IAM Basics: Why It Exists at All
Before the policies and roles, understand the problem IAM was built to solve, and why every step of its design exists to shrink the damage when something leaks.
From your mentor
People bounce off IAM because they learn the JSON before the why. Start here: one shared key was a disaster, and every IAM feature since is a reaction to it. Get that, and policies stop feeling random.
IAM exists for one reason: to shrink the damage when something leaks.
In 10 minutes you’ll see why every IAM feature is a blast-radius limiter. You do NOT need policy syntax yet.
Pick your way in, same idea, 5 doors
Imagine one key that opens everything you own. Now imagine making copies that each open only one door, expire in an hour, and can be cancelled. That’s IAM, turning one dangerous key into many small, safe ones.
One account, one set of keys
A brand-new AWS account has exactly one identity, the root user, and its credentials can do absolutely anything. That's the problem IAM exists to fix.
Careful here
IAM’s entire job is to replace that one all-powerful key with many narrow, identifiable, revocable ones, so access is scoped, auditable, and easy to take away.
Every request asks two questions
Strip IAM to its core and it's just two checks, run on every single API call, and the second one says 'no' by default.
1 · Authentication
“Who are you?”
Proven by credentials, a password + MFA, an access key, or a short-lived SSO token.
2 · Authorization
“Are you allowed to do this?”
Checked against policies, and the answer is no unless something explicitly allows it.
Request runs
IAM is just these two questions, asked on every single API call. Authentication decides who; authorization decides what, and it’s deny-by-default.
Authentication ≠ authorization
Authentication proves who you are (your credentials). Authorization decides whether you may do this specific thing (your policies). Being signed in doesn’t mean you’re allowed, that confusion is behind half of all “Access Denied” surprises.How identity on AWS grew up
IAM didn't arrive fully formed. Each layer was added to solve a specific pain of the one before it.
| Step | What it added | The pain it solved |
|---|---|---|
| Root user | One identity that can do everything | (the starting point, and the problem) |
| IAM users | A separate named identity per person/app | Accountability, who did what, and revoke one without re-keying all |
| Groups | Attach permissions to a role, add users to it | Stop hand-managing permissions per person |
| Policies + least privilege | Grant only the exact actions/resources needed | Shrink what any one identity can touch |
| IAM roles (temporary creds) | Assumable permissions with no stored secret | Kill long-lived keys for apps, CI, cross-account |
| Identity Center (federation) | One workforce identity, SSO, short-lived sessions | No standing credentials for humans at all |
Nice, that’s the win
Why the climb matters: blast radius
The real reason to climb isn't tidiness, it's that each rung shrinks the damage when a credential inevitably leaks.
If this credential leaks, how much can the attacker do?
The entire account, forever, close it, drain billing, delete everything. Nothing can restrain it.
Whatever that user can do, and it keeps working until a human notices and rotates the key.
Only the role’s scope, and only until the short session expires, minutes to hours.
Almost nothing standing to steal, access is a short-lived, MFA-gated session tied to the person.
This is why the IAM “climb” isn’t bureaucracy, each rung shrinks what a stolen credential can do. The goal is to have nothing long-lived worth stealing.
Assume the leak
Credentials will leak, committed to git, phished, left on a laptop. Good IAM design assumes it and asks: “when this leaks, how bad is it, and for how long?” Roles and Identity Center win because the honest answer becomes “barely, and not for long.”Why IAM done right is elegant
Four properties fall out of the climb, and together they're what 'secure access' actually means on AWS.
Least privilege
Every identity can do exactly its job and nothing more, so a compromise is contained to a thin slice instead of the whole account.Accountability
Each action is tied to a named identity and logged in CloudTrail, you can always answer “who did this, and when?”Temporary by default
Roles and Identity Center hand out short-lived credentials that expire on their own, so there’s little standing to steal.Scales to anything
The same model covers one person, a thousand employees, apps, CI pipelines, and other AWS accounts, without ever reaching for the root key.Where to go next
Now that the why is clear, go see how the authorization decision actually works, and practise it.
Next up
IAM, in Depth (deep dive)
The request model, all the policy types, the exact evaluation logic, roles & AssumeRole, and least privilege in practice with Access Analyzer.
Then test yourself
Try the IAM Policy Simulator, compose identity, resource, SCP, boundary, and session policies, fire a request, and watch it pass or fail through the real decision pipeline, with the deciding rule called out. The fastest way to truly get “explicit deny wins.”