I am attempting to verify my AWS credentials using the command aws sts get-caller-identity, but I am receiving an error stating: "An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid." I have updated my ~/.aws/credentials file, yet the CLI still refuses to authenticate. Is this caused by an expired session, a typo in my Access Key ID, or is my local machine pointing to the wrong AWS Partition or Region?
3 answers
In most Software Development and Cloud Technology workflows, the InvalidClientTokenId error means that the AWS Access Key ID you are using is either non-existent or has been deleted in the IAM console. AWS cannot find a match for the token provided. First, run aws configure list to see exactly which credentials and profile the CLI is currently using. If the Access Key looks correct, log into the AWS Management Console, navigate to IAM, and ensure the status of that specific key is set to "Active." If you recently deleted a key and created a new one, your local environment might still be cached or pointing to an old profile.
Could this error be related to environment variables? I’ve noticed that AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables in the terminal often override the values set in the credentials file.
Check if you are using an AWS SSO or Federated login. If your session token has expired, GetCallerIdentity will fail even if your Client ID looks valid because the associated temporary session is no longer active.
I agree with Sarah. For those using temporary credentials, running aws sso login or refreshing your session token is the standard fix. It's a frequent point of confusion in modern Software Development environments that rely on short-lived security tokens.
Julian, that is exactly what happened to me! I was editing my ~/.aws/credentials file for hours, but I forgot I had exported old keys as environment variables earlier in the session. In Cloud Technology, environment variables have the highest priority in the AWS CLI credential provider chain. Running unset AWS_ACCESS_KEY_ID and unset AWS_SECRET_ACCESS_KEY cleared the old tokens and allowed the CLI to finally use the correct credentials from my config file.