Amazon Web Services
Identity & Access — IAM
Grant least-privilege permissions to users, services, and workloads via policies and roles.
IAM (Identity and Access Management) controls who can do what in an AWS account. The core building blocks are identities — users, groups, and roles — and policies, JSON documents listing allowed/denied actions on resources. Every API call is authenticated and then authorized against the applicable policies; the default is implicit deny, and an explicit deny always wins.
A building access-card system. Each person or robot (principal) carries a card (role) encoding exactly which doors (actions) it may open and when (conditions). Temporary visitor passes (assumed roles) expire automatically, so nobody walks around with a permanent master key.
Key Concepts
1
The single most important concept is the IAM role: a set of permissions that can be assumed temporarily, rather than long-lived credentials. EC2 instances, Lambda functions, and ECS tasks get roles so they receive short-lived credentials automatically — no secrets baked into code. Cross-account access, federation (SSO, OIDC), and workload identity all use roles. Best practice is least privilege: grant only the specific actions needed, prefer roles over access keys, and use conditions to tighten scope.