IAM: Identity and Access Management
AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. It is a Global Service (not Region-specific) that handles Authentication (Who are you?) and Authorization (What are you allowed to do?).
The Airport Analogy
Think of AWS as a high-security airport:
- Root User: The owner of the airport. They have the master keys to every door and safe. This user should rarely be used.
- IAM User: An employee at the airport (e.g., a gate agent). They have a specific ID badge.
- IAM Group: A department (e.g., “Security Staff”). If you add an employee to this department, they automatically get the department’s access rights.
- IAM Role: A temporary uniform (e.g., a “Firefighter” suit). Anyone qualified can put it on to perform a specific task, then take it off.
- Policy: The rulebook that says “Anyone wearing a Security Staff badge can enter Gate A but not the Vault.”
Core Concepts & Well-Architected Framework
In the Security Pillar of the Well-Architected Framework, IAM follows the Principle of Least Privilege: Grant only the minimum permissions required to perform a task.
1. Policies (JSON)
Policies are documents that define permissions. They consist of:
- Effect: Allow or Deny.
- Action: The specific API calls (e.g.,
s3:GetObject). - Resource: The ARN (Amazon Resource Name) the action applies to.
- Condition: Optional constraints (e.g., IP address range).
Service Comparison Table
| Feature | IAM User | IAM Role | IAM Group |
|---|---|---|---|
| Definition | Long-term identity for a person or application. | Temporary identity for a service or federated user. | A collection of IAM Users. |
| Credentials | Password or Access Keys. | Short-lived tokens (STS). | None (inherits from policies). |
| Best Use Case | Individual developers using CLI/Console. | EC2 instances, Lambda, or Cross-account access. | Managing permissions for a team (Devs, Admins). |
Scenario-Based Learning (Decision Matrix)
If/Then Guide
- IF an EC2 instance needs to upload files to S3… THEN attach an IAM Role to the EC2 instance (Instance Profile).
- IF you have employees in an external Active Directory… THEN use Identity Federation with SAML 2.0.
- IF you need to restrict the Root user of a member account in an Organization… THEN use a Service Control Policy (SCP).
- IF you want to ensure a user is who they say they are… THEN enable Multi-Factor Authentication (MFA).
Exam Tips: Golden Nuggets
- Explicit Deny: An explicit “Deny” in any policy always overrides any “Allow.”
- Access Keys: Never embed Access Keys in your code. Use IAM Roles for applications running on AWS.
- Root User: The first task after creating an AWS account is to enable MFA on the Root user and delete its Access Keys.
- IAM is Global: You do not select a region when creating users or roles; they are available across all regions.
IAM Architectural Flow
Key Services
- IAM: Identity management.
- STS: Security Token Service (Temp credentials).
- AWS Organizations: Centralized account management.
Common Pitfalls
- Using the Root user for daily tasks.
- Attaching Inline Policies instead of Managed Policies.
- Leaving Access Keys active for deleted users.
Quick Patterns
- Cross-Account: Role in Account B, trusted by Account A.
- Web Identity: Login via Google/Amazon using OIDC.