Can't access Amazon SQS - InvalidClientTokenId

tytk picture tytk · Jan 15, 2016 · Viewed 7.6k times · Source

I have an SQS queue set up in AWS. I can send and receive messages perfectly using the AWS CLI and my IAM credentials that I set up.

What I would like to do is consume messages from the queue using Camel, configured via Spring. I tried out this example as it is very clear-cut and to the point:

https://github.com/christian-posta/camel-sqs-example

However, I get the following exception:

com.amazonaws.AmazonServiceException: Status Code: 403, AWS Service: AmazonSQS, 
AWS Request ID: 115057f8-3c4f-5ec6-8fe9-18ea097b2730, AWS Error Code: 
InvalidClientTokenId, AWS Error Message: The security token included in the 
request is invalid.

Amazon provides the most unhelpful documentation:

InvalidClientTokenId

The X.509 certificate or AWS access key ID provided does not exist in our records.

HTTP Status Code: 403

I have double-checked that I am using the exact same IAM credentials as I used through the CLI and that IAM user has a policy allowing read/write access to the queue. I have also toyed around with sending the additional URL params accessKey, secretKey, amazonSQSEndpoint and region as documented by Camel.

Why is Amazon saying that the access key is invalid or doesn't exist in their records and how can I fix my request?

Answer

Keet Sugathadasa picture Keet Sugathadasa · Apr 29, 2018

When faced with a situation like this, there are two ways to trouble shoot this.

Option 1: Check the credentials in the ~/.aws/credentials file, where there can be mistakes made in the access key and secret. The probability of getting this wrong is very less, but it could happen.

Option 2: Provide the IAM user with necessary permissions, and check whether the issue gets recreated. If it's your very own AWS account, do give AmazonSQSFullAccess and carry out your work. In this sense, you will not easily run into any permission issues. Also check this link, where it mentions the minimum set of permissions requires for a user to work with AWS SQS.

Since the status code of the response is 403 (forbidden), this definitely has to be something related to authorization. I know my answer is coming two years later, but I once faced with a similar issue, and this worked.