AWS IAM Fundamentals: Users, Roles, Policies & Least Privilege

IAM has four core building blocks. A user is a permanent identity with long-term credentials (console password and/or access keys) — meant for a specific person or a legacy application. A group is just a named collection of users that policies can be attached to once, instead of per-user. A rolehas no long-term credentials at all — it's assumed temporarily (via AWS STS) by a user, an AWS service like EC2/Lambda, or an external identity provider, and issues short-lived, auto-expiring credentials. A policyis the actual JSON document defining what's allowed or denied.

Why roles are preferred for workloads

An access key embedded in application code or an EC2 instance is a long-lived secret that, if leaked, works until manually revoked. A role attached to an EC2 instance profile issues credentials that auto-rotate every few hours via the instance metadata service — even if the workload is compromised, the exposure window is bounded, and there's no static secret to leak in the first place.

How a policy statement is structured

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyOnOneBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ]
    }
  ]
}

This grants read-only access to exactly one bucket — not s3:* on *, which is the single most common IAM mistake. Scoping both the Action list and the Resource ARN is what makes a policy "least privilege" rather than a rubber stamp.

AWS collects every applicable policy — identity-based, resource-based, permission boundaries, and (in an organization) SCPs — and evaluates them together using one fixed precedence rule:

Create a least-privilege role and assume it via the CLI:

# 1. Create a trust policy allowing your own account to assume this role
cat > trust-policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
    "Action": "sts:AssumeRole"
  }]
}
EOF

aws iam create-role \
  --role-name s3-readonly-role \
  --assume-role-policy-document file://trust-policy.json

# 2. Attach a scoped permission policy (use the JSON from Theory above, saved as read-policy.json)
aws iam put-role-policy \
  --role-name s3-readonly-role \
  --policy-name S3ReadOnlyOneBucket \
  --policy-document file://read-policy.json

# 3. Assume the role and get temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/s3-readonly-role \
  --role-session-name test-session

# 4. Use the returned AccessKeyId/SecretAccessKey/SessionToken to confirm
# you can read from the bucket but NOT write to it or read any other bucket

"AccessDenied" despite an Allow policy attached: use the IAM Policy Simulator or CloudTrail's "Event history" to see the exact API call and the effective decision — check for an explicit Deny in a permission boundary or SCP first, since those silently override an Allow at the identity level without any error hinting at their existence.

A role can't be assumed: confirm the trust policy's Principal matches the exact caller (account root vs. a specific user/role ARN), and that the calling identity has sts:AssumeRolepermission on that specific role's ARN — both sides (trust policy AND caller permission) must allow it.

Users are for people, roles are for workloads and temporary access, groups organize users, and policies are JSON documents scoped by Action and Resource. AWS evaluates every applicable policy together with one rule: an explicit deny anywhere always wins, otherwise an explicit allow is required, and the default is deny.