AWS IAM Explained: Complete Guide to Users, Groups, Roles, and Policies

Key Takeaway

IAM (Identity and Access Management) is AWS's security service that controls "who" can do "what" with AWS resources. Users are for people, Groups are collections of users, Roles are for AWS services or external systems, and Policies define permission rules.

---

When Should You Use IAM?

When you create an AWS account, a root user with full permissions is created. However, using the root user for daily tasks is extremely risky from a security perspective.

IAM is Required For

• Granting different permissions to team members (developers vs operators)
• AWS services like EC2, Lambda accessing other services
• External systems accessing AWS resources
• Granting temporary permissions

IAM Characteristics

• Free service: IAM itself has no cost
• Global service: Applies to entire AWS account regardless of region
• Eventually consistent: Changes take time to replicate across the system

---

The 4 Core IAM Components

1. IAM Users: Accounts for People

An IAM User represents an individual person or application that accesses AWS.

Characteristics:
- Long-term credentials (password, Access Key)
- 1:1 mapping with specific individuals
- Console login or programmatic access

Use Cases:

• Granting developer John EC2 management permissions
• CI/CD pipeline account for S3 uploads

2. IAM Groups: Collections for Permission Management

An IAM Group is a logical collection of users. Attaching policies to a group grants all members the same permissions.

Characteristics:
- Can only contain users (no groups within groups)
- One user can belong to multiple groups
- Groups themselves cannot log in

Use Cases:

• "Developers" group: EC2, S3, Lambda permissions
• "Admins" group: Full admin permissions
• "ReadOnly" group: Read-only permissions

3. IAM Roles: Permissions for Services and Temporary Access

An IAM Role is a permission set not tied to a specific person. It's "assumed" when needed.

Characteristics:
- Uses temporary credentials (security recommended)
- Can be assumed by AWS services, other accounts, external systems
- No credential rotation needed (auto-expires)

Use Cases:

• EC2 instance accessing S3
• Lambda function writing to DynamoDB
• Cross-account resource access
• Users logged in via external IdP (Identity Provider)

4. IAM Policies: Documents Defining Permission Rules

An IAM Policy is a JSON document that defines who can do what.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

---

IAM Users vs Roles: Which Should You Choose?

Comparison	IAM User	IAM Role
Target	People, long-term applications	AWS services, temporary access
Credentials	Long-term (Access Key)	Temporary (STS token)
Security	Key rotation required	Auto-expires, no rotation needed
Example	Developer console access	EC2 accessing S3
AWS Recommendation	Limited use	Strongly recommended

Selection Criteria

• IAM User: Real people who log into the console
• IAM Role: AWS services, applications, cross-account access, external systems

---

Types of IAM Policies

1. Identity-Based Policies

Policies directly attached to users, groups, or roles.

• AWS Managed Policies: Provided by AWS, reusable (e.g., AmazonS3FullAccess)
• Customer Managed Policies: User-created, reusable
• Inline Policies: Added directly to a single identity (not recommended)

2. Resource-Based Policies

Policies attached to resources. Examples include S3 bucket policies and IAM role trust policies.

// S3 bucket policy example: Allow cross-account access
{
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

3. Permission Boundaries

Sets the maximum permissions an IAM entity can receive. Limits rather than grants permissions.

4. Service Control Policies (SCPs)

Defines maximum permissions for organizations or OUs in AWS Organizations. Applies even to root users.

---

Least Privilege Principle

How to Implement Least Privilege

1. Start with AWS managed policies → gradually reduce
2. Use IAM Access Analyzer: Analyze actual permission usage
3. Check last accessed information: Remove unused permissions
4. Set permission boundaries: Apply maximum permission caps

Policy Evaluation Logic

1. Default: All requests denied (Implicit Deny)
2. If explicit Allow exists → Consider allowing
3. If explicit Deny exists → Always deny (Explicit Deny)
4. Intersection of all applicable policies = Final permissions

Key Point: Explicit Deny always overrides Allow.

---

IAM Security Best Practices

Protecting the Root User

1. Never use root user for daily tasks
2. Enable MFA on root user (mandatory!)
3. Delete root Access Keys

Securing IAM Users/Roles

1. Enable MFA (Multi-Factor Authentication)
2. Rotate Access Keys regularly (90 days recommended)
3. Delete unused credentials
4. Apply strong password policies

Permission Management

1. Manage permissions through groups (avoid attaching directly to users)
2. Prefer roles (temporary credentials over long-term)
3. Monitor external access with IAM Access Analyzer

---

SAA-C03 Exam Focus Points

1. ✅ Root user restrictions: No daily use, MFA mandatory
2. ✅ Roles vs Users: EC2, Lambda service access → use roles
3. ✅ Least privilege: Grant only needed permissions, use Access Analyzer
4. ✅ Policy evaluation: Explicit Deny > Allow > Implicit Deny
5. ✅ Cross-account access: IAM role + trust policy

---

Frequently Asked Questions

Q: What's the difference between root user and IAM user?

The root user is created when you create an AWS account and has all permissions. IAM users are created by the root user and only have assigned permissions. Use IAM users for daily tasks.

Q: Why are IAM roles more secure?

IAM roles use temporary credentials. Even if credentials are leaked, damage is limited since they auto-expire. No manual rotation needed like Access Keys.

Q: Can I attach a role to a group?

No. Only policies can be attached to groups. Roles are assumed by users, AWS services, or external systems. Groups are just for convenient permission management.

Q: What happens when a user belongs to multiple groups?

All group policies are combined. However, if any group has an explicit Deny, that action is denied.

Q: What is Principal in IAM policies?

Principal specifies who can access resources in resource-based policies. Identity-based policies don't have Principal (the attached identity is the principal).

Q: When should I use Permission Boundaries?

When giving developers permission to create IAM users/roles, but limiting the maximum permissions those entities can have. Prevents privilege escalation during delegation.

---

Related Posts

• IAM Policy Writing and Evaluation Logic
• IAM Role vs User: When to Use Which
• AWS Organizations & SCP Guide

---

References

• AWS IAM Official Documentation
• IAM Security Best Practices
• IAM Policies and Permissions
• Applying Least Privilege Principle