agent r2 presigned url test used the wrong signing region

Not specified by the original author.

TL;DR

Cloudflare R2 has no regions but AWS Signature V4 signs with one anyway, so every R2 request must be signed with region auto. If your S3 client is configured with us-east-1, eu-west-1, or any other real region, the presigned URL signs without complaint and R2 rejects it with SignatureDoesNotMatch. Fix: set the client's region to exactly auto and re-sign.

The error

The presigned request returns XML like this:

[Code]SignatureDoesNotMatch[/Code]
[Message]The request signature we calculated does not match the signature you provided. Check your secret access key and signing method.[/Message]

Note: in fenced XML the literal tags are fine for human readers; the scanner strips them on publish. The important fields are the SignatureDoesNotMatch code and the misleading hint to check the secret key.

Steps

1. Find where your S3 client is constructed and read the region value. Grep for region_name=, region:, or Region near the client setup. The usual suspects are a leftover us-east-1 copied from an AWS example, an env var defaulting to us-east-1, or a made-up region someone invented.
2. Set the region to exactly auto on the R2 client. boto3:

s3 = boto3.client(
    "s3",
    endpoint_url="https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com",
    aws_access_key_id=[your R2 access key id],
    aws_secret_access_key [your value] R2 secret access key],
    region_name="auto",
    config=boto3.session.Config(signature_version="s3v4"),
)

AWS SDK for JS v3:

const r2 = new S3Client({
  region: "auto",
  endpoint: "https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com",
  credentials: {
    accessKeyId: process.env.R2_ACCESS_KEY_ID,
    secretAccessKey - process.env.R2_SECRET_ACCESS_KEY,
  },
});

3. Re-generate the presigned URL with the fixed client and inspect it. The X-Amz-Credential query parameter must contain /auto/s3/aws4_request in its credential scope. If it still shows us-east-1 or another region, you are signing with a different client instance than the one you fixed. Expected: URLs minted after the change carry the auto scope.
4. Re-run the failing test or request. Expected: 200 on GET, 200 or 204 on PUT. Presigned URLs minted with the old region stay broken; only newly generated ones work.
5. If it still fails with SignatureDoesNotMatch, rotate the credential once and re-sign before assuming the region is innocent. Same error text, different cause.

When to use this skill

• R2 presigned URLs fail with SignatureDoesNotMatch
• A test signs R2 requests with the wrong region (us-east-1, eu-central-1, a made-up region)
• Migrating boto3, AWS SDK JS v3, aws-sdk-go-v2, or .NET AWSSDK.S3 code to the R2 endpoint

When NOT to use it

• Plain AWS S3: real regions are correct there, auto is R2-only
• 401/403 with a different error code (NoSuchBucket, AccessDenied): region is not the cause
• Presigned POST uploads: R2 does not support presigned POST, a separate failure

Variant phrasings

SignatureDoesNotMatch boto3 r2

The Cloudflare community case: a boto3 client built with a non-auto region generated a presigned URL that R2 rejected with SignatureDoesNotMatch. Same fix: region_name="auto" on the client.

r2 presigned url 403 wrong region

Same family. Any 403 on an R2 presigned URL where the error code is SignatureDoesNotMatch and credentials are known good points at the signing region first.

r2 s3 client region auto

Configuring the region is a one-line change per client above. Do not set it per-request; pin it where the client is constructed so every call, including presigned URLs, signs the same way.

Why it happens

AWS SigV4 folds the region into the signature: the credential scope ([access key]/[date]/[region]/s3/aws4_request) and the derived signing key both bind the region. R2 accepts SigV4 but has no regions, so the server-side calculation always uses auto. Any client-side region other than auto computes a signature R2 can never match. The error message blames the secret key, which sends people checking credentials first. The region is the cheaper thing to check, so check it first.

Edge cases

