A developer is deploying a Java application to an Amazon ECS cluster running on AWS Fargate. The application uses the AWS SDK for Java to write logs to an Amazon CloudWatch Logs group. The ECS task is configured with an IAM task role that has the necessary permissions to write to CloudWatch. However, the container definition also contains the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, which contain temporary credentials used during a previous CI/CD test run. When the application runs, it fails to write logs and throws an ExpiredTokenException. Which action should the developer take to resolve this issue?
- AModify the application code to initialize the CloudWatch Logs client using a StaticCredentialsProvider with access keys passed as constructor arguments.
- Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition.Answer
- CUpdate the ECS task role's trust policy to include a Statement block that grants the logs:PutLogEvents action to the task execution role.
- DStore a new set of active access keys in AWS Systems Manager Parameter Store as a SecureString, and update the application code to retrieve them using the Parameter Store API on startup.
Answer
Remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition.
The correct answer is to remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables from the ECS container definition. In the AWS SDK default credential provider chain, environment variables have higher precedence than ECS container credentials. If these environment variables are set (even with expired credentials), the SDK will attempt to use them, resulting in an ExpiredTokenException. Removing them allows the SDK chain to fall back to the ECS container credentials provider, which retrieves the credentials associated with the ECS task role.
Step-by-Step Solution
Key Concept
AWS SDK Default Credential Provider Chain Precedence