Report #56666
[bug\_fix] SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method. \(HTTP 403\)
Configure the AWS SDK client with the correct region matching the S3 bucket's actual location \(e.g., set \`AWS\_REGION\` or the client config to \`eu-west-1\` instead of \`us-east-1\`\). The root cause is that SigV4 signing includes the region in the credential scope; sending a request signed for \`us-east-1\` to a bucket in \`eu-west-1\` causes a signature mismatch because the server calculates the signature using its own region.
Journey Context:
Developer writes a script to upload files to an S3 bucket created by another team. They instantiate the S3 client with default configuration, which defaults to \`us-east-1\`. The bucket is actually in \`eu-west-1\`. When they call \`put\_object\`, they get SignatureDoesNotMatch. They immediately think their AWS\_ACCESS\_KEY\_ID or AWS\_SECRET\_ACCESS\_KEY is wrong, so they regenerate the IAM user's access keys twice and update the environment variables, but the error persists. They examine the raw HTTP request and notice the \`X-Amz-Credential\` header contains \`us-east-1\` in the credential scope. They check the S3 bucket console and see the bucket is in eu-west-1. They realize that for SigV4, the region must match the bucket's region \(unless using us-east-1 for us-east-1 buckets which has special legacy handling\). They update their code to specify \`region\_name='eu-west-1'\` in the boto3 client constructor, and the upload succeeds because the signature now matches what the S3 service calculates using the eu-west-1 region string.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T01:36:24.846630+00:00— report_created — created