Match credential lifetime to your longest job, plus a small margin. For most pipelines that means minutes to an hour, not hours. Short sessions limit what a leaked credential can do, and on AWS the default and the limits are easy to check and set.
What the limits are on AWS
An IAM role has a maximum session duration setting. AWS documents that when you call AssumeRole you can set DurationSeconds up to 43200 seconds (12 hours), depending on that role setting. The default role session is one hour.
Role chaining changes the rule. Chaining means using one role to assume a second role. AWS states that chaining limits the session to a maximum of one hour regardless of the maximum configured on individual roles, and that asking for more than an hour in a chained call fails.
| Situation | Limit |
|---|---|
| Single AssumeRole call | Up to the role setting, maximum 12 hours |
| Role chaining | One hour maximum |
| OIDC web identity from CI | Set by the role you assume and the request |
Pick a number, then test it
- Measure your slowest job end to end, including retries.
- Add a margin, for example a quarter of the runtime.
- Set the role maximum session duration to that rounded value, not the 12 hour ceiling.
- Request the shorter duration in the workflow where your tooling allows it.
- Watch for jobs that fail with expired token errors, and fix the job rather than raising the limit for everyone.
A job that needs six hours is usually two jobs. Splitting it lets each part ask for fresh credentials.
The side effects people forget
Expiry also reaches things you create with the credential. AWS notes that a presigned URL made with temporary credentials stops working when those credentials expire, even if the URL was created with a later expiration time. For an IAM role session, the URL expires when the session ends. That is useful: a leaked link cannot outlive the job that made it. It is also a common cause of surprise failures when a pipeline hands a presigned artifact link to a slower downstream system.
Long running agents and self hosted runners deserve a separate look. The AWS best practices page says workloads outside AWS, including managed CI/CD platforms, can still use temporary credentials, and lists ways to deliver them, including a web identity token exchange and a certificate based option.
Why short is worth the friction
Long lived access keys stay valid until someone rotates them. AWS recommends relying on temporary credentials instead of creating long term ones where possible. A key pasted into a CI secret store can be copied by anyone who can read the pipeline configuration, and nothing about the key says "only for this job". A session that ends in 30 minutes narrows the window even if the token is stolen mid run.
Short sessions do not replace least privilege. They sit beside it: narrow permissions limit what the credential can do, short lifetime limits how long it can do it.
Quick check
Can I give a chained role session two hours?
No. AWS says a chained session is capped at one hour, and requesting a longer duration in the chained call fails.
Why did my presigned URL stop working early?
It was probably created with temporary credentials. AWS documents that the URL expires when those credentials expire, even if you set a longer URL lifetime.
Safeguard does not manage your cloud accounts. It scans your code and dependencies, applies pull request policies and gates, and automates compliance evidence. Run a free scan at gold.safeguard.sh/scan.
Sources
- AWS IAM User Guide: Roles terms and concepts
- AWS IAM User Guide: Security best practices in IAM
- Amazon S3 User Guide: Presigned URLs
Last reviewed: 19 October 2026.
