IAM Role vs User: When to Use Which?

Key Takeaway

IAM Roles use temporary credentials; IAM Users use long-term credentials. When EC2, Lambda, or other AWS services need to access other services, always use roles. Users are only for real people logging into the console.

Core Differences: IAM Role vs User

Quick Comparison

Aspect	IAM User	IAM Role
For	People, specific applications	AWS services, temporary access
Credentials	Long-term (password, Access Key)	Temporary (STS token)
Expiration	Manual rotation required	Auto-expire (default 1 hour)
Association	1:1 with specific person/system	Anyone can assume if authorized
Security risk	Key leak = permanent risk	Token leak = time-limited
AWS recommendation	Limited use	Strongly recommended

Long-term vs Temporary Credentials

IAM User (Long-term Credentials)
├── Access Key ID: AKIAXXXXXXXXXXXXXXXX
└── Secret Access Key: Fixed value (valid until rotated)
    └── Risk: If leaked, exploitable until deleted

IAM Role (Temporary Credentials)
├── Access Key ID: ASIAXXXXXXXXXXXXXXXX (temporary)
├── Secret Access Key: Temporary value
├── Session Token: Required
└── Expiration: Auto-expires in 1-12 hours
    └── Benefit: Leaks have limited damage window

When Should You Use IAM Roles?

1. AWS Services Accessing Other Services (Required!)

The most important use case. When EC2, Lambda, ECS need to access S3, DynamoDB, etc., always use roles.

❌ Wrong Method (Never do this!)
Hardcode Access Keys in EC2 instance code
  └── Security risk: Code leak = key leak

✅ Correct Method (AWS Recommended)
Attach IAM role to EC2 instance
  └── Auto-retrieves temporary credentials from instance metadata

Example scenarios:

• EC2 instance reading files from S3 bucket
• Lambda function writing to DynamoDB
• ECS task retrieving secrets from Secrets Manager

2. Cross-Account Access

Use roles when accessing resources in another AWS account.

Account A (Resource Owner)          Account B (Needs Access)
┌─────────────────┐              ┌─────────────────┐
│  S3 Bucket      │              │  IAM User       │
│                 │              │  (Developer)    │
│  IAM Role       │◄─ Assume ────│                 │
│  - Trust Policy:│    Role      │  Permission:    │
│    Allow Acct B │              │  sts:AssumeRole │
└─────────────────┘              └─────────────────┘

3. External Identity Provider (IdP) Federation

Use roles when authenticating via SAML 2.0 or OpenID Connect for enterprise SSO.

Enterprise User
  ↓ (Corporate IdP Authentication)
Active Directory / Okta / Google
  ↓ (SAML Assertion or OIDC Token)
AWS STS (AssumeRoleWithSAML / AssumeRoleWithWebIdentity)
  ↓ (Temporary Credentials Issued)
Access AWS Resources

4. Temporary Privilege Escalation

Pattern where you have read-only access normally, but assume an admin role when needed.

Developer (Default: ReadOnly)
  ↓ Assume Admin Role (MFA Required)
Admin Role (Temporary, 1 hour)
  ↓ Task Complete
Back to ReadOnly state

When Should You Use IAM Users?

AWS recommends IAM Identity Center (SSO) first; use IAM users only when that's not possible.

Cases Requiring IAM Users

Use Case	Description
Workloads not supporting roles	WordPress plugins, etc. that can't use temporary credentials
Third-party tools	Clients not supporting IAM Identity Center
Emergency access	Break-glass accounts for IdP failures
CodeCommit SSH keys	When Git SSH authentication is needed
Amazon Keyspaces	Cassandra-compatible service access

How Role Assumption Works

Assume Role Process

1. Requester → AWS STS: Call AssumeRole
   └── Role ARN + (optional) External ID, Session Name

2. STS: Check Trust Policy
   └── "Is this requester allowed to assume this role?"

3. STS → Requester: Return Temporary Credentials
   ├── AccessKeyId (starts with ASIA)
   ├── SecretAccessKey
   ├── SessionToken
   └── Expiration

4. Requester: Call AWS APIs with temporary credentials

Trust Policy Example

Defines who can assume the role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Principal types:

• "Service": "ec2.amazonaws.com" - AWS service
• "AWS": "arn:aws:iam::123456789012:root" - Another account
• "AWS": "arn:aws:iam::123456789012:user/DevUser" - Specific user

Service Role vs Service-Linked Role

Service Role

• AWS service assumes to perform work
• Created and managed by user
• Permissions editable

Examples: EC2 instance role, Lambda execution role

Service-Linked Role

• Automatically created and managed by AWS
• Permissions not editable (AWS managed)
• Can only delete after related resources are deleted

Examples: AWSServiceRoleForAutoScaling, AWSServiceRoleForElasticLoadBalancing

Role Chaining

Using one role's temporary credentials to assume another role.

User → Role A → Role B → Role C
       (assume) (assume) (assume)

Limitation:

• Maximum session duration: 1 hour (regardless of role settings)
• Even if role allows 12 hours, chaining limits to 1 hour

SAA-C03 Exam Focus Points

1. ✅ EC2/Lambda accessing other services: Always IAM role (never hardcode Access Keys)
2. ✅ Temporary vs long-term credentials: Role = temporary (auto-expire), User = long-term (manual rotation)
3. ✅ Cross-account access: Role + trust policy
4. ✅ Service-linked roles: AWS managed, not editable
5. ✅ Role chaining limit: Max 1 hour session

Frequently Asked Questions

Q: Why are IAM User Access Keys dangerous?

Access Keys are permanent credentials. If included in code or committed to Git, they're exploitable until deleted. Role temporary credentials auto-expire, limiting damage from leaks.

Q: How does an EC2 instance with an attached role get credentials?

EC2 provides credentials automatically via the Instance Metadata Service (IMDS). SDKs handle this automatically—no code configuration needed.

http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

Q: What happens to original permissions when assuming a role?

When you assume a role, you temporarily give up original permissions. Only the role's permissions are available. Original permissions return when the role session ends.

Q: Can a user assume multiple roles simultaneously?

Not simultaneously. But you can chain from one role to another. Session duration is limited to 1 hour when chaining.

Q: I can't delete a service-linked role.

Service-linked roles require deleting related resources first. For example, delete all Auto Scaling groups before you can delete AWSServiceRoleForAutoScaling.

Related Posts

• IAM Basics: Users, Groups, Roles, and Policies
• IAM Policy Evaluation Logic
• AWS Organizations & SCP Guide

References

• AWS IAM Roles
• IAM Users
• When to Use IAM Roles
• Temporary Security Credentials