IAM Role vs IAM User: What's the Difference and When to Use Each

Definition

An IAM user is a long-lived AWS identity that belongs to one person or application and authenticates with a password (for the console) and/or access keys (for the API). An IAM role is an AWS identity with no permanent credentials — principals assume it through AWS Security Token Service (STS) and receive short-lived access keys plus a session token that expires automatically.

At a glance they look similar — both can have IAM policies attached — but they are deployed very differently in practice. AWS guidance since 2023 is unambiguous: use IAM roles (and IAM Identity Center for humans) wherever possible, and minimize or eliminate IAM users with long-lived access keys.

How It Works

IAM User

Created via IAM console, CLI, or CloudFormation with a unique name (alice, deploy-bot).
Can have a console password (with optional MFA) and/or up to two active access key pairs (AKIA... / secret).
Authenticates every API call by signing it with SigV4 using its access keys. The keys do not expire until rotated or deleted.
Can belong to IAM groups, inheriting their attached policies.
Ideal candidates for replacement: service accounts with baked-in keys, CI/CD runners with secrets in env vars, CLI users without SSO.

IAM Role

Created with two distinct documents: a trust policy (who may assume it) and one or more permissions policies (what the resulting session may do).
No keys of its own. A principal calls sts:AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity to get temporary credentials that expire in 15 minutes to 12 hours.
Assumed transparently by AWS services: EC2 via an instance profile, Lambda via its execution role, ECS via task roles, CodeBuild, Glue, Step Functions, and more.
Humans can assume roles through IAM Identity Center (formerly AWS SSO), corporate SAML, or aws sts assume-role with an external IdP.

The Practical Difference

With an IAM user, a stolen access key is usable until somebody notices and rotates it — potentially months. With an IAM role, a stolen session token is usable only until it expires (typically one hour), and the next refresh produces completely different credentials. This difference alone prevents most long-tail credential-leak incidents.

Key Features and Limits

Account limits — IAM users: 5,000 per account. IAM roles: 1,000 per account by default (both can be raised via Service Quotas).
Access keys per user — up to 2 active (so you can rotate without downtime).
Console access for roles — only via federation (Identity Center, SAML) or the AWS console's Switch Role feature; roles never have their own password.
Session duration — 15 minutes to role's MaxSessionDuration (1–12 h, default 1 h). Role chaining caps at 1 h. IAM user credentials don't expire.
MFA — users can have MFA devices enforced by an IAM policy condition. Roles can require aws:MultiFactorAuthPresent in their trust policy or permissions policy.
Instance profiles — the container that wraps a role when attached to an EC2 instance. Only one instance profile per instance.
Service-linked roles — special roles whose lifecycle is managed by an AWS service (e.g., AWSServiceRoleForAutoScaling). Cannot be converted to ordinary roles.
Audit — both are logged in CloudTrail; role sessions additionally carry a sts:SourceIdentity field when configured, making attribution easier across role chains.

Common Use Cases

Workload permissions (always roles) — EC2 instance profiles, Lambda execution roles, ECS task roles, EKS IRSA/Pod Identity, Glue/SageMaker jobs.
Human access at scale (always roles via IAM Identity Center) — federate your corporate IdP (Okta, Microsoft Entra, Google) and grant role-based permission sets across many AWS accounts.
Cross-account access (always roles) — trust Account A from Account B's role so pipelines can deploy cross-account without sharing keys.
Third-party integrations (always roles with external ID) — monitoring or FinOps vendors assume a role in your account; the External ID condition prevents confused-deputy attacks.
CI/CD (roles with OIDC) — GitHub Actions, GitLab CI, CircleCI, Buildkite all support OIDC federation to assume AWS roles without long-lived secrets.
IAM users (narrow edge cases) — legacy on-premises scripts that can't federate, programmatic AWS access from environments that predate role-compatible SDK builds, or emergency break-glass accounts protected by hardware MFA.

Pricing Model

Both IAM users and IAM roles are free. IAM and AWS STS do not charge per identity, per policy, or per API call. You pay only for the downstream AWS services the authenticated requests touch (S3 GETs, DynamoDB reads, etc.).

