AWS IAM Role: What It Is and When to Use It

Definition

An AWS Identity and Access Management (IAM) role is an AWS identity with a permissions policy attached but no long-lived credentials of its own. Instead, principals (AWS services, IAM users, federated identities, or other roles) assume the role via AWS Security Token Service (STS) and receive short-lived credentials — an access key ID, a secret access key, and a session token — that expire automatically. Roles are the recommended way to grant access to AWS for workloads and cross-account scenarios.

Because the credentials are temporary (typically 15 minutes to 12 hours), a leaked role session is far less dangerous than a leaked long-lived access key. Roles are also the foundation for federation from corporate identity providers, SSO via IAM Identity Center, and workload authorization without embedding secrets.

How It Works

An IAM role has two distinct policy documents:

• Trust policy (also called the assume-role policy) — a resource-based policy on the role that answers the question "who may assume this role?". It names principals such as an AWS service (ec2.amazonaws.com, lambda.amazonaws.com), another AWS account, a SAML provider, or an OIDC provider (for example, the GitHub Actions OIDC endpoint).
• Permissions policy — one or more identity-based policies attached to the role describing "what may the role's session do?". These are standard JSON policies with Effect, Action, Resource, and Condition elements.

To use a role, a principal calls one of the STS AssumeRole* APIs — AssumeRole (IAM principals), AssumeRoleWithSAML (SAML 2.0 federation), or AssumeRoleWithWebIdentity (OIDC/Cognito/mobile). STS verifies the trust policy, mints temporary credentials, and returns them. For AWS services, this assumption is transparent: you attach the role and the service does the STS call on your behalf.

For EC2, the role is attached via an instance profile — a container object with the same name as the role that the instance is launched with. The instance metadata service (IMDS, v2 required since 2024 for new instances) exposes the credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> and the AWS SDKs pick them up automatically. Lambda, ECS tasks, CodeBuild, and other services have their own execution-role equivalents.

Key Features and Limits

• Session duration — configurable between 1 hour and 12 hours (default 1 hour) via the MaxSessionDuration on the role. AssumeRoleWithSAML and AssumeRoleWithWebIdentity cap at 12 hours; role chaining (role → role) caps at 1 hour.
• 1,000 IAM roles per AWS account by default (quota can be raised).
• 10 managed policies per role; additional permissions can be added inline (role inline policy limit: 10,240 characters).
• Trust policy size — 2,048 characters for the assume-role policy document.
• External ID — a shared secret condition key (sts:ExternalId) used by third-party vendors to prevent the confused deputy attack when they assume a role in your account.
• Source identity — sts:SourceIdentity lets you carry a user-identifying string into CloudTrail across role chains.
• Role tags and session tags — both are available for ABAC (attribute-based access control); session tags can be passed during AssumeRole and consumed by condition keys like aws:PrincipalTag/Team.
• Service-linked roles — special roles predefined by AWS services (e.g., AWSServiceRoleForAutoScaling) whose trust policy and permissions are managed by the service itself.
• Revocation — you cannot revoke individual session tokens, but attaching an inline AWSRevokeOlderSessions-style policy that denies actions where aws:TokenIssueTime is earlier than now invalidates outstanding sessions.

Common Use Cases

1. EC2 instance profiles — grant applications on EC2 AWS API access without storing access keys on disk.
2. Lambda execution roles — every Lambda function must have a role that allows it to write CloudWatch Logs and access any other AWS resources it needs.
3. ECS / EKS task roles — fine-grained permissions per container, distinct from the node/instance role.
4. Cross-account access — a role in Account B with a trust policy naming Account A lets pipelines, admins, or services from A deploy into B.
5. Federated human access — SAML 2.0 (Okta, Azure AD) or OIDC (Google, Cognito) identities exchange their IdP token for an STS session.
6. CI/CD with OIDC (e.g., GitHub Actions) — avoids long-lived keys by having the runner exchange a signed OIDC token for a role session.

Pricing Model

IAM roles and AWS STS are free to use. You pay only for the AWS API calls the role makes to other services (S3 GETs, DynamoDB reads, etc.). There is no per-session charge, no per-role charge, and no data transfer for STS responses.

AWS Free Tier does not need to cover IAM because it is already free. IAM Access Analyzer's external-access findings are also free, while its unused-access analysis and custom-policy checks are priced per analyzed resource or evaluation.

Pros and Cons

Pros

• No long-lived credentials on disk, dramatically reducing leak blast radius.
• Automatic credential rotation every time the session refreshes.
• First-class support in every AWS SDK and CLI (aws sts assume-role, credential_process, SSO profiles).
• Clean separation of who can assume (trust policy) and what they can do (permissions policy).

Cons

• Trust policies are powerful and easy to mis-scope (e.g., allowing "Principal": {"AWS": "*"} without conditions creates a confused-deputy risk).
• Role chaining is capped at 1 hour, which can surprise long-running batch workflows.
• Debugging an AccessDenied across multiple assume-role hops requires reading CloudTrail carefully for the right session context.

Comparison with Alternatives

| | IAM Role | IAM User | IAM Identity Center Permission Set | | --- | --- | --- | --- | | Credential type | Temporary (STS) | Long-lived | Temporary (STS, under the hood) | | Intended for | Workloads, federation, cross-account | Legacy; scripts without SSO | Human SSO access to many accounts | | Rotation | Automatic | Manual | Automatic | | Best practice today | Use for all workloads and federation | Minimize usage | Use for all human access |

Exam Relevance

IAM roles are core material on:

• Solutions Architect Associate (SAA-C03) — instance profiles, cross-account access patterns, Lambda execution roles.
• Developer Associate (DVA-C02) — writing trust policies for Cognito Identity Pools, STS AssumeRoleWithWebIdentity, SDK credential provider chain.
• Security Specialty (SCS-C02) — external IDs, session policies, permissions boundaries on roles, role chaining caveats.
• Also touched on in SysOps (SOA-C02) and SAP (Professional).

Classic exam trap: candidates confuse the trust policy (controls who can assume) with the permissions policy (controls what the session does). A question saying "the service can assume the role but gets AccessDenied when calling S3" points to the permissions policy; "AccessDenied on AssumeRole" points to the trust policy (or an SCP).

Frequently Asked Questions

Q: What is the difference between a trust policy and a permissions policy on an IAM role?

A: The trust policy is attached to the role and controls who can assume it — typically an AWS service principal, another account, or a federated identity provider. The permissions policy is one or more identity-based policies that control what the resulting role session can do once assumed. Both must allow the request: if the trust policy blocks the AssumeRole call, the session is never created; if the permissions policy blocks an action, the API call during the session fails with AccessDenied.

Q: How long do IAM role credentials last?

A: STS credentials from AssumeRole last between 15 minutes and the role's MaxSessionDuration (1–12 hours, default 1 hour). AssumeRoleWithSAML and AssumeRoleWithWebIdentity cap at 12 hours, and role chaining (one role assuming another) caps at 1 hour regardless of the target's MaxSessionDuration. SDKs automatically refresh credentials when they near expiration.

Q: When should I use an IAM role instead of an IAM user?

A: Use an IAM role whenever possible — for EC2 instances, Lambda functions, ECS/EKS tasks, cross-account access, and federated human access through IAM Identity Center. Reserve IAM users for edge cases where no alternative exists (for example, a legacy on-premises script that cannot federate). Roles eliminate long-lived credentials, rotate automatically, and produce cleaner CloudTrail audit trails.

---

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