InvalidClientTokenId after aws key rotation

Not specified by the original author.

TL;DR

InvalidClientTokenId means the access key in the request does not exist. After a rotation, something is still using the old, now-deleted key. Find every place the old key was configured and point it at the new one.

Error

"InvalidClientTokenId" after aws key rotation

Steps

1. Identify which key is failing: the error follows the caller, so check the credentials file, env, or IAM role of the failing process. Expected: you find the stale key identifier.
2. Compare it against the current keys on the IAM user: aws iam list-access-keys --user-name [user]. Expected: the failing key is absent (deleted) or inactive.
3. Update the failing caller with the new key pair. Expected: the caller uses the current key.
4. Search for other copies: CI secrets, app config, and scripts often each hold their own copy. Expected: a complete list of places the old key lived.
5. Delete or deactivate the old key only after every caller is moved. Expected: no caller can regress to the dead key.

When to use

• AWS API calls fail with InvalidClientTokenId after rotating an IAM user key.
• You need a checklist for finding stale key copies.

When not to use

• ExpiredToken (session token issue, not a deleted key).
• SignatureDoesNotMatch (wrong secret, not a missing key).

Tool compatibility

• AWS IAM user access keys; CLI, SDKs, and CI callers.

Variant phrasings

The security token included in the request is invalid

Often the same stale-key situation.

AWS key not recognized after rotation

Identical handling.

Why it happens

Rotations create a new key before deleting the old, but every copy of the old key (files, env, CI, docs) must be updated by hand or automation, and missed copies fail.

Edge cases

• Keys embedded in AMIs or container images keep failing until the image is rebuilt.
• Third-party integrations holding the old key fail on their schedule, not yours.
• Deleting the old key before the cutover is complete turns a warning into an outage.

Provenance

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

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

Thread query: "InvalidClientTokenId" after aws key rotation

TL;DR: InvalidClientTokenId means the access key in the request does not exist. After a rotation, something is still using the old, now-deleted key. Find every place the old key was configured and point it at the new one.

Not specified by the original author.

TL;DR

InvalidClientTokenId means the access key ID does not exist: a typo, a deleted key, or the wrong credentials file/profile being picked up. In automation the usual story is environment variable precedence: stale AWSACCESSKEY_ID in the environment shadowing the intended credentials, or the wrong profile selected. Print which key ID is being used (it is not secret) and trace where it came from.

The query

AWS "InvalidClientTokenId" in automation: credential chain debugging

Use this when

• Automation fails with InvalidClientTokenId
• Credentials work locally but fail in CI
• Debugging credential precedence
• After credential rotation

Not for when

• IAM "not authorized" errors (key valid, permissions lacking)
• Expired session tokens (different error)
• STS assume-role failures

Steps

Step 1: Identify which key ID is being used

Log or print the access key ID the failing call uses (key IDs are not secret). Compare it against the expected key. A completely unexpected ID means the wrong credential source is winning. Expected output: the actual key ID in use, compared to the intended one.

Step 2: Walk the credential provider chain

Check each source in precedence order: environment variables, shared credentials file profiles, container/IAM roles. The winner is the first source with values; stale values in a high-precedence source shadow everything below. Expected output: the winning credential source identified.

Step 3: Check for stale environment variables

Look for AWSACCESSKEY_ID set in the CI environment, container env, or shell profile from an old rotation. Stale env vars are the number one cause in automation; they override fresher file-based credentials silently. Expected output: stale variables found and removed, or ruled out.

Step 4: Verify the key exists and is active

Check in IAM that the key ID exists and is active. Deleted or deactivated keys produce exactly this error; rotation that deleted the old key before automation picked up the new one is the classic sequence. Expected output: the key confirmed existing and active, or the deletion found.

Step 5: Prefer IAM roles over static keys

Where possible, eliminate static keys: use IAM roles for EC2, ECS task roles, or OIDC federation for CI. Roles cannot suffer InvalidClientTokenId from stale keys because there are no keys. Expected output: the credential source moved to roles, removing the failure class.

Provenance

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

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

Thread query: AWS "InvalidClientTokenId" in automation: credential chain debugging

TL;DR: InvalidClientTokenId means the access key ID does not exist: a typo, a deleted key, or the wrong credentials file/profile being picked up. In automation the usual story is environment variable precedence: stale AWSACCESSKEY_ID in the environment shadowing the intended credentials, or the wrong profile selected. Print which key ID is being used (it is not secret) and trace where it came from.

Not specified by the original author.

Your access key is wrong, deleted, or from a different account. Re-enter credentials with aws configure --profile my-profile (or regenerate the key pair in the IAM console first if the key was deleted or deactivated). This is not a session expiry, so aws sso login alone will not help unless you are on SSO.

An error occurred (InvalidClientTokenId) when calling the ListBuckets operation: The security token included in the request is invalid.

Fix

1. Confirm which identity is actually being used:

   aws sts get-caller-identity --profile my-profile

   Expected on success: your UserId, Account, Arn. If this fails, the credentials for that profile are bad.

2. Check the obvious: open ~/.aws/credentials and look for copy/paste damage (trailing spaces, truncated keys, keys pasted into the wrong profile section).

3. If the key was deleted or deactivated in IAM, create a fresh access key pair in the IAM console, then:

   aws configure --profile my-profile

   Paste the new key ID and secret when prompted. Expected: aws sts get-caller-identity --profile my-profile succeeds.

4. If you are on SSO rather than static keys, re-authenticate instead:

   aws sso login --profile my-profile

When this applies

• The error is (InvalidClientTokenId) with The security token included in the request is invalid.
• Commands worked before and broke after a key rotation, or never worked with these keys.

When it does NOT apply

• ExpiredToken: the key is fine, the temporary session lapsed. Refresh the session.
• SignatureDoesNotMatch: the secret is wrong but the key ID exists. Re-enter the secret carefully.
• AccessDenied: credentials are valid, permissions are missing.

Compatibility

• AWS CLI v1 and v2.

Why it happens

AWS cannot find the access key ID in its records for the target account. Usual causes: the key was deleted or deactivated, it belongs to a different account than the one being called, or it was mistyped during aws configure.

Edge cases

• AWS_ACCESS_KEY_ID env vars override the credentials file; a stale exported key produces this error even with a correct file. Check env | grep AWS_.
• Keys are per-account: a key from account A used against account B resources fails this way.
• After aws configure, old sessions cached in ~/.aws/cli/cache can linger; clear the cache if the error persists with fresh keys.

Documented in the towardsthecloud AWS CLI profiles guide under 'Invalid Credentials or Access Denied': the error 'An error occurred (InvalidClientTokenId)' means the access key ID does not exist in AWS records for the target account - commonly deleted, from a different account, or mistyped. Diagnosis: run 'aws sts get-caller-identity --profile my-profile'; if it fails the credentials are invalid. Fixes: for IAM users regenerate the access keys in the IAM console and re-run 'aws configure --profile'; for SSO profiles re-authenticate with 'aws sso login --profile'. Also watch for copy/paste errors like extra spaces. Source: https://towardsthecloud.com/blog/aws-cli-switch-profiles