Don't Panic — AWS Identity and Access Management

IAM controls who can make which AWS request under which conditions. That is the whole thing. Every console click, CLI command, SDK call, and service-to-service operation is an API request, and IAM is the authorization layer that decides whether to accept it.

Before IAM existed, every API call used root credentials. That was the problem. IAM replaced it with identities — users, roles, and temporary sessions — and policies that describe what each identity may do. The core evaluation model has not changed since 2011: a request is implicitly denied unless an applicable policy produces an allow, and any applicable explicit deny overrides that allow.

The part that surprises most people is how many policy layers participate in that decision. An identity-based policy grants permissions to a user or role. A resource-based policy grants permissions to a named principal on a resource. A permissions boundary caps what identity-based policies can grant. A session policy narrows one temporary session. Service control policies set organization-level guardrails. Resource control policies do the same for resources. A single API call can be evaluated against all six layers, and the interaction is not always intuitive.

The mental model that survives first contact with production is: follow one request. A principal uses credentials to ask an AWS service to perform an action on a resource. AWS builds a request context — the principal, the action, the resource, the time, the network path, the tags, the Region — and evaluates every policy that applies. The result is allow or deny. When access surprises you, the answer is never in one policy document. It is in the interaction between the layers, and the debugging path starts with identifying which layer caused the denial.

Least privilege is not a policy you write once. It is a process: define the task, write the narrowest evidence-backed policy, validate before deployment, test both allowed and denied paths, observe real activity through CloudTrail, review Access Analyzer findings, and remove unused permissions. The first policy you write will be too broad. That is expected, not a failure. The question is whether you close the gap before or after something goes wrong.

The three things worth remembering: temporary credentials are the default design target for both people and workloads; explicit deny always wins; and IAM tells you how access should be decided while CloudTrail gives you evidence about requests that actually occurred. You need both for sound operations.

Start with the request model in the reference tab if you want the evaluation logic in detail. The cheatsheet is the fastest way to identify which policy type does which job. And if you are debugging an unexpected deny, the field notes describe the policy-layer interactions that most troubleshooting guides skip.

Don't Panic — AWS Identity and Access Management

Relevant careers