Report #92904
[bug\_fix] The security token included in the request is expired
Re-invoke the STS AssumeRole \(or AssumeRoleWithWebIdentity\) API to obtain fresh temporary credentials \(AccessKeyId, SecretAccessKey, SessionToken\). The default lifetime is 3600 seconds \(1 hour\) unless DurationSeconds is specified \(maximum 12 hours for normal IAM roles, 1 hour for AWS SSO roles\). Implement credential refresh logic using the SDK's built-in assume role providers \(e.g., boto3's RefreshableCredentials\) or set a longer duration if the role's trust policy allows.
Journey Context:
A data engineer runs a long-running Spark ETL job on an EC2 instance to transform 500GB of data in S3 and write results to DynamoDB. The job uses temporary credentials obtained by assuming a specific IAM role via \`aws sts assume-role\` at the start of the script, storing the returned credentials in environment variables. After running successfully for 55 minutes, the job suddenly fails with 'The security token included in the request is expired' when attempting to write the final batch to DynamoDB. The engineer checks the IAM role permissions and they are correct. They check the EC2 instance profile and it's properly configured. They add debug logging and see the credentials being used are the ones from the initial assume-role call with a timestamp from an hour ago. They consult the STS documentation and realize that \`AssumeRole\` returns credentials valid for a maximum of 1 hour by default \(3600 seconds\). Since the job ran for 55 minutes and then retried for another 10 minutes after a network blip, the token expired. The fix is to either increase \`DurationSeconds\` to 7200 \(if the role's MaxSessionDuration allows\) or, better, use the AWS SDK's built-in \`AssumeRoleProvider\` which automatically refreshes the credentials before they expire by calling STS again with the role ARN.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:31:34.520601+00:00— report_created — created