AWS IAM User vs Role: What is the Difference?

Quick Definition

• IAM User — a long-lived identity in an AWS account, with credentials (password and/or access keys) that don't expire automatically.
• IAM Role — a temporary identity that any allowed principal can assume via AWS STS, getting short-lived credentials.

In simple terms:

A user is a permanent identity; a role is a costume any allowed principal can put on for a limited time.

---

Why the Difference Matters

• Roles eliminate long-lived credentials, the biggest contributor to AWS credential leaks.
• Roles enable federation, cross-account access, and service identity in a clean, auditable way.
• The AWS security best-practice guidance increasingly says: prefer roles to users.

---

Side-by-Side Comparison

Aspect	IAM User	IAM Role
Credential lifetime	Long-lived (until rotated)	Short-lived (15 min – 12 h)
Credentials	Console password, access keys	Temporary STS credentials
Who can be it	Itself only	Anyone allowed by trust policy
Trust policy	N/A	Defines who can assume
Common use	Persistent human or app identity	Service identity, federation, cross-account, JIT
Console sign-in	Direct	Via federation / switch role
MFA support	Yes	Yes (enforced via condition)
Best fit	Limited / break-glass	Most modern scenarios

---

When to Use IAM Users

• Small AWS deployments without Identity Center.
• Specific legacy automation that can't use roles.
• Break-glass account in single-account setups.
• External integrations that strictly need an access key (rare in modern services).

For most other cases, you should use roles.

---

When to Use IAM Roles

• Human access — through IAM Identity Center, which materializes as roles in accounts.
• EC2 instance access — via instance profile.
• Lambda execution — via execution role.
• ECS / EKS task — task role.
• Cross-account access — principal in account A assumes role in account B.
• CI/CD — GitHub Actions / GitLab use OIDC federation to assume a role with no stored secrets.
• Federated SSO — SAML / OIDC users assume role on sign-in.
• AWS services acting on your behalf — service roles (CodePipeline, Backup, EventBridge, etc.).

---

Mechanics of Role Assumption

sts:AssumeRole

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name dev-session

Returns:

• AccessKeyId
• SecretAccessKey
• SessionToken
• Expiration (typically 1 hour by default)

These credentials are used like normal IAM keys but expire automatically.

Trust Policy Example

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-external-id" }
    }
  }]
}

This trust policy lets account 111111111111's principals assume the role, requiring an external ID.

---

Federation Patterns

• SAML 2.0 — sign in via SAML IdP (Entra ID, Okta, ADFS).
• OIDC — sign in via OIDC IdP (GitHub Actions, GitLab, Kubernetes ServiceAccounts via IRSA, Auth0).
• IAM Identity Center — AWS-managed SSO; integrates with external IdPs, materializes as Permission Set–backed roles.

All these eliminate the need for IAM Users and long-lived keys.

---

Real-World Examples

1. Eliminating IAM User for CI/CD

Old: GitHub Actions used an IAM User's access key stored as a GitHub secret. Periodic key leaks.

New: GitHub Actions uses OIDC federation to AssumeRole. No stored credentials.

2. EC2 Application Reading from S3

Old: Application read access key from config file.

New: Instance profile attaches a role; SDK reads temporary credentials from IMDSv2.

3. Multi-Account Human Access

Old: One IAM User per person per account = chaos at scale.

New: Identity Center provides centralized SSO; users get role credentials per account on sign-in.

4. Cross-Account Auditor

Auditor in account A assumes AuditorRole in account B with external ID. No keys; full audit trail in CloudTrail.

---

Common Pitfalls

• Trust policy too broad. Principal: * or large account lists.
• No external ID for cross-account access from third parties (Confused Deputy).
• Long session durations without justification.
• Access keys created on roles (not possible — but key creation on IAM Users is common).
• Mixing users and roles without naming convention or governance.
• Service roles with Administrator — overkill for most services.

---

Best Practices

1. Default to roles. Use IAM Users only when truly necessary.
2. Use Identity Center for human access.
3. Use OIDC federation for CI/CD.
4. Use service roles for EC2, Lambda, ECS, EKS, etc.
5. Tight trust policies — minimum principals, MFA conditions where applicable.
6. External ID for third-party cross-account access.
7. Short session durations by default.
8. Periodic review of roles and assumed-role activity.
9. CloudTrail monitoring of AssumeRole events.
10. Tag roles with owner and purpose.
11. For remaining users: MFA, short-lived access keys (rotate ≤ 90 days).

---

Checklist

• Identity Center used for human access?
• OIDC federation for CI/CD?
• Roles used for all EC2 / Lambda / ECS / EKS?
• IAM User count minimized; remaining users justified?
• Trust policies tight; external ID for third parties?
• Session durations appropriate?
• Roles tagged with owner?
• CloudTrail monitoring on assume-role events?

---

How Forestall Helps

Forestall identifies:

• IAM Users that could be migrated to Identity Center / federation.
• Long-lived access keys with no recent rotation.
• Risky trust relationships (broad principals, missing external ID).
• Roles with excessive permissions or session durations.
• Privilege escalation paths via role-assumption chains.

---

Frequently Asked Questions

Are IAM Users deprecated?

Not officially, but AWS guidance strongly favors roles + Identity Center for most use cases.

Can I have a user without access keys?

Yes — console-only users or for break-glass scenarios.

What about MFA?

Both users and roles support MFA. Enforce via condition aws:MultiFactorAuthPresent: true for sensitive actions.

Can roles have access keys?

No — roles use temporary credentials issued by STS on assumption.

What's the longest a role session can last?

Up to 12 hours (configurable per role; chained sessions max 1 hour).

---

Conclusion

IAM Users and IAM Roles serve different purposes in AWS. Roles, with their temporary credentials and assumable model, are the modern default — eliminating long-lived secrets, enabling clean cross-account and federation flows, and providing better audit trails. Reserve IAM Users for break-glass and edge cases; do everything else with roles + Identity Center + federation, and watch credential-leak risk fall sharply.