AWS InvalidClientTokenId in automation: credential chain debugging

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.

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.

Unable to locate credentials. You can configure credentials by running 'aws configure'

TL;DR: the CLI found no credentials anywhere it looks. Run aws configure and enter your access key pair, or if your org uses SSO run aws sso login --profile [profile]. Nine times out of ten the fix is either never having run aws configure, or AWS_PROFILE pointing at a profile that doesnt exist.

Unable to locate credentials. You can configure credentials by running "aws configure".

Steps

1. Confirm the failure:

aws sts get-caller-identity

Expected on success: JSON with UserId, Account, and Arn. If it errors the same way, keep going.

2. Check which profile is active and where values come from:

aws configure list

Expected: shows the profile name and the source of each value (env, config file, or none).

3. Set credentials. Static keys:

aws configure

Expected: prompts for AWS Access Key ID, AWS Secret Access Key, region, and output format. SSO instead:

aws sso login --profile [your profile]

Expected: browser opens for SSO, then the CLI reports a successful login.

4. Verify:

aws sts get-caller-identity

Expected: returns your identity with no error.

When this applies

• any aws command fails with the exact Unable to locate credentials error
• fresh install where aws configure was never run
• new shell where the env vars were not exported, or AWS_PROFILE names a profile with no keys
• SSO session expired

When it doesnt

• InvalidClientTokenId: The security token included in the request is invalid — the key is deleted, deactivated, or mistyped; recreate it in IAM and re-run aws configure
• ExpiredToken — refresh SSO or the temporary credentials
• AccessDenied on a specific call — identity is fine, the IAM policy is missing the action

Compatibility

AWS CLI v2 (v1 from distro repos is retired). Same chain on Linux, macOS, and Windows.

Why it happens

The CLI checks credentials in a fixed order: environment variables, the shared credentials file, SSO cache, then container or instance metadata. If none yields a key it raises this instead of guessing. The classic traps: AWS_PROFILE pointing nowhere, env vars set in one terminal but not another, and an SSO login that expired silently.

Edge cases

• ~/.aws/credentials stores the secret in plain text: chmod 600 it and never commit it
• a typo in the env var name is a top cause — it must be exactly AWSSECRETACCESS_KEY
• system clock skew shows up as SignatureDoesNotMatch, not this error
• in containers and EC2, prefer IAM roles over static keys so there is nothing to locate

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=aws+unable+to+locate+credentials'

AWS CLI users repeatedly hit Unable to locate credentials when no credentials exist in any of the places the CLI checks: environment variables, the shared credentials file, an instance profile, or an assumed role. The verified fix: run aws configure (or aws sso login --profile for SSO setups) and confirm with aws sts get-caller-identity, watching for the common traps of a wrong AWS_PROFILE or a typo in the env var name. Source: https://github.com/abdullahbinamin/devops-training-practical-notes/blob/HEAD/terraform/Day-01-Terraform-Fundamentals-and-Setup/04-aws-cli-setup.md