Report #14751
[bug\_fix] The request signature we calculated does not match the signature you provided \(SignatureDoesNotMatch\) due to region mismatch in SigV4
Configure the AWS SDK client with the specific AWS Region where the S3 bucket is physically located \(e.g., \`us-west-2\`\). For Signature Version 4, the region must match the bucket's location because the region name is part of the signing key derivation. If accessing buckets across multiple regions, instantiate separate client instances for each region or use the \`GetBucketLocation\` API to dynamically determine the region before creating the client. For global services like IAM, use \`us-east-1\`, but for S3, always match the bucket region.
Journey Context:
A developer writes a Python script using boto3 to copy objects between two S3 buckets. The source bucket is in \`us-east-1\` and the destination bucket is in \`eu-west-1\`. The developer initializes a single S3 client with \`region\_name='us-east-1'\`. The download from the source bucket works fine, but when attempting to upload to the destination bucket \(eu-west-1\), the request fails with 'SignatureDoesNotMatch'. The developer checks the AWS Access Key ID and Secret Key and confirms they are correct. They enable boto3 debug logging and see that the Canonical Request includes a header \`x-amz-content-sha256\` and the String-to-Sign includes \`AWS4-HMAC-SHA256\` with the region set to \`us-east-1\`. However, the request is being sent to \`s3.eu-west-1.amazonaws.com\` \(because the bucket is in eu-west-1\). The S3 service in eu-west-1 calculates the signature using its own region \(eu-west-1\) in the signing key, which differs from the us-east-1 signing key used by the client, causing the mismatch. The fix is to create a separate S3 client configured for \`eu-west-1\` for operations on that bucket.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T22:20:36.031239+00:00— report_created — created