InvalidClientTokenId

The provided AWS access key ID does not exist.

Frequently documented in developer and vendor support forums.

• Typo in access key
• Key was deleted
• Using wrong account credentials

1. Verify access key in IAM console
2. Generate new access keys
3. Check correct profile is used

Last reviewed: March 2026 How we review solutions

AWS returns "InvalidClientTokenId" when the access key ID in your API request does not match any active access key in any AWS account. This is fundamentally an identity problem—AWS cannot even begin to evaluate permissions because it does not recognize who is making the request. The most common cause is a copy-paste error when configuring credentials: access key IDs start with "AKIA" for long-term keys or "ASIA" for temporary session credentials, and a missing or extra character invalidates the entire key. Deactivated or deleted access keys also produce this error—when an administrator rotates credentials by creating a new key and deleting the old one, any system still using the old key will immediately fail. Environment variable conflicts are another frequent source: if AWS_ACCESS_KEY_ID is set in your shell environment, it takes precedence over credentials in ~/.aws/credentials, and a stale environment variable will override the correct file-based credentials. In CI/CD pipelines, this error often appears when secrets are not properly injected into the build environment or when the secret reference name does not match the environment variable name the AWS SDK expects.

1. Run aws sts get-caller-identity to verify your current credentials
2. Check that AWS_ACCESS_KEY_ID starts with "AKIA" (long-term) or "ASIA" (session)
3. Verify no environment variable is overriding ~/.aws/credentials
4. Confirm the access key is active in the IAM console (not deactivated or deleted)
5. Check for trailing whitespace or newline characters in your key values
6. If using assumed roles, verify the session token is also set (AWS_SESSION_TOKEN)

Assumed role with expired session token

When using aws sts assume-role, you get temporary credentials with an expiration (default 1 hour). If you set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY but forget AWS_SESSION_TOKEN, or if the session has expired, you get InvalidClientTokenId. Re-run the assume-role command to get fresh credentials.

Cross-account access with wrong partition

AWS GovCloud (us-gov) and China regions (cn) are separate partitions. An access key from the commercial partition will not work against GovCloud endpoints and vice versa. Ensure your key matches the partition you are targeting.

Credential file with wrong profile name

If your ~/.aws/credentials has [production] instead of [default], and you run aws commands without --profile production, the SDK uses the default profile which may not exist or may have old keys.

Where do I find my keys?

In IAM > Users > Security credentials.

How do I rotate keys?

Create new key, update apps, delete old key.

What is the difference between InvalidClientTokenId and AccessDenied?

InvalidClientTokenId means AWS does not recognize the access key at all—the identity is invalid. AccessDenied means the identity is valid but lacks permission for the requested action. The fix for each is different: fix the key vs. fix the IAM policy.

How do I rotate AWS access keys safely?

Create a new access key in IAM, update all systems to use the new key, verify they work with aws sts get-caller-identity, then deactivate (not delete) the old key. Wait a week before deleting the old key to catch any systems you missed.

Can this error appear when using IAM roles on EC2?

Typically no—EC2 instance roles use the instance metadata service, not access keys. However, if environment variables like AWS_ACCESS_KEY_ID are set on the instance, they override the role credentials and can cause this error if stale.

• AWS CLI Command Reference
• AWS API Error Retries – AWS Docs