Almost everyone’s first real experience with AWS is the same: you try to do something perfectly reasonable, and you get told access denied. It feels like the system is fighting you.
The name behind that “no” is IAM, Identity and Access Management. It took me a while to stop resenting it and realize the friction is the entire point. Security doesn’t start from “sure.” It starts from “no,” and makes you earn every “yes.”
The one question IAM answers
Strip away the jargon and IAM is answering a single question, over and over:
Who is allowed to do what, to which resource?
- Who is the principal: a user, or a role (more on that below).
- What is the action: read this, delete that, launch the other.
- Which is the resource: a specific bucket, database, function.
Every permission in AWS is some version of that sentence.
Policies — the rulebook, in writing
A policy is that sentence written down, as a small document. It says: this effect (allow or deny), for these actions, on these resources. You attach policies to identities, and those identities can then do exactly what the policies say and nothing else.
Users vs roles — a permanent badge vs a borrowed hat
This is the distinction that confused me longest.
- A user is a permanent identity with its own credentials. A person, or an app, with a badge that’s theirs.
- A role is a temporary hat. No permanent password, just a set of permissions someone or something puts on for a task, then takes off. Services use roles to act on each other safely, without long-lived keys lying around.
The click: a role isn’t a person, it’s a costume with permissions stitched in.
The rules of the game
Three rules run the whole thing, and once they clicked, the “access denied” messages stopped feeling random:
- Deny by default. If nothing explicitly allows an action, it’s denied. Silence means no.
- An explicit allow opens the door.
- An explicit deny always wins. If anything says no, it’s no, even if something else said yes.
That’s also the spirit of least privilege: start from nothing, and grant only the specific things actually needed. It’s the opposite of how I’d think as a salesperson, where access often signals trust. Here, good systems assume nothing.
The root account — the master key
When you open an AWS account, the root user can do anything. The grown-up move is to lock it away, turn on multi-factor authentication, and never use it for daily work. You create limited identities for that. The most powerful key is the one you use least.
How AWS actually decides
Quick reference, for future me
| Term | What it is | Plain version |
|---|---|---|
| Principal | Who is making the request | The “who” |
| Action | The operation requested | The “what” |
| Resource | The thing acted on | The “which” |
| Policy | Document of allow/deny rules | The rulebook |
| User | Permanent identity | A badge that’s yours |
| Role | Temporary assumed identity | A borrowed hat |
| Least privilege | Grant only what’s needed | Start from nothing |
| Root user | All-powerful account owner | The master key, locked away |
I still get tripped up by IAM, the layered policies, the JSON, the times two rules quietly interact. But I stopped reading “access denied” as the system being difficult. It’s the system doing exactly its job, and learning to see the “no” as a feature instead of a bug felt like a genuinely technical shift in how I think.