AWS Root User vs IAM

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 ?

01

Fine-Grained Control

Give exactly the right access. Not too much. Not too little.

02

Completely Free

IAM costs nothing. You only pay for the AWS resources you use.

03

Limit the Blast Radius

If one account gets compromised, damage stays limited.

04

Scales With Your Team

Works for startups and enterprises alike.

05

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.

Share This Article

Sapuni Dheerasinha
Sapuni Dheerasinha
Articles: 8

Leave a Reply

Your email address will not be published. Required fields are marked *