AWS `ExpiredToken`: What It Means and How to Fix It
ExpiredToken is temporary credentials that have passed their expiry time. It comes from STS, and the message reads:
The security token included in the request is expired.
If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.
Quick reference
| Error | ExpiredToken |
| Service | STS |
| Message | The security token included in the request is expired. |
| Most common cause | A long-running job outlived its credentials |
What it actually means
Temporary credentials from STS — anything with a session token — have a fixed lifetime. When it passes, every request fails with ExpiredToken or ExpiredTokenException.
Default and maximum lifetimes vary by how the credentials were obtained:
| Source | Default | Maximum |
|---|---|---|
AssumeRole |
1 hour | The role’s maximum session duration, up to 12 hours |
| Role chaining (a role assuming a role) | 1 hour | 1 hour, hard capped |
GetSessionToken with MFA |
12 hours | 36 hours |
| EC2 instance metadata | Rotated automatically | Rotated automatically |
Role chaining being capped at one hour regardless of the role’s configured maximum is the detail that surprises people building multi-account automation.
Why it happens
Ranked by how often each one turns out to be the answer.
| # | Cause | Fix |
|---|---|---|
| 1 | A long-running job outlived its credentials | A build, migration, or bulk copy that takes longer than the session. Refresh mid-run, or raise the role’s maximum session duration and request it explicitly with --duration-seconds. |
| 2 | Credentials were exported to environment variables and cached | Exported AWS_SESSION_TOKEN values do not refresh themselves. Use a profile with credential_process or sso_session so the SDK refreshes on demand. |
| 3 | Role chaining hit the one-hour cap | Assuming a role from an already-assumed role caps at one hour, even if the target role allows twelve. Assume the target role directly from the base identity where possible. |
| 4 | The container credential provider is being bypassed | On ECS and EKS the SDK fetches and refreshes credentials automatically. Code that reads them once at startup and holds them will fail an hour later. |
| 5 | An SSO session expired | IAM Identity Center sessions expire independently of the role session. aws sso login again. |
How to tell which one you have
# Who am I, and does the call work at all?
aws sts get-caller-identity
# When does the current session expire? (SSO / credential_process caches)
cat ~/.aws/cli/cache/*.json 2>/dev/null | python3 -m json.tool | grep -i expiration
cat ~/.aws/sso/cache/*.json 2>/dev/null | python3 -m json.tool | grep -i expiresAtPreventing it
Never cache credentials in application code. Every AWS SDK refreshes automatically when it obtains credentials from the instance metadata service, the ECS task role endpoint, the EKS web identity token file, or a profile — as long as you construct the client once and let the SDK own the credential chain.
The anti-pattern is reading credentials into variables at startup and constructing signed requests by hand. Construct a client instead.
Related errors
SignatureDoesNotMatch— All AWS APIsInvalidClientTokenId— STS- All AWS error references — the full index
Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.