Table of Contents
AWS Organizations is a powerful service that helps you manage multiple AWS accounts with ease and security. Whether you’re a startup growing fast or a large enterprise managing dozens of teams, AWS Organizations allows you to apply policies, control billing, and automate account creation — all from a central place.
☕ 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:CopyCopy
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
Read More on AWS Advanced IAM
- Avoid Disaster with AWS Service Control Policies
- AWS Resource Control Policies Made Easy
- AWS Organizations: Secure Cloud Setup