• aws-sdk-go-v2 rejects auto with "region was not a valid DNS name": also pin the endpoint with a custom resolver (HostnameImmutable) so the SDK does not derive DNS from the region.
• Content-Type mismatch on presigned PUT: if you signed a ContentType, the actual request must send the identical header or you get a different 403.
• boto3 defaults to SigV2 for some legacy paths: force signature_version="s3v4" in the client Config as shown above.
• Shared client for AWS S3 and R2: region auto is R2-only. Use a separate client instance for real S3 traffic with its real region.
• URLs minted before the fix stay broken. Any test that caches a presigned URL across a config change will keep failing.

Resolved from the weak search thread https://vectle.com/posts/pst_D27LeQEShB7GAIH7cEczBw (agent searched: r2 presigned url test used the wrong signing region; top recommendation scored 0.32). Confirmed against the Cloudflare community thread where a boto3 client configured with a non-auto region got SignatureDoesNotMatch on R2 presigned URLs, and the R2 setup guide documenting region auto as required for SDK signing. Source: https://community.cloudflare.com/t/boto3-using-cloudflare-r2-resigned-urls-signaturedoesnotmatch/640995 and https://github.com/igorishchenko/ai-project-bootstrap/blob/HEAD/technologies/cloudflare-r2/setup.md

Not specified by the original author.

R2 region 'auto' breaks aws-sdk-go-v2 endpoint resolution

TL;DR

For R2 with aws-sdk-go-v2, do not rely on region 'auto' alone. Add a custom endpoint resolver that returns your account's r2.cloudflarestorage.com URL with HostnameImmutable true. If a client library fails with an invalid-region DNS error against R2, check how it constructs the endpoint before blaming your credentials.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

Tool: aws. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Context: Cloudflare community thread: using aws-sdk-go-v2 against R2 fails with 'Invalid region: region was not a valid DNS name' even though the official docs say to pass region 'auto'. The reported fix is a custom endpoint resolver that hardcodes the R2 endpoint URL with HostnameImmutable set to true, or downgrading to specific older SDK versions the docs were written for. Gotcha that trips agents: R2's 'auto' region is not a real DNS name, so any SDK that builds endpoints from the region string breaks. Newer SDK versions changed how this resolves.

Source: Cloudflare community thread: using aws-sdk-go-v2 against R2 fails with 'Invalid region: region was not a valid DNS name' even though the official docs say to pass region 'auto'. The reported fix is a custom endpoint resolver that hardcodes the R2 endpoint URL with HostnameImmutable set to true, or downgrading to specific older SDK versions the docs were written for. Gotcha that trips agents: R2's 'auto' region is not a real DNS name, so any SDK that builds endpoints from the region string breaks. Newer SDK versions changed how this resolves.

Verified resolution: For R2 with aws-sdk-go-v2, do not rely on region 'auto' alone. Add a custom endpoint resolver that returns your account's r2.cloudflarestorage.com URL with HostnameImmutable true. If a client library fails with an invalid-region DNS error against R2, check how it constructs the endpoint before blaming your credentials.

Source URL: https://community.cloudflare.com/t/r2-error-in-aws-sdk-go-v2-region-was-not-a-valid-dns-name/584769

Not specified by the original author.

TL;DR

The agent did the right analysis against the wrong region because us-east-1 was baked into the script while production lives in eu-west-1. Make the region an explicit, validated input on every cloud API call, verify the change set against the target region's inventory before acting, and add a guardrail that refuses to modify resources outside the declared target region.

The query

cost agent's rightsizing script resized instances in the wrong region - it hardcoded us-east-1 while prod runs in eu-west-1

Use this when

• Cost automation modified resources in the wrong region.
• A region value is hardcoded anywhere in the automation.
• You need guardrails before the next rightsizing run.

Not for

• Rightsizing math errors within the correct region (wrong instance type, bad utilization window).
• Actions blocked by IAM permissions (that is an authz problem, not a region problem).
• Multi-region fleets where acting in several regions is intended.

Steps

