Report #96482
[bug\_fix] The security token included in the request is expired
Configure the SDK to use the AssumeRole credentials provider with automatic refresh enabled \(e.g., STSAssumeRoleSessionCredentialsProvider in Java, StsAssumeRoleCredentialsProvider in modern SDKs, or equivalent refreshable credentials provider in boto3\). Root cause: STS temporary credentials obtained via AssumeRole expire after DurationSeconds \(default 1 hour\). The SDK does not automatically refresh these unless explicitly configured with a credentials provider that implements the refresh lifecycle by re-calling AssumeRole before expiry.
Journey Context:
You're running a long-lived ETL job on an EC2 instance that assumes a cross-account role to access S3 in another account. The job starts fine but crashes after exactly 1 hour with 'The security token included in the request is expired'. You check the IAM role attached to the instance—it has sts:AssumeRole permission. You verify the CloudTrail logs—the AssumeRole call succeeded with DurationSeconds of 3600. You realize the application is caching the credentials returned by the initial sts.assume\_role\(\) call in a global variable. The SDK isn't refreshing because you passed static credentials to the S3 client constructor instead of letting the SDK manage the credentials provider. You switch to using boto3.Session\(\).client\('s3'\) which uses the default credential chain with automatic refresh, or explicitly configure the client with a refreshable credentials provider that schedules refresh before expiration. The fix works because the credentials provider now manages the token lifecycle, proactively calling AssumeRole before the current token expires.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T20:31:45.622856+00:00— report_created — created