What Is AWS IAM? Cloud Permissions in Plain English

Welcome back to our free AWS learning series. Last stop — Amazon EBS, the cloud drive that lives down the hall — ended with a promise: the pantry, the kitchen and the shelves were all rented, and what was missing was the keys. Here they are. AWS IAM (Identity and Access Management) is the permissions office built into every AWS account — completely free — where you create logins, write down exactly which doors each one may open, and issue machines temporary keys that expire on their own. And the twist that earns this post its keep: the most dangerous login in your AWS account is the one you created on day one. That email-and-password combo you think of as "the account" is the master key to everything, no rule you write can restrain it — and AWS itself wants it locked in a drawer. It doesn't just suggest this, either: between 2024 and June 2025, AWS force-fitted a second lock (MFA) onto every root login in existence, because too many buildings were burning down.

Everything in IAM — users, groups, policies, roles, the access keys people keep leaving in public — is furniture arranged around one idea: the account is a building, and nobody should be walking around with the deed in their pocket. Jake and Ethan will do the explaining, as always, because most IAM guides open with a JSON schema, and you should get a story about a text message that was never sent instead.

The Text Message Jake Almost Sent

Quick recap for anyone joining mid-series: Jake runs a phone repair shop, his booking page lives on a micro EC2 instance with an 8 GB drive whose 64-cent rent he once tried to dispute, and Ethan is the friend who translates cloud things into shop things. This week Jake is off to a two-day repair-trade expo, and Sam — the weekend helper, good with customers, honest to a fault — is watching the shop. If the booking page hangs, Sam needs to restart it. Simple. So Jake did the obvious thing: he opened his messages, typed the AWS email address and password into a text to Sam, and had his thumb on Send.

Ethan, reading over his shoulder in the way of all good friends and bad omens, asked one question: "Do you know what that password can do?" Jake shrugged — restart the booking page, obviously. "It can also delete the booking page," Ethan said, "empty every backup you set up after the wedding trip, order ten thousand dollars of computers in a data center you've never heard of, and close the entire account. You're not lending Sam a key. You're texting him the deed to the building."

Jake deleted the text. And here's the part that should genuinely change how you set up your own account: the correct fix — a separate login for Sam that can restart the booking page and do nothing else — costs exactly zero dollars and takes about ten minutes. That fix is IAM, and the first thing it asks you to accept is uncomfortable: the login Jake almost texted is one he shouldn't be using either.

The Login AWS Wants You to Stop Using

The email and password you created your AWS account with has a name: the root user. It is not the "main login." It is the deed. Three things make it unlike every other credential you own:

• It can do the irreversible things. Close the account. Change the account's email address. Alter billing and support arrangements. These aren't daily chores — they're ownership acts, the cloud equivalent of selling the shop.
• Nothing you write can restrain it. Every permission rule in the rest of this post applies to users and roles. None of them apply to root. There is no "root, but only on weekdays." The deed doesn't take instructions from the key cabinet.
• It's one password guarding everything — which is why it's the credential thieves actually want, and why sharing it, texting it, or typing it daily is the single worst habit in cloud computing.

Don't take this blog's word for how dangerous it is — watch what its landlord did. Starting in May 2024 with the biggest accounts and finishing in June 2025 with everyone else, AWS made MFA mandatory on every root user of every account type. Not recommended. Mandatory. Sign in without a second factor and you get 35 days of warnings, then a locked door until you comply. A company that bills by the hour decided that letting customers guard the deed with a password alone was costing everyone too much. That is the strongest product review a security feature has ever received.

So the professional ritual, which Jake performed the evening the text wasn't sent: put MFA on the root user (a free authenticator app is fine — AWS now insists anyway), store the password in a password manager, sign out, and don't come back except for the handful of ownership tasks that genuinely require it. People who run serious AWS accounts touch their root login a few times a year. Everything else — every deploy, every restart, every invoice check — happens through the keys in the next section.

Born Powerless: Users, Groups, and the Default No

An IAM user is a named key you cut inside the account: its own sign-in name, its own password, a tag with a person's name on it. Jake made two — jake-admin for himself, sam for the weekend helper — and then discovered the design decision that quietly makes all of AWS safer:

A brand-new user can do nothing at all. Sam's first sign-in was a tour of polite refusals — every console page a variation of "not authorized." This is the default deny, and it's the opposite of how your own PC works, where a new account can at least open its own files. In AWS, permission isn't taken away from people; it's never there until someone writes it in. Coming from the physical world this feels bureaucratic. It's actually the mercy: nobody has ever accidentally deleted a database with a permission they were never given.