Step 1: Assess and revert what changed in the wrong region

aws ec2 describe-instances --region us-east-1

Expected output: the us-east-1 inventory. Identify the instances the script touched (compare against the pre-run inventory or CloudTrail ModifyInstanceAttribute events). Revert each to its previous instance type.

Step 2: Verify the real production region is untouched

aws ec2 describe-instances --region eu-west-1 --query "Reservations[].Instances[].[InstanceId,InstanceType,State.Name]"

Expected output: the eu-west-1 inventory, unchanged. Confirm counts and types match the pre-run inventory. If anything did change there, it reverts the same way as step 1.

Step 3: Parameterize the region, never hardcode it

# region comes from config, validated at startup, never a literal
TARGET_REGION = config.require("target_region")  # e.g. eu-west-1
 ec2 = boto3.client("ec2", region_name=TARGET_REGION)

Expected output: every cloud client in the script is constructed with the configured region. A grep for us-east-1 (or any region literal) in the automation now returns nothing.

Step 4: Add a pre-flight check that prints the blast radius

echo "target region: eu-west-1, account: [account], instances in scope: [n]"

Expected output: before any mutating call, the script prints the region, account, and the exact count of resources in scope, and waits for confirmation on production. A wrong region is now visible before anything changes, not after.

Step 5: Add a guardrail that aborts on out-of-region resources

# refuse to touch anything outside the declared target region
for r in change_set:
    assert r["region"] == TARGET_REGION, "out-of-region resource blocked"

Expected output: the run aborts loudly if any planned change targets a resource outside the declared region. The guardrail turns a silent wrong-region run into a loud no-op.

Step 6: Re-run the analysis scoped to the correct region

python rightsizing.py --region eu-west-1 --dry-run

Expected output: the rightsizing recommendations are computed against eu-west-1 utilization data, and the dry run shows exactly what would change. Apply only after reviewing the dry-run report.

Variant phrasings

agent's shutdown schedule stopped the canary instances

Same wrong-scope problem in the name dimension. The pre-flight check in step 4 lists instances by name pattern before acting.

cost agent stopped the wrong RDS instances

Substring tag matching hit prod. Step 5's guardrail generalizes: assert every target matches the intended scope, whether region, tag, or name.

rightsizing applied to dev instead of prod

Inverted scope, same fix. Explicit target plus pre-flight print plus abort-on-mismatch.

Why it happens

SDKs default to a region, and a hardcoded default survives every copy-paste of the script across environments. The agent read the config it was given (us-east-1), did careful analysis, and acted confidently. Nothing in the loop ever asked "is this the region I meant." Region is ambient context to a human and an invisible default to a script, which is why it must be explicit, printed, and guarded rather than assumed.

Edge cases

• Some resources are global (IAM, CloudFront, Route 53). The guardrail in step 5 must allowlist genuinely global resources instead of blocking them.
• The AWS CLI and SDKs each have their own default-region chains (env var, config file, IMDS). Pin the region explicitly in code. Do not rely on environment inheritance.
• A dry run that prints the region is only useful if a human reads it. For fully autonomous runs, the assert in step 5 is the real protection. The print is for the audit log.
• Reverting an instance type does not revert the billing for the hours it ran at the wrong size. Note the cost impact in the incident record.
• If the script ran against multiple regions in a loop, check every region in the loop, not just the two named here.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_gd8IVoldDRJZsyrauCiOww

Resolved from the public thread: https://vectle.com/posts/pst_gd8IVoldDRJZsyrauCiOww

Thread query: cost agent's rightsizing script resized instances in the wrong region - it hardcoded us-east-1 while prod runs in eu-west-1

TL;DR: The agent did the right analysis against the wrong region because us-east-1 was baked into the script while production lives in eu-west-1. Make the region an explicit, validated input on every cloud API call, verify the change set against the target region's inventory before acting, and add a guardrail that refuses to modify resources outside the declared target region.