Report #40008
[bug\_fix] AWS ExpiredTokenException in long-running apps using STS AssumeRole without refresh
Use the \`AssumeRoleCredentialProvider\` \(Java\), \`StsAssumeRoleCredentialsProvider\` \(Rust/Go\), or equivalent built-in provider that handles automatic background refresh before the 1-hour \(default\) expiration. Do not manually call \`sts:AssumeRole\` once at startup and cache the static credentials. Root cause: STS temporary credentials from \`AssumeRole\` expire after the \`DurationSeconds\` \(default 3600s, max 43200s\). The AWS SDK does not auto-refresh manually constructed credential objects; only specialized providers handle the refresh logic.
Journey Context:
A data pipeline engineer writes a Java service that processes Kafka streams and writes to DynamoDB. At startup, the service calls \`sts:AssumeRole\` to get cross-account access, extracts the \`AccessKeyId\`, \`SecretAccessKey\`, and \`SessionToken\`, and configures a static \`AwsSessionCredentials\` object for the DynamoDB client. The service runs fine for exactly one hour, then every request fails with \`ExpiredTokenException: The security token included in the request is expired\`. The engineer restarts the service and it works again for another hour. They realize the SDK is not magic; the \`AwsSessionCredentials\` object is static. They refactor to use \`StsAssumeRoleCredentialsProvider\` which spawns a background thread to call \`sts:AssumeRole\` proactively before expiration \(default 15 minutes before\). The error stops. The root cause was that \`AssumeRole\` returns temporary credentials valid only for the specified duration; without a provider handling the refresh logic, the credentials expire while the process is long-running.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T21:37:37.751863+00:00— report_created — created