• Groups are keyrings. Attach permissions to a group called staff, put Sam in it, and every future weekend hire gets the same keyring by joining the group — no re-cutting keys one door at a time.
• Yes, even a one-person shop makes a user for itself. jake-admin can do nearly everything day-to-day, and that's fine — the point is that it can be restrained, watched, and revoked, three words the root user laughs at. Daily driver in the pocket, deed in the drawer.
• One honest signpost: for teams, AWS's official recommendation is now a sibling service — IAM Identity Center — where humans get temporary credentials each session instead of permanent passwords. The FAQ below covers when that graduation matters. For learning, and for Jake's two-person operation, IAM users with MFA are a respectable rung of the ladder.

Policies: The Tag That Lists the Doors

So where do permissions actually live? On the tag. An IAM policy is a short JSON document attached to a user, group, or role, and every one of them answers three questions: may you (Effect), do what (Action), to which thing (Resource). Sam's entire power over Jake's shop, written out for real:

{
  "Effect":   "Allow",
  "Action":   ["ec2:RebootInstances", "ec2:DescribeInstances"],
  "Resource": "arn:aws:ec2:*:*:instance/i-0abc123 (the booking page)"
}

Restart the booking page, see its status, nothing else. Sam cannot open the customer files, cannot touch the backups, cannot spend a cent. Notice what the document doesn't say: there's no list of forbidden things, because the default deny already forbids everything. Policies almost never revoke — they carve tiny holes of Yes in a wall of No.

• You rarely write these by hand. AWS ships hundreds of pre-written managed policies — ReadOnlyAccess (look at everything, touch nothing) is the beginner's best friend. AdministratorAccess is the photocopy of the master key: it exists, Jake's own user wears it, and it should be handed out the way you'd hand out photocopies of a master key.
• The principle with the fancy name — least privilege — is just shopkeeper's sense: the weekend helper gets the front door and the counter, not the safe. Start from ReadOnlyAccess, add doors when reality asks.
• And the veto: one explicit Deny beats every Allow in the account. If any policy anywhere says Deny, the action fails — even for a user wearing AdministratorAccess. It's how a company bans one dangerous action account-wide without re-editing fifty keyrings, and it's the second counterintuitive rule worth tattooing somewhere: No always outranks Yes.

When these rules collide in real life, they produce the most famous error message in AWS — and this blog has already spent a full post untangling it. If you've ever been on the receiving end, the S3 Access Denied post is this section applied to a crime scene.

Roles: The Valet Ticket

Users cover people. But most of what happens in a cloud account isn't done by people — it's Jake's booking page writing its nightly backup to the S3 warehouse at 2 a.m. while every human sleeps. Machines need permissions too, and the beginner's instinct — make the machine a "user" and paste its credentials into the code — is precisely the accident the next section is about. IAM's answer is the role, and the difference fits in one sentence: a user is a key someone keeps; a role is a valet ticket anyone approved may hold for a while.

• A role is assumed, not owned. No password, no permanent anything. Whoever presents the ticket — a server, a service, occasionally a person — receives temporary credentials that expire on their own, usually within hours.
• For machines, it's beautifully invisible. Jake attaches a role ("may write to the backup bucket") to the EC2 instance, and AWS delivers fresh credentials to the machine continuously, rotating them behind the scenes. The code contains no secret at all. There is nothing to steal, nothing to rotate, nothing to accidentally publish.
• The expiry is the feature. A leaked password is a problem until someone notices. A leaked temporary credential is a problem until lunchtime. Security people call this "reducing the blast radius"; Ethan calls it "why valet tickets exist instead of handing the parking kid your house keys."

Access Keys: The Key That Works From Anywhere

One credential type remains, and it's the one that funds a small industry of cautionary tales. An access key is a pair of long strings any IAM user can generate — made for code and command lines, no browser, no face, and by default no MFA challenge. It's a key that works from anywhere on Earth, copies perfectly, and never expires on its own. Now the ritual disaster, which repeats so reliably you could set a calendar by it: a developer pastes the key into a script "just to test," publishes the script to a public code repository, and goes to bed. Bots scan public repositories around the clock, and researchers who plant deliberate bait keys have clocked them being tried within minutes of upload. By morning the account is mining cryptocurrency at the largest instance size in three continents, and the bill has more digits than the shop's phone number. AWS even keeps a pre-written emergency policy that it slaps onto keys it spots in public — the accident is so routine the landlord keeps a fire blanket by the door.

The rules, in descending order of how much Ethan will judge you: machines get roles, always — that's the whole previous section. Humans get passwords plus MFA. If you genuinely need a personal access key (learning the command line counts), keep it out of code, treat it like cash on the counter, rotate it, and delete it the month you stop using it. Jake's number of access keys, after all this? Zero. His booking page runs on a role, and roles don't fit in a text message.

What IAM Will Not Do for You

Fair warnings, in the spirit of the series:

