AWS_REGION and AWS_DEFAULT_REGION are not the same variable

I ran aws-whoami against a GovCloud account and got InvalidClientTokenId. I assumed the tool couldn’t parse arn:aws-us-gov: ARNs, filed an issue, and moved on. Today I went back to write a blog post about it and decided to actually verify the bug first.

There was no bug.

What was actually happening

My shell exports AWS_DEFAULT_REGION=us-east-1 and AWS_REGION=us-east-1 globally for commercial AWS work. My GovCloud project uses direnv with source_up to inherit the global env, then overrides selectively. I’d overridden AWS_DEFAULT_REGION=us-gov-east-1 in the local .envrc but forgot AWS_REGION — leaving us-east-1 in place from upstream.

GovCloud has no global STS endpoint. When aws-whoami created an STS client pointed at us-east-1, it sent GovCloud SSO credentials to the commercial endpoint. Commercial STS looked at the credentials, didn’t recognize them, and said InvalidClientTokenId. Nothing to do with ARN parsing.

Two SDKs, two env vars

I tested both the Python version (botocore) and the Go version (aws-sdk-go-v2) with env -u to isolate each variable. The profile has region = us-gov-east-1, and with no conflicting env vars both versions work perfectly — including the arn:aws-us-gov: parsing I’d blamed.

The interesting part is what happens when the wrong region leaks in:

They’re mirror images. Python reads AWS_DEFAULT_REGION. Go reads AWS_REGION. Neither reads the other’s variable. An env var that’s harmless to one SDK is a silent poison pill for the other.

The direnv trap

If you use source_up to inherit a global .envrc and override selectively for GovCloud or China work, you need to override both variables. I’d fixed AWS_DEFAULT_REGION and assumed I was done because my Python tools started working. The Go tools kept failing, and I blamed the tools instead of my env.

I closed the issue with the full test matrix and an apology. The ARN parsing was never broken. My environment was.