You made an AWS call and got InvalidClientTokenId: The security token included in the request is invalid. This is an authentication failure, not an authorization one: AWS is saying it does not recognize the access key ID in your request at all. That is a different and often more confusing problem than a permissions denial, because the credentials look fine to you. The cause is almost always that the key was deleted or disabled, the credentials are stale, or you are pointed at the wrong partition or region. The fast path is to confirm which identity you are actually presenting before you touch anything else.
InvalidClientTokenId: The security token included in the request is invalid.
What this error means
Every AWS request is signed with an access key ID and secret. When AWS receives the request, it looks up that access key ID to verify the signature. InvalidClientTokenId means that lookup failed: the access key ID is not one AWS can find and use for this endpoint. That happens when the key was deleted or deactivated, when the credentials being sent are not the ones you think, or when the request is aimed at an endpoint in a different partition (aws, aws-cn, or aws-us-gov) than the account the key belongs to. Because the failure is about recognizing the key rather than what it is allowed to do, no amount of policy editing will fix it. You fix the credentials or the endpoint.
Common causes
- The access key was deleted or set to inactive in IAM.
- The credentials in use are stale: an old key left in
~/.aws/credentials, a shell environment variable overriding your profile, or a cached key in a tool. - The wrong profile is active, so a different account’s key is being sent than you intend.
- A partition mismatch: standard
awscredentials sent to anaws-cnoraws-us-govendpoint, or vice versa. - A region endpoint the account is not enabled for, or a typo in a custom endpoint URL.
- A copy-paste error: a trailing space, or the key ID and secret swapped.
How to fix it
STABILIZE
- Confirm which identity you are actually presenting. This is the single most useful command and it will either succeed and name the caller, or fail with the same error, which tells you the credentials themselves are the problem:
aws sts get-caller-identity
If this fails with InvalidClientTokenId, the credentials are bad or wrong-partition. If it succeeds but a later call fails, the region or endpoint is the issue.
DIAGNOSE
- See exactly which credentials the CLI is resolving and from where. Check the active profile and the environment overrides:
echo "AWS_PROFILE=$AWS_PROFILE"
echo "AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID"
aws configure list
Environment variables win over the profile, so a stale AWS_ACCESS_KEY_ID in your shell will silently override ~/.aws/credentials.
- Confirm the key exists and is active in the account it belongs to. If you can reach that account another way, list the keys for the user:
aws iam list-access-keys --user-name my-user
Look at the Status field: an Inactive key produces this error.
- Confirm the endpoint and region match the key’s partition. A GovCloud or China account needs its own endpoints, and mixing them with standard credentials fails:
echo "AWS_REGION=$AWS_REGION"
aws configure get region
FIX
- If the credentials are stale, clear the overriding environment variables so the intended profile is used:
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
export AWS_PROFILE=my-profile
- If the key was deleted or deactivated, create a fresh key and update your credentials file:
aws iam create-access-key --user-name my-user
aws configure --profile my-profile
- Re-copy both the access key ID and secret carefully to rule out a paste error, then re-run
aws sts get-caller-identityto confirm the fix. - If the cause is a partition or region mismatch, point the call at the correct partition endpoint and region for the account the key belongs to.
How to prevent it
- Prefer short-lived credentials from IAM Identity Center (SSO) or assumed roles over long-lived access keys, so there are fewer stale keys to go wrong.
- Rotate access keys on a schedule and delete old ones promptly so a deleted key never lingers in a config file.
- Keep one clear profile per account and avoid setting
AWS_ACCESS_KEY_IDin your shell, which silently overrides everything. - Document which accounts are in the
aws-cnoraws-us-govpartitions so nobody points standard credentials at them. - Store credentials in a secrets manager or the SSO cache rather than pasting them between machines.
When to call a senior engineer
Call for help when the same identity fails across many machines or pipelines and you cannot tell whether the key, the partition, or the endpoint is at fault, when credentials are managed by an SSO or federation setup that keeps handing out something the API rejects, or when this appears in production automation and you need it traced without leaking secrets. Erzon engineers can pin down exactly which credential is being presented, fix the source of the stale or wrong-partition key, and move you onto short-lived credentials so it stops recurring.
Related errors we fix
AccessDenied: User is not authorized to perform this operation Fix this error → AWS Stack:arn:... is in ROLLBACK_COMPLETE state and can not be updated. Fix this error → AWS UPDATE_ROLLBACK_FAILED Fix this error → AWS ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded Fix this error → Want a senior engineer to just fix it?
Paste this exact error into the form. A senior engineer replies within one business hour with what is likely wrong and a flat quote. Triage is free.
Book a fix