AWS IAM
Identity & Access Management

What is AWS IAM?

IAM (Identity and Access Management) is a global AWS service that controls who can access AWS and what they can do. It is the foundation of security in any AWS environment.

Why Do We Need IAM?

Without IAM, everyone would use the root account (owner account), which is extremely dangerous. IAM lets us:

• Create separate accounts for each person (developer, admin, tester)
• Give only the permissions that person needs — Principle of Least Privilege
• Track who did what and when (audit trail)
• Allow third-party services to interact with AWS securely
• Manage access for thousands of users from one place

Key Features of IAM

• Global service — IAM is not region-specific; it applies across all regions
• Free service — IAM itself has no additional charge
• Integrated with all AWS services
• Supports Multi-Factor Authentication (MFA)
• Provides temporary access through Roles

IAM Core Components

IAM has four main building blocks. Understanding each one is essential.

1. IAM Users

An IAM User represents a single person or service. When created, a user has no permissions by default. Permissions are granted by attaching policies.

• Can have a Console Password (for AWS Management Console login)
• Can have Access Keys (for CLI/API access)
• Can belong to one or more groups
• Permissions can be attached directly or inherited from a group

2. IAM Groups

Groups make it easy to manage permissions for multiple users at once. Assign a policy to a group — all users in that group inherit it.

Example groups: Developers, Admins, DBAs, ReadOnly-Team

3. IAM Roles

A Role is not assigned to a person — it is assumed temporarily. Think of it like borrowing a badge. Roles are used when:

• An EC2 instance needs to access S3 (the instance assumes a role)
• A Lambda function needs to write to DynamoDB
• A user from another AWS account needs cross-account access
• Users logging in via SSO / Federation

4. IAM Policies

A Policy is a JSON document that defines permissions. It specifies which AWS services and actions are allowed or denied, and on which resources.

• Can be attached to Users, Groups, or Roles
• Multiple policies can be attached to one identity
• AWS provides pre-built Managed Policies (e.g., AdministratorAccess, AmazonS3ReadOnlyAccess)
• You can create Inline Policies or Customer Managed Policies

IAM Policy Types

IAM Policy JSON Structure

Every IAM policy is written in JSON. Understanding this structure is critical for the AZ and AWS exams, and for real-world work.

{
  "Version": "2012-10-17",         // always use this version
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",     // optional: statement ID
      "Effect": "Allow",            // "Allow" or "Deny"
      "Action": [
        "s3:GetObject",          // specific action
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket", // specific resource (ARN)
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {             // optional: when rule applies
        "StringEquals": {
          "aws:RequestedRegion": "ap-south-1"
        }
      }
    }
  ]
}

Breaking Down Each Field

Authentication vs Authorization

These two terms are often confused. Both are handled by IAM but they are completely different concepts.

IAM Decision Flow

When a user or service tries to perform an action in AWS, IAM checks in this order:

1. Is there an explicit Deny? → If yes, access is denied immediately
2. Is there an explicit Allow? → If yes, access is granted
3. Neither? → Access is denied (implicit deny — default)

MFA & Access Keys

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security beyond just a password. Even if a password is stolen, the attacker cannot log in without the second factor.

• Factor 1: Something you know (password)
• Factor 2: Something you have (physical device / virtual authenticator app)

MFA Device Types in AWS

Access Keys vs Console Password

There are two ways to access AWS — each uses different credentials:

IAM Security Tools

AWS provides built-in tools to audit and review your IAM configuration.

1. IAM Credentials Report (Account Level)

A downloadable CSV report of all IAM users and the status of their credentials — password last used, MFA enabled, access keys created/rotated, etc.

• Go to IAM → Credential Report → Download
• Useful for compliance audits
• Shows which users haven't logged in for a long time (potential inactive accounts)

2. IAM Access Advisor (User Level)

Shows which services a user has permission to access, and when they last accessed each service.

• Go to IAM → User → Access Advisor tab
• Helps you identify unused permissions → remove them (least privilege)
• Shows the last time each allowed service was actually used

3. IAM Policy Simulator

Test what a user, group, or role can or cannot do — without actually performing the action.

• Useful for testing before giving permissions to production users
• Access at: policy simulator tool in the IAM console

IAM Best Practices

• ✓
  Never use the Root account for daily tasks. Create an IAM admin user immediately after account creation and lock the root account away.
• ✓
  One physical user = One IAM user. Don't share IAM users between people. Each person gets their own account.
• ✓
  Use Groups to assign permissions. Attach policies to groups, not individual users. Makes it easier to manage at scale.
• ✓
  Apply Principle of Least Privilege. Give only the minimum permissions required. Start with zero and add what is needed.
• ✓
  Enable MFA for all users, especially the root account and admin users. This is the single most impactful security step.
• ✓
  Rotate Access Keys regularly. Rotate every 90 days and immediately revoke keys for users who leave the organization.
• ✓
  Use IAM Roles for applications and services (EC2, Lambda, etc.) instead of embedding access keys in code.
• ✓
  Enforce a strong password policy. Set minimum length, require uppercase/numbers/symbols, and force rotation.
• ✓
  Audit regularly with Credentials Report and Access Advisor. Remove unused users, permissions, and access keys.
• ✓
  Never share or hardcode Access Keys. Use environment variables, AWS Secrets Manager, or IAM Roles instead.

Chapter Summary

What's Next?

Now that IAM is covered, the next topic is EC2 (Elastic Compute Cloud) — where you will launch virtual machines in the cloud and connect them to what you just learned about IAM Roles (so EC2 instances can securely access S3, RDS, and other AWS services).