beginnerintermediateadvanced

AWS · IAM

IAM — Master This

The vocabulary, policy types, and evaluation logic behind every access decision AWS makes

Deny by defaultnothing is allowed unless a policy explicitly allows it
Explicit deny always winsoverrides every allow, from any applicable policy
Roles, not long-lived keystemporary credentials for humans and workloads alike
Review is scheduled, not one-timeAccess Analyzer finds unused and excess access

1.IAM vocabulary: identities, policies, resources, actions

An IAM policy is a JSON document that answers one question: can this identity take this action on this resource, under these conditions? Every other IAM concept is a variation on how that document is written or attached.

Key features

Identity = who: an IAM user, role, or federated principal
Action = what: an API operation, like s3:GetObject
Resource = which thing: identified by its ARN
Condition = when/how: IP range, MFA present, tag match
A policy is a JSON document combining all four

The four parts of every IAM policy statement

The four parts of every IAM policy statement
Element	Answers	Example value
Principal / identity	Who is asking?	An IAM user, role, or federated identity
Action	What are they trying to do?	s3:GetObject, ec2:StartInstances
Resource	On which specific thing?	arn:aws:s3:::reports-bucket/2026/*
Condition	Under what circumstances?	aws:SourceIp, aws:MultiFactorAuthPresent
Effect	Allow or deny?	Allow (default posture is deny)

What a policy statement evaluates

Identity

who is asking

Action

what they want to do

Resource

which thing, by ARN

Condition

under what circumstances

Command

text

Effect + Action + Resource + Condition  →  one statement
Statement[]                              →  one policy (JSON document)

Every IAM policy answers who, what action, on which resource, under what condition — every other IAM feature is a variation on those four parts.

2.Identity-based, resource-based, trust, boundary, and session policies

IAM has five policy types: identity-based says what an identity can do, resource-based says who can reach a resource, trust says who may assume a role, boundaries cap what a policy can grant, session policies narrow one session.

The five IAM policy types

The five IAM policy types
Type	Attached to	Question it answers
Identity-based	A user, group, or role	What can this identity do?
Resource-based	A resource (S3 bucket, SQS queue, KMS key…)	Who may reach this resource?
Trust policy	A role (a resource-based policy on the role itself)	Who is allowed to assume this role?
Permissions boundary	A user or role, alongside its identity-based policy	What is the maximum this identity could ever be granted?
Session policy	Passed when assuming a role (AssumeRole call)	What should this one temporary session be limited to?

Two different attachment points, two different questions

Identity-based

Attached to a user, group, or role
Answers "what can THIS IDENTITY do"
The policy type most engineers write first

Resource-based

Attached to the resource itself (bucket, queue, key)
Answers "who may reach THIS RESOURCE"
A trust policy is this type, attached to a role

Command

text

Identity-based  → attached to the WHO
Resource-based  → attached to the WHAT
Trust policy    → resource-based policy on a ROLE itself
Boundary/session → never grant; only cap what an allow elsewhere can reach

Identity-based and resource-based policies grant; boundaries and session policies only cap. A trust policy answers "who may assume it," not "what can it do."

3.Users vs roles, role assumption, and federation

An IAM user has long-lived credentials; a role has none of its own and is assumed instead, handing out short-lived credentials that expire. AWS now recommends roles for almost everything — federation for humans, IAM roles for workloads.

Key features

IAM user = long-lived credentials, exists until deleted
IAM role = no credentials of its own, must be assumed
AssumeRole returns temporary credentials that expire (minutes to hours)
Federation lets an external identity provider assume a role, no IAM user needed
IAM Identity Center centralizes human sign-in across many accounts

User vs role, side by side

User vs role, side by side
Property	IAM user	IAM role
Credentials	Long-lived (password / access keys)	None of its own — issued temporarily on assumption
Lifetime of a session	Until explicitly revoked	Minutes to a few hours, then expires automatically
Who/what uses it	A specific named person or app	Anyone/anything the trust policy allows to assume it
Typical use today	Narrow legacy cases only (see mistake below)	Human sign-in via federation, and all workloads

How a temporary credential gets issued

authenticatesviais authorizedtoissues

Human or workload

Identity provider / IAM Identity Center

sts:AssumeRole

Temporary credentials

expires in minutes-to-hours

Command

text

aws sts assume-role --role-arn arn:aws:iam::111122223333:role/deploy --role-session-name ci-run

A user has long-lived credentials; a role has none and must be assumed for short-lived ones. AWS recommends roles over long-lived keys almost everywhere.

4.Least privilege, explicit deny, and policy evaluation logic

IAM defaults to deny unless a policy explicitly allows a request. An explicit Deny anywhere applicable always wins, no matter how many policies say Allow. Least privilege means granting only what a task needs, not starting broad.

Key features

Default posture: deny, unless something explicitly allows
Explicit Deny in any applicable policy always overrides an Allow
Identity-based + resource-based policies combine as a union of Allows
Identity-based + permissions boundary combine as an intersection
Least privilege: grant only what a task needs, then narrow over time

How policy evaluation combines across policy types

How policy evaluation combines across policy types
Combination	Effective permission
Identity-based policy alone	Whatever it allows
Identity-based + resource-based (same account)	Union — allowed by either grants access
Identity-based + permissions boundary	Intersection — must be allowed by both
Identity-based + SCP/RCP (organization member)	Intersection — must be allowed by all
Any explicit Deny, anywhere applicable	Always wins, regardless of any Allow

The evaluation order for one request

evaluatedfirstyesnoyesno (implicitdeny)

Request arrives

Any explicit Deny apply?

in SCP, RCP, resource, identity, or boundary

Any explicit Allow apply?

Denied

Allowed

Command

text

No applicable Allow           → implicit deny (the default)
Applicable Allow, no Deny     → allowed
Applicable Allow AND Deny     → denied (explicit Deny always wins)

Deny by default; an explicit Deny anywhere applicable wins over any Allow. Grant the narrow set a task needs from the start, not "broad now, narrow later."

5.ARNs, conditions, wildcards, and troubleshooting access

An ARN is the address of one AWS resource, and it is what a policy's Resource field matches against. A wildcard broadens that match; a Condition narrows it. When access breaks, use the policy simulator instead of guessing.

Key features

ARN format: arn:partition:service:region:account-id:resource
A wildcard (*) in Resource or Action broadens what a statement matches
Policy versioning keeps prior versions; you can roll back without recreating
The IAM policy simulator tests "would this call actually be allowed?"
Access Analyzer flags unintended public/cross-account access before it bites

Reading an ARN, field by field

Reading an ARN, field by field
Field	Example value	Meaning
partition	aws	"aws" (standard), "aws-cn", or "aws-us-gov"
service	s3	Which AWS service owns this resource
region	(often empty for S3)	Region the resource lives in — global services omit it
account-id	111122223333	The AWS account that owns the resource
resource	reports-bucket/2026/q1.csv	The specific resource, service-defined format

Command

text

arn:partition:service:region:account-id:resource
s3:Get*        matches s3:GetObject, s3:GetBucketPolicy, ...
s3:GetObject   matches exactly one action, nothing else

An ARN is the address a Resource field matches — a wildcard broadens it, a Condition narrows it. Debug AccessDenied with the simulator, not more grants.

6.IAM Access Analyzer and ongoing permission review

IAM Access Analyzer flags resources reachable from outside the account, checks a policy's JSON for security issues before saving, and identifies permissions granted but never used — so unused access is found and removed on a schedule.

Key features

External access findings: flags resources reachable outside the account
Policy validation: 100+ automated checks before a policy is saved
Unused-access analysis: flags permissions granted but not exercised
Policy generation: drafts a least-privilege policy from CloudTrail activity
None of the three runs by itself — an analyzer must be created first

What IAM Access Analyzer actually checks

What IAM Access Analyzer actually checks
Capability	What it flags
External access analysis	Resources (buckets, roles, keys…) reachable from outside the account or org
Unused access analysis	Roles, permissions, and credentials granted but not used within a set window
Policy validation	JSON syntax errors, overly permissive patterns, and 100+ known-bad constructs
Policy generation	A draft least-privilege policy, built from a role's real CloudTrail activity

Command

text

aws accessanalyzer create-analyzer --analyzer-name <name> --type ACCOUNT|ORGANIZATION
aws accessanalyzer list-findings --analyzer-arn <arn>

Temporary credentials over long-lived keys, MFA for humans, least privilege from the start, scheduled review — Access Analyzer is the tool for that last one.

Spotted a mistake on this page? Tell us.

Read Sheet