• It won't restrain the root user. Worth repeating once, because people try: policies bind users and roles. The deed answers to nobody. The only protections root gets are the MFA now forced onto it and the drawer you lock it in.
• It won't stop you from being generous. IAM will attach AdministratorAccess to anyone you point at, without comment. Least privilege is a discipline, not a setting — the tool hands out master-key photocopies exactly as cheerfully as front-door keys.
• It won't log customers into your app. IAM governs who may manage your AWS account — staff and servers. Sign-in for the people using what you build is a different AWS service (Cognito) wearing a similar costume. Mixing them up is a classic first-year detour.
• It won't un-leak a key. Deactivating a leaked access key stops future damage; it doesn't undo the resources launched at 3 a.m. The order of operations after a leak is deactivate, then inspect the account for surprises, then contact AWS support — who see this weekly and are, by all accounts, kind about it.

Try It Yourself in Ten Minutes

The cheapest lap in the entire series — every step below is free. Sign in and open IAM from the console search bar. First, admire the nagging: the IAM dashboard scores your account's hygiene and will already be pointing at anything loose. Second, cut a key: Users → Create user, name it after yourself, allow console access, and attach the managed policy ReadOnlyAccess. Third — the part that teaches more than any diagram — open a private browser window, sign in as that new user, and try to do something: stop an instance, delete a bucket, anything. Watch the polite refusal. That's the default deny shaking your hand. Then go back to your admin login, swap ReadOnlyAccess for the permissions you actually want your daily-driver user to have, and from today onward sign in as that user — the root login goes in the drawer with MFA on it, visited a few times a year like a relative you respect but don't vacation with. Chai is, as ever, legally required.

Questions People Actually Ask

What does IAM stand for?

Identity and Access Management — the permissions office built into every AWS account: logins created, powers written down on tags, temporary keys issued to machines. Free in every particular, which the next question repeats on purpose.

What is the AWS root user?

The email-and-password you created the account with — the deed, not a key. It can close the account and change its ownership details, no policy can restrain it, and AWS now enforces MFA on it everywhere. Lock it away; work through lesser keys.

Is AWS IAM free?

Yes — users, groups, policies, roles and MFA cost nothing, in any quantity, forever. You pay for what people do with their permissions, never for the permission system itself. In a series that has marked a bill trap in every post, enjoy the one service with no meter.

What is the difference between the root user and an IAM user?

Root owns the building and answers to nothing. An IAM user is a named key cut inside the account: its own sign-in, born completely powerless, able to do only what policies allow — which means it can be restrained, watched, and revoked. Daily work on the key; the deed in the drawer.

What is an IAM policy?

The tag on the key: a short JSON document answering may-you / do-what / to-which-thing. Everything unmentioned is denied by default, and a single explicit Deny overrides every Allow in the account — the veto that always wins, even over administrators.

What is an IAM role, and how is it different from a user?

A user is a key someone keeps; a role is a valet ticket anyone approved can hold briefly. Roles are assumed, issue temporary credentials that expire on their own, and are the correct answer whenever a machine needs permissions — the server gets a role, AWS rotates its credentials invisibly, and the code holds no secret at all.

Are AWS access keys safe to use?

They're long-lived, work from anywhere, faceless, and skip MFA — treat them like cash. The classic accident is pasting one into published code: bots patrol public repositories, and bait keys planted by researchers get tried within minutes. Machines should use roles; humans who truly need a key keep it out of code, rotate it, and delete it when idle.

Should I use IAM Identity Center instead of IAM users?

For a team, yes — it's AWS's official recommendation for humans, issuing fresh temporary credentials each session instead of permanent passwords and keys. For a one-person learning account, one IAM user with MFA remains perfectly respectable. Know which rung you're on, and graduate when colleagues arrive.

What is next in this series?

The bill. Every stop so far has marked a money trap — stopped instances that still charge rent, orphan drives, reserved-not-used space — so next we read the bill itself: where charges hide, what the Free Tier credits really cover, and the alarm you can set so a surprise emails you before it grows teeth.

If You're Here for the Certification

The standing reminder, since this series grew out of our AWS certification learning series: IAM is the single most reliable exam currency there is — it appears on every AWS exam, from Cloud Practitioner to the machine learning ones. The recurring questions are exactly this post's furniture: "an EC2 application needs S3 access — access keys or role?" (the role, every time, forever), "which credentials for a new team member?" (never root, prefer temporary credentials), "a user has Allow and an explicit Deny — what happens?" (Deny wins, no exceptions), and least-privilege scenarios dressed in a dozen costumes. You can now answer all four from a story about a text message that was never sent, which sticks better than a policy-evaluation flowchart. And if you're planning a booking, check the AWS certification changes post first — 2026 moved several deadlines that decide which exam version you should even sit.

Published August 2026. Part of the free AWS learning series — previous stop: What Is Amazon EBS? Cloud Block Storage in Plain EnglishSee you in next post.