AWS STS AssumeRole: What It Is and When to Use It

Definition

AssumeRole is an API operation within the AWS Security Token Service (STS) that enables an AWS Identity and Access Management (IAM) principal (like a user or another role) to obtain temporary security credentials to operate as a different IAM role. This action is central to delegating access securely across AWS accounts or within a single account, allowing entities to access resources they don't normally have permissions for, without needing long-term credentials.

How It Works

The AssumeRole process involves a trusted relationship between the principal making the call (the caller) and the role being assumed (the target role). The core of this interaction is governed by two types of IAM policies:

1. Permissions Policy on the Caller: The IAM user or role initiating the AssumeRole call must have an identity-based policy that explicitly allows the sts:AssumeRole action for the target role's Amazon Resource Name (ARN).

2. Trust Policy on the Target Role: The target role must have a resource-based policy known as a trust policy. This policy specifies which principals (accounts, users, services, or other roles) are trusted and allowed to assume it.

The Request Flow:

1. An IAM principal makes a call to the sts:AssumeRole API, providing the ARN of the role to be assumed and a unique RoleSessionName to identify the session in logs.
2. AWS STS validates the request by checking both the caller's permissions policy and the target role's trust policy. Both must grant permission for the action to succeed.
3. If the request is valid, STS generates and returns a set of temporary security credentials consisting of an Access Key ID, a Secret Access Key, and a Session Token.
4. The original principal then uses these temporary credentials to make API calls. For the duration of the session, it operates with the permissions granted by the permissions policies attached to the assumed role, not its original permissions.

The permissions of the resulting session are the intersection of the role's identity-based policies and any optional session policies passed during the AssumeRole call. Session policies can further restrict permissions for the temporary session but cannot grant more permissions than the role's policies already allow.

Key Features and Limits

• Session Duration: The duration of the temporary credentials can be specified using the DurationSeconds parameter. This can range from a minimum of 900 seconds (15 minutes) to a maximum defined on the role, which can be up to 12 hours. If not specified, the default session duration is 1 hour.
• Role Chaining: This occurs when you use temporary credentials from one role to assume a second role. Role chaining limits the session duration of the second role to a maximum of one hour, regardless of the role's maximum duration setting.
• External ID: A unique identifier that can be used by a third party to assume a role in your account. It is a crucial security feature to mitigate the "confused deputy" problem, where a trusted entity could be manipulated into misusing its permissions.
• Session Policies: Optional managed or inline policies that can be passed during the AssumeRole call to scope down the permissions of the temporary session. You can pass up to 10 managed policy ARNs and one inline policy. The total size of these policies cannot exceed 2,048 characters.
• Session Tags: You can pass key-value pairs as session tags, which can be used for attribute-based access control (ABAC) in policies or for cost allocation and tracking. You can pass up to 50 session tags.
• Source Identity: An attribute that can be set by the principal assuming the role to indicate who the original user was. This identity is passed along in role chaining and can be audited in AWS CloudTrail logs.
• STS API Quotas: By default, the AssumeRole operation shares a quota of 600 requests per second per account per Region with other STS operations.

Common Use Cases

1. Cross-Account Access: This is the most common use case. A user or application in a 'development' account (Account A) can assume a role in a 'production' account (Account B) to access its resources, such as an Amazon S3 bucket or an Amazon RDS database. This avoids the need to create and manage duplicate IAM users across accounts.

2. Federated Access for Human Users: AssumeRole is used to grant temporary AWS access to users authenticated through an external Identity Provider (IdP) like Active Directory (via SAML 2.0) or a social provider like Google or Facebook (via OpenID Connect). The user authenticates with the IdP, which then allows them to call an STS operation like AssumeRoleWithSAML or AssumeRoleWithWebIdentity to get temporary AWS credentials.

3. Permissions Delegation for AWS Services: Many AWS services act on your behalf by assuming an IAM role. For example, you can grant an Amazon EC2 instance permissions to read from an S3 bucket by attaching an IAM role to it. The EC2 service assumes this role to get temporary credentials for the instance to use.