AWS Free Tier coverage is moot because IAM is already free. IAM Access Analyzer's external access findings are free, while unused access analysis and custom policy checks carry a small per-resource or per-evaluation cost.

Pros and Cons

IAM User — Pros

Simple mental model: a username plus secret — similar to traditional Linux/Unix accounts.
Works everywhere, including legacy tools that don't understand STS refresh flows.

IAM User — Cons

Long-lived access keys are the leading cause of AWS credential leaks (GitHub commits, leaked container images, forgotten .env files).
Manual rotation — humans tend to skip it, especially for service accounts.
Scales poorly across many accounts; every account needs its own user database.

IAM Role — Pros

Short-lived credentials minimize blast radius on leak.
Automatic rotation; SDKs refresh transparently.
Decouples who can assume from what they can do, enabling clean layering with SCPs and permission boundaries.
Native support across every AWS service for workloads.

IAM Role — Cons

Steeper learning curve: trust policies, STS APIs, role chaining, session policies.
Federation setup (SAML/OIDC) takes time and usually involves a separate identity provider.
Role chaining caps at one hour, which can surprise long-running batch jobs.

Comparison with Alternatives

| Attribute | IAM User | IAM Role | IAM Identity Center Permission Set | | --- | --- | --- | --- | | Credentials | Long-lived password / access keys | Temporary STS session | Temporary STS session (wraps a role) | | Rotation | Manual | Automatic | Automatic | | Best for | Rare edge cases | Workloads + cross-account | Human SSO across many accounts | | Federation support | Console + keys only | SAML 2.0 + OIDC + AssumeRole | Native (IdP → Identity Center → role) | | AWS recommendation today | Minimize | Preferred for workloads | Preferred for humans |

Exam Relevance

Expect to see user-vs-role questions on:

Cloud Practitioner (CLF-C02) — basic distinction between users, groups, and roles.
Solutions Architect Associate (SAA-C03) — instance profiles, cross-account scenarios, choosing roles over access keys.
Developer Associate (DVA-C02) — Lambda execution roles, Cognito Identity Pools, SDK credential provider chain, preferring IMDS-sourced role credentials over embedded keys.
Security Specialty (SCS-C02) — federation patterns, trust policies, external IDs, permissions boundaries.

Classic exam trap: a scenario that describes an application on EC2 with access keys hardcoded in the AMI. The best answer is never "rotate the keys more often"; it is "replace the keys with an IAM role attached via an instance profile." Similarly, for GitHub Actions to AWS, the right answer is OIDC federation to an IAM role, not storing access keys as GitHub secrets.

Frequently Asked Questions

Q: Why does AWS recommend IAM roles over IAM users?

A: Because roles deliver short-lived, automatically rotating credentials instead of long-lived access keys that sit on disk. Most credential-leak incidents trace back to IAM user access keys committed to Git, baked into AMIs/containers, or leaked in logs — problems that effectively disappear when the workload uses a role (instance profile, Lambda execution role, or OIDC-federated CI role) and the human uses IAM Identity Center. Roles also provide cleaner cross-account access and better audit trails via STS session context.

Q: Can an IAM role be used by a human instead of by an AWS service?

A: Yes. Humans assume roles all the time — via IAM Identity Center (the modern default), via SAML 2.0 federation from a corporate IdP, via the console's Switch Role feature across accounts, or via aws sts assume-role on the CLI. In each case the human is authenticated by the IdP (or by their base IAM credentials) and is then issued a temporary role session. This is strictly better than giving each person an IAM user in every account.

Q: When is it still acceptable to use an IAM user?

A: Narrow edge cases: legacy on-premises scripts that cannot integrate with STS refresh or OIDC; old SDKs that predate the modern credential provider chain; emergency break-glass accounts that are deliberately static and protected by hardware MFA; or specific third-party tools that explicitly require long-lived keys. Even in these cases, favor access key rotation every 90 days, MFA enforcement, and tight permission boundaries — and revisit whether IAM Identity Center or an OIDC-federated role can replace the user.

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