Auntie Ama owns a busy fabric shop in Makola Market. Her workers, helpers, and visiting traders all need different levels of access. Some can sell. Some can't touch the cash box. Some only borrow her apron for one task. That's not chaos — that's identity and access management.
Visit the shopAuntie Ama runs a busy fabric stall. She owns it. She has the master key. She decides who walks in, who can touch the cash box, who can restock the shelves, and who is allowed nowhere near the inventory ledger.
Without rules, the shop would be chaos — anyone could grab anything. With rules, every person has a clear role: cashier, restocker, cleaner, supplier.
That's exactly what AWS IAM does for your account. One owner. Many people. Different permissions for each.
Auntie Ama hires three workers: Kwesi the cashier, Adwoa the restocker, and Kofi the cleaner. Each one gets a personalized name badge and a key to the side door. The keys are NOT the same as Ama's master key.
Kwesi's badge says "Kwesi · Cashier." Adwoa's badge says "Adwoa · Restocker." Each badge is unique to its owner. If Kofi loses his badge, only Kofi's access gets revoked — not everyone's.
That's exactly what an IAM UserAn IAM User is a permanent identity within your AWS account that represents a single person or service. Each user has unique credentials. is in AWS. One user = one human (or one application). Each has their own login, their own credentials, their own identity.
Auntie Ama writes a rule card for each worker. They're simple, written in plain ink:
Kwesi's card: "Allowed to open cash box. Allowed to give change. NOT allowed to touch shelves."
Adwoa's card: "Allowed to restock shelves. Allowed to count inventory. NOT allowed near cash box."
Kofi's card: "Allowed to sweep floors. NOT allowed to touch ANY merchandise or cash."
That's a policy. It's a written document that says exactly what someone is allowed (and not allowed) to do. Each worker carries their card. The shop doesn't follow the worker — it follows the card.
Suppose Auntie Ama's business explodes. She now has 20 cashiers, 15 restockers, and 10 cleaners. Writing 45 individual rule cards would be madness. And what if cashier rules need to change? She'd have to update 20 cards.
So she does something smarter. She writes three group cards:
• "CASHIERS" group card — allowed to use cash boxes.
• "RESTOCKERS" group card — allowed to handle inventory.
• "CLEANERS" group card — allowed to use cleaning supplies.
Then she just stamps each worker into a group: "You're a cashier. You're a restocker." When she hires a new cashier, she just adds them to the cashier group — no new rule writing needed.
That's an IAM Group. Permissions live on the group. People join the group. Never assign permissions to individuals when a group will do.
One afternoon, a delivery driver from Tema arrives with new fabric rolls. He needs to walk into the storeroom to drop them off. But he's not a worker — he doesn't have a badge or a key.
Auntie Ama doesn't hire him. She just hands him an apron and says: "Wear this for the next 10 minutes. It gives you access to the storeroom only. When you leave, give it back."
The apron isn't his. He never owned it. He just borrowed it temporarily for one task. When the task is done, he hands it back, and he goes back to being just a delivery driver.
That's an IAM RoleAn IAM Role is an identity that can be temporarily assumed by a user, application, or AWS service. Roles use temporary credentials that expire — perfect for cross-account access, EC2 instances accessing S3, and federated logins.. It's not tied to a specific person. Anyone (or anything) authorized can "assume" the role for a limited time, do their job, then drop it.
This is how an EC2 server reads from an S3 bucket. The server doesn't have a username — it temporarily wears the "S3 access" apron.
Remember Auntie Ama's master key from the very beginning? It opens everything. The cash box, the storeroom, the books, the safe in the back, even the ledger she doesn't show anyone.
If a thief gets that key, the entire shop is lost. So Ama keeps it locked in a safe at home and almost never carries it. She uses her own personal cashier badge for daily work. The master key only comes out for emergencies — once a year, maybe.
That's the root user in AWS. It's the email and password you signed up with. It can do everything — including delete the account itself.
The honest truth: after creating your account, log out of root, create a personal IAM user with admin permissions, and use THAT for everything. Never use root for daily work. Enable MFA on root. Lock it away.
IAM is the most exam-tested topic for a reason — it's the foundation of AWS security. But you don't need to memorize it. Just remember Ama's stall.
Master key. Can do everything. Use only in emergencies.
One per person. Has its own credentials and login.
JSON document listing what's allowed and what's denied.
Permissions in bulk. Add a person, they inherit the rules.
Temporary identity. Assumed for a task, then dropped.
"AWS security isn't paranoia. It's just running your shop properly."
Read the story again