4. Temporary Privilege Escalation: A user with a limited set of permissions can temporarily assume a role with more specific, elevated privileges to perform a sensitive task, such as deploying an application or modifying a database schema. This adheres to the principle of least privilege.

Pricing Model

AWS Security Token Service (STS) and the AssumeRole API operation are offered at no additional charge. You only pay for the underlying AWS resources that are consumed or accessed by the temporary credentials obtained through AssumeRole.

Pros and Cons

Pros:

• Enhanced Security: Replaces the need for long-lived IAM user access keys with short-term, automatically rotating credentials, significantly reducing the risk of compromised keys.
• Least Privilege: Enables fine-grained access control by allowing entities to obtain only the permissions they need, for only as long as they need them.
• Centralized Access Management: Simplifies managing access for users and applications, especially in multi-account environments, by centralizing role definitions.
• Auditing and Traceability: Actions performed by an assumed role can be tracked in AWS CloudTrail, which logs the role session name and source identity to identify who performed the action.

Cons:

• Increased Complexity: Managing trust policies, role permissions, and session policies can be complex, especially at scale. Debugging permissions issues can involve analyzing multiple policies.
• Role Chaining Limitations: The one-hour maximum session duration for chained roles can be a constraint for long-running automated tasks that require assuming multiple roles in sequence.
• Confused Deputy Risk: If not configured correctly with mechanisms like the ExternalId condition, cross-account roles can be vulnerable to the confused deputy problem.

Comparison with Alternatives

AssumeRole vs. Resource-Based Policies

• Identity: When a principal uses AssumeRole, it surrenders its original permissions and takes on the identity and permissions of the role. With a resource-based policy (e.g., an S3 bucket policy), the principal retains its original identity and permissions while gaining additional access to the specific resource.
• Scope: AssumeRole is ideal for granting broad access to multiple resources and services within an account. A resource-based policy is scoped to a single resource and is better for granting granular access to specific resources without the overhead of role assumption.
• Scalability: For managing access for many principals or across many resources, IAM roles are generally more scalable and flexible than managing individual resource policies.

Exam Relevance

Understanding AssumeRole is fundamental for nearly all AWS certifications, as it's a core security and architecture concept.

• AWS Certified Solutions Architect - Associate (SAA-C03): Expect questions on cross-account access patterns and choosing between IAM roles and resource-based policies.
• AWS Certified Developer - Associate (DVA-C02): Focuses on how applications use STS to get temporary credentials to access AWS services securely.
• AWS Certified Security - Specialty (SCS-C01): Requires a deep understanding of trust policies, the confused deputy problem, ExternalId, session policies, and auditing assumed role actions.
• AWS Certified Solutions Architect - Professional (SAP-C02): Tests complex multi-account strategies, federated access patterns, and limitations like role chaining.

Frequently Asked Questions

Q: What is the difference between an IAM user and an IAM role?

A: An IAM user has permanent, long-term credentials (a password for console access and access keys for programmatic access) and represents a specific person or application. An IAM role does not have its own long-term credentials; instead, it is an identity that trusted entities (like IAM users, applications, or AWS services) can assume temporarily to gain a specific set of permissions.

Q: What is the "confused deputy" problem and how does ExternalId help?

A: The confused deputy problem is a security vulnerability where an entity with permission to perform actions is tricked by a malicious third party into misusing its authority. In the context of AssumeRole, this can happen when a third-party service is given access to your account. A malicious actor could provide your role's ARN to that service, tricking it into acting on their behalf in your account. The ExternalId parameter prevents this by adding a condition to the role's trust policy, requiring the assuming party to provide a unique, secret identifier that only you and the legitimate third party should know.

Q: How do I troubleshoot "Access Denied" errors when calling AssumeRole?

A: An "Access Denied" error when calling AssumeRole typically stems from one of two policy issues. First, verify that the IAM user or role making the call has an identity-based policy allowing the sts:AssumeRole action on the target role's ARN. Second, check the trust policy of the target role to ensure it explicitly lists the caller's account or principal as trusted. Both policies must grant access for the call to succeed.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.