CoDeKu DevOps Academy Blog - DevOps & Cloud Blogging Platform
Imagine you just moved into a brand new apartment building. The landlord hands you one master key it opens every door. Every room. Every storage unit. Every floor. Your room, your neighbor’s room, the electricity vault, the rooftop everything.
Would you carry that key to the grocery store? Hand it to a friend? Leave it on your desk?
Of course not. You’d lock it away and only touch it in a real emergency.
That master key is your AWS Root User. And IAM is the smarter, safer system you build on top of it.
Who is the Root User?
When you first create an AWS account, Amazon gives you one login one email, one password. This is your Root User. It is the god-mode account of your entire AWS universe.
⚠ The Scary Truth
If someone breaks into your Root User account, they can delete every server, rack up a $50,000 bill overnight, and destroy everything you built. AWS cannot reverse most of it. Root User has zero guardrails absolutely none.
What is IAM?
IAM stands for Identity and Access Management. It is a free AWS service that lets you create separate identities inside your account each with their own controlled permissions.
Instead of one master key for everything, IAM lets you create dozens of specific keys. A developer gets access to the server room only. A data analyst gets access to the data bucket only. No one gets the billing room unless they absolutely need it.
Component 1
IAM Users
Individual people developers, analysts, admins. Each gets their own login and specific permissions.
Component 2
IAM Groups
Bundle users into teams. Set permissions once on the group everyone inside inherits them instantly.
Component 3
IAM Roles
Not for people for AWS services. Your EC2 server needs a role to talk to S3. Lambda needs a role to write logs.
Component 4
IAM Policies
JSON documents that define exactly what is allowed or denied. Attached to users, groups, or roles.
What Does a Policy Look Like?
A policy is a simple JSON document. It answers three questions: Who? What action? On which resource? Here is a real example granting read-only access to an S3 bucket:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
Effect
Allow or Deny the action
Action
What operation to perform
Resource
Which AWS resource it applies to
Root User vs IAM
🔴 Root User
✗ Full unrestricted access
✗ Cannot limit permissions
✗ One per account only
✗ No team-level control
✗ Dangerous to use daily
🟢 IAM Users
✓ Controlled, limited access
✓ Custom permissions per user
✓ Unlimited users possible
✓ Full audit logs via CloudTrail
✓ Safe for everyday use
Why IAM ?
Fine-Grained Control
Give exactly the right access. Not too much. Not too little.
Completely Free
IAM costs nothing. You only pay for the AWS resources you use.
Limit the Blast Radius
If one account gets compromised, damage stays limited.
Scales With Your Team
Works for startups and enterprises alike.
MFA Support Built In
Add a second layer of security on every user.
Summary
Root User = god-mode account. Powerful, dangerous, lock it away immediately.
IAM = the safe system. Create real users and services with controlled, scoped access.
Users = people. Groups = teams. Roles = services. Policies = the rules.
IAM gives you control, accountability, and security completely free.
Best rules: MFA on, least privilege always, never hardcode access keys.
“Security isn’t about fear.
It’s about being intentional.”
IAM is how you tell your cloud exactly who to trust, how much, and when. That is not paranoia. That is good engineering.

