IAM: users, roles & policies

Least privilege, roles over keys, evaluation.

IAM (Identity and Access Management) is the security control plane of AWS: every API call is authorized by IAM. Getting the model right — users, roles, policies, and least privilege — is the single most important security foundation for an architect.

Principals, policies, and evaluation

IAM policies grant or deny actions on resources to principals (users, roles, services). Evaluation is deny-by-default: a request is denied unless a policy explicitly allows it, and an explicit deny always overrides any allow. Prefer managed and custom policies scoped to exactly what a principal needs — the principle of least privilege — rather than broad grants. Organize human users into IAM groups so a common permission set is attached once and inherited, and always protect the root user with MFA and use it almost never, since it has unrestricted power that no policy can cap.

# Allow read of ONE bucket's objects — nothing more.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::reports-prod", "arn:aws:s3:::reports-prod/*"]
  }]
}
# Default-deny means every other action is denied automatically.

Roles: the key to secure architecture

Roles are the architect’s most important IAM tool: a role is a set of permissions assumed temporarily, delivering short-lived credentials with no long-lived keys to leak. Attach a role to an EC2 instance (an instance profile), a Lambda function, or an ECS task so it gets auto-rotated credentials from the metadata service — never store access keys on a server. Roles also enable cross-account access (assume a role in another account) and federation (SSO users assume roles). For organization-wide guardrails, Service Control Policies in AWS Organizations cap what entire accounts can do, even for their admins. The pattern throughout: identities get least-privilege roles, not standing keys.