AWS CLI "ExpiredToken" - Fix Expired Session Credentials in CI

The temporary STS credentials the job assumed have expired. A long-running deploy outlived the session’s duration, so AWS now rejects the token - re-assuming the role mints fresh credentials.

What this error means

A job that started fine begins failing partway through with ExpiredToken, typically after a long step. Re-running the job (which re-assumes the role) succeeds, marking this as a renewable, time-based failure rather than a permission problem.

An error occurred (ExpiredToken) when calling the UploadPart operation:
The provided token has expired.

Common causes

Session shorter than the job

OIDC/STS sessions have a max duration (often 1 hour). A deploy that runs longer than the session has its credentials expire mid-flight.

Credentials assumed too early

If the role is assumed at the start of a long pipeline and used much later, the remaining lifetime may be too short by the time the AWS call runs.

How to fix it

Re-assume the role close to the AWS work

Refresh credentials right before the long step, and raise the session duration if the role allows it.

- uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::1234567890:role/ci-deploy
    aws-region: us-east-1
    role-duration-seconds: 3600
- run: ./long-deploy.sh   # runs immediately after credentials refresh

Shorten or split the long step

1. Break a multi-hour deploy into stages so no single step outlives the session.
2. Ensure the role’s MaxSessionDuration is high enough for the longest step.
3. Re-run the job to refresh - ExpiredToken is transient and clears on a fresh assume.

How to prevent it

• Assume the role immediately before the AWS-heavy step, not at job start.
• Set role-duration-seconds to comfortably exceed the longest step.
• Split very long deploys so they fit inside one session.

Related guides