The describe-regions command describes the regions that are enabled for your AWS account. At times this command fails with the error message “AWS was not able to validate the provided access credentials”.

As a part of our Server Management Services, we help our Customers to fix AWS related errors regularly.

Let us today discuss the possible causes and fixes for this error.

What causes error AWS was not able to validate the provided access credentials ?

As we discussed earlier, while trying to run the ‘aws ec2 describe-regions’ command, it at times fails with the error as given below:

1. The version of Session tokens: The AWS Security Token Service (AWS STS) supports an updated version format for session tokens. New AWS Regions not enabled by default use the updated AWS STS format. The global AWS STS endpoint (sts.amazonaws.com) issues tokens in the previous format by default. This error can occur if a session token is trying to use the previous format with an AWS Region not enabled by default.

2. Timestamp of Authentication tokens: If date or time is wrong on the local computer, or date/time is wrong for VM/instance, then the credentials will be invalid and we will get “AWS was not able to validate the provided credentials”.

3. AWS CLI is Boto based: Boto can pick up credentials from all sorts of places. It saves the old authentication values in the file location $HOME/.boto

4. File format issue: File format of sourced bash file containing the environment variables at times causes the ID and SECRET variables to have invisible trailing whitespace. This in turn causes issues with the AWS authentication.

How to fix error AWS was not able to validate the provided access credentials ?

Let us now look at the possible methods to fix the issue:

The version of Session tokens

Tokens obtained from Regional endpoints use the new version format and are valid in all AWS Regions. It is a best practice to use Regional STS endpoints. This is because using an endpoint that is geographically closer to your application means that it can access STS services with lower latency and with better response times.

Use one of the following methods to resolve this issue.

(a) Obtain tokens from a Regional endpoint

(b) Change Region compatibility of session tokens for global endpoint

Timestamp of Authentication tokens

While using the the AWS CLI, we need to set the credentials first. To set credentials use the below command.

$ aws configure

If it is shows the same error again, then we need to check the Machine time and sync with standard time. We can set the time with command below or NTP.

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

sudo ntpclient -s -i 1 -l -d -h 0.amazon.pool.ntp.org  //To sync the clock for VM/instance

For the machine running the host kernel, OS client sending the API call includes a timestamp in the API call headers. If the difference between the timestamp and AWS clock is too big, the API call will be rejected with “AuthFailure”. Assuming ntpd is installed on the system where you are running the AWS CLI commands, you can try the following commands in order:

date
sudo service ntpd stop
sudo ntpdate time.nist.gov
sudo service ntpd start
ntpstat

After this the OS clock should be synchronized with NTP. Finally, make sure to run the configure command.

AWS CLI is Boto based

Another method to fix the error is to ensure that the login credentials mentioned in .boto file is correct.

cat ~/.boto

[Credentials]
aws_access_key_id=MY*OLD*ACCESS*KEY
aws_secret_access_key=MY*OLD_SECRET*ACCESS*KEY

If not, we need to update the values in .boto file.

Alternate Fixes

If you manage AWS services from AWS CLI command using “aws configure”, you have a credential file generated in the home directory.

#cat /root/.aws/credentials
[default]
aws_access_key_id=XXXXXXXXXX
aws_secret_access_key=XXXXXXXX

Make sure the “aws_access_key_id” and “aws_secret_access_key” are correct as taken from IAM of AWS or create a new access key from IAM and change it accordngly in the credentials file.

Apart from the fixes mentioned above, fixing the file format on the bash sourced file and reloading the environment variables can also help to fix the error. It would also be a good idea to check the permission of the IAM user and ensure it has administrator access policy attached to it via the group.

[Need any further assistance in fixing AWS errors? – We’re available 24*7]

Conclusion

In short, the describe-regions command at times fails with the error message “AWS was not able to validate the provided access credentials”. Today, we saw how our Support Engineers fix this error.