Exploring AWS Organizations: How to Structure and Separate with OUs

☕ It was a cloudy Tuesday afternoon. Arjun, our curious cloud engineer, sipped his chai and stared at his screen.

"Why would anyone need multiple AWS accounts when IAM users exist?"

He had just created his startup’s AWS Organization using his email arjun@mystartup.ai. A whole new console appeared, and it was filled with mysterious terms like Management Account, Root OU, Organizational Units, and Service Control Policies (SCPs).

🎯 What is AWS Organizations?

AWS Organizations is a global service that lets you manage multiple AWS accounts from one place. It helps with:

Centralized billing
Account-level isolation for teams/projects
Applying security controls (via SCPs)
Sharing discounts (like Reserved Instances)

🧩 The Hierarchy – Explained

Let’s break it down as Arjun did:

1. Management Account

The first account used to create the AWS Organization
Has god-level permissions
Can’t be restricted by policies (for safety)
Handles all billing and charges

✅ In Arjun's case, arjun@mystartup.ai is the Management Account.

2. Root OU (Organizational Unit)

Created automatically
It’s the top-level container for your entire Organization
You cannot delete it — it’s the base of your structure

3. Custom OUs (HR, Dev, Sales...)

Arjun created separate Organizational Units to logically separate his departments:

Root OU
├── Dev OU
├── HR OU
├── Sales OU
└── Finance OU

Each OU is just a container. You don’t deploy resources inside an OU — you place AWS accounts under them.

4. Member Accounts

Separate AWS accounts under your Organization
Used by teams or projects
Can be created manually or automated via API
Governed by the policies and structure of the Organization

✅ For example:

dev-backend@mystartup.ai (under Dev OU)
sales-dashboard@mystartup.ai (under Sales OU)

Each team gets its own AWS playground, but still plays by the Organization’s rules.

💡 Why Not Just Use IAM Users?

Great question, Arjun asked the same!

“No company gives every employee their own AWS account…”

True, but here’s the catch:

IAM users work within a single AWS account
Multiple IAM users in one account = shared blast radius
One IAM misconfiguration = everyone’s at risk

Using separate AWS accounts gives:

Hard isolation (perfect for prod vs test environments)
Better cost visibility
Clean separation of permissions and access
Easier security and compliance auditing

🔐 Bonus: SCPs (Service Control Policies)

Once Arjun added accounts under OUs, he realized he could control what each account could or could not do — using Service Control Policies.

Example:

❌ Block S3 in Dev OU
✅ Allow only EC2 and CloudWatch in Test OU

Think of SCPs as organizational-level IAM policies — but stronger.

🧠 Final Thought from Arjun

"So now, I can give my DevOps team a full AWS account, isolate billing, enforce policies, and still control everything from one place? Damn. AWS Organizations is powerful!"

He took a long sip of chai, smiled, and added AWS Organizations Mastered to his exam prep checklist.

🚀 TL;DR

Management Account = Admin of all
Root OU = Top-level container
OUs = Logical groupings (like departments or projects)
Member Accounts = Independent AWS accounts under the org
Use SCPs to restrict or allow services per OU or account