AWS IAM: A Clean Mental Model (Users, Groups, Roles & Policies)

TL;DR

IAM = Identity & Access Management for AWS.
You create identities (Users, Groups, Roles) and attach policies (JSON) that explicitly allow actions on resources.
Default is deny. If it’s not explicitly allowed, it’s blocked.
Authenticate first (prove who you are) → then authorize (what you can do).
Root user: use only for account setup/billing; create an admin IAM user/role for daily work.

What IAM Is (and why it matters)

AWS IAM helps you securely control access to AWS services and resources for individuals, teams, and systems. Access can happen through the AWS Management Console, AWS CLI, or SDKs—but only after authentication and authorization.

The Access Paths

Console (human users with passwords + MFA)
CLI/SDK (access keys, temporary creds, roles)

Identities: Users, Groups, Roles

IAM User: An individual identity with long-term credentials (password and/or access keys).
IAM Group: A collection of users. Attach policies to the group to manage permissions for many users at once.
IAM Role: An identity without long-term credentials that’s assumed by a user, service, or workload to get temporary permissions. Ideal for EC2, Lambda, CI/CD, cross-account access, etc.

Authn vs Authz (don’t mix them up)

Authentication: verifying identity (login, keys, MFA).
Authorization: verifying permissions (what actions on which resources). By default, no permissions exist until you attach policies that explicitly allow them.

Policies: The Permission Engine (JSON)

Policies are JSON documents that define Effect, Action, Resource, and optional Condition. Anything not explicitly allowed is denied.

Policy anatomy

Sid (optional): statement identifier
Effect: Allow or Deny
Action: API operations (e.g., s3:GetObject)
Resource: ARNs the actions apply to
Condition (optional): context rules (e.g., source IP, MFA present)

Minimal example — Allow S3 read-only to a bucket

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DeptReadOnlyS3",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-dept-bucket",
        "arn:aws:s3:::example-dept-bucket/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Example Setup: Two Departments

Create two IAM groups: DeptA, DeptB.
Attach a policy to each group (e.g., each department’s S3 buckets, DynamoDB tables, etc.).
Create users for each person and add them to the right group.
(Optional) Use roles for workloads (EC2/Lambda) to access resources with temporary credentials.

The Root User (handle with care)

Every AWS account has root credentials with full access. Use it only for:

Initial account setup
Billing tasks
Closing the account
Creating the first admin IAM user/role Then lock it down: enable MFA, create an admin role, and avoid daily use.

Roles vs Users (quick mental model)

Users = people with long-term credentials
Roles = temporary access for people/services/workloads Attach policies to roles so workloads inherit least-privilege permissions when they assume the role.

Common Pitfalls (and quick fixes)

Using root for daily work → Create an admin role/user; enable MFA on root.
Over-permissive policies (*:*) → Start with least privilege; add narrowly.
Static access keys on servers → Use instance profiles/roles for EC2, or role-based creds for Lambda.
Forgetting default deny → If access fails, check: identity policies, resource policies, explicit denies, and conditions (IP, MFA, regions).