Day 1 - AWS Organizations: A New Unit of Thought for Multi-Account Architecture

Almost every company starting to use AWS goes through the same path. At the beginning, there is just one account. A handful of developers all log into the same root account via the console and create EC2 instances and spin up RDS databases. As the team grows, IAM Users are created, then IAM Groups. Then the security team says "you can't keep production and development in the same account." So a separate development account and production account are created. Over time, those two become five, then forty, then a hundred. And at some point, IAM policy conflicts, inability to split costs by department, and security incidents spreading from one account to another all hit at the same time.

Before AWS Organizations went GA in 2017, all of this was an operational problem that customers had to solve themselves. Netflix managed 100+ accounts with their own tool Cloudaco, and Capital One created Cloud Custodian. Then in 2017, AWS began providing a standard API for "grouping multiple accounts into a single management unit." That's Organizations. And that's where Domain 1 of SAP-C02 (26%) starts.

Today we begin with the fundamental question "why multi-account?" and then move through Organizations' structure, OU design standards, Management account risks, and account automation. If you see a question in the Pro exam asking "how do I group N accounts?", this thinking tool should immediately come to mind.

Why Multi-Account: 4 Motivations and Their Depth

The need for multi-account is not simply "accounts are cleaner when split." Four distinct dimensions operate simultaneously.

💡 Related theory: Blast Radius is a term established by Netflix's Chaos Engineering team. When Netflix Chaos Monkey randomly kills instances, "blast radius" measures "how many users does one instance death affect." The account is the strongest barrier to this radius — at the AWS account boundary, IAM, networking, and API calls are all blocked. The same philosophy was formalized as the Bulkhead Pattern in Michael Nygard's Release It! (2007). Like a ship's bulkhead, if one compartment floods, others survive.

💡 Related theory: Bounded Context is a core concept from Eric Evans' Domain-Driven Design (2003). When different domain models mix in the same codebase, semantic conflicts occur (Order is an invoice to the billing team but a shipping unit to logistics). BC's essence is to isolate code and data by domain. An AWS account is infrastructure-level Bounded Context. If the billing domain and logistics domain share the same account, IAM policies grow bloated considering both. Splitting accounts keeps each account's IAM simple.

🔍 Going deeper: The power of the AWS account boundary is implemented explicitly at the API level. An IAM User in one account fundamentally cannot see resources in another account by default. To see them requires passing through three gates: (1) Cross-Account Role + (2) Resource Policy + (3) STS AssumeRole. By contrast, within the same account, a single misconfigured IAM policy can grant access to another team's resources. That's why isolation like "Dev/Prod separation" is enforced through account separation, not IAM.

📚 Case study: In the 2019 Capital One breach, if prod and staging had been in different accounts, an attacker with staging's IAM Role could never access prod S3. Because they shared an account, one EC2 IAM Role gave access to production data. After the incident, Capital One built an "Account Vending Machine" to split every workload group into a separate account. This philosophy is now reflected in AWS Control Tower's Account Factory.

AWS Organizations Structure: 3 Layers of Root, OU, Account

Root
 ├── Management Account (billing·Org management, no workloads)
 ├── OU: Security
 │    ├── Log Archive (CloudTrail S3 storage, Object Lock)
 │    └── Audit (Security Hub, GuardDuty Master)
 ├── OU: Infrastructure
 │    ├── Network (TGW, DNS, Direct Connect, Route 53)
 │    └── Shared Services (CI/CD, ECR, AD, CodeArtifact)
 ├── OU: Workloads
 │    ├── OU: Prod (N accounts)
 │    └── OU: Non-Prod (N accounts)
 ├── OU: Sandbox (free experimentation, cost·service limits)
 ├── OU: PolicyStaging (SCP testing)
 └── OU: Suspended (accounts pending closure)

• Management Account: The billing account that created the Organization. No workload deployment (security·isolation).
• Member Account: Regular accounts that live inside OUs.
• OU (Organizational Unit): Container for accounts. Maximum 5 levels of nesting.

🔍 Going deeper: OUs can nest up to 5 levels, but in practice 3+ levels is rare. AWS SRA (Security Reference Architecture) recommendation is 2-3 levels. Example: Root → Workloads → Prod → App-A-Prod account (3 levels). Deeper nesting increases SCP evaluation cost and operational complexity.

🔍 Going deeper: Organizations' backend is Eventually Consistent. SCP changes may take minutes to propagate to all accounts. Don't expect immediate effect after seeing an attachPolicy event in CloudTrail. In the Pro exam, "SCP attached directly must block Lambda immediately" is often a trap.

⚠️ Pitfall: SCPs do not apply to Management accounts (intentional). The root user in Management can delete the Organization itself—nothing SCPs can prevent. Standard practice is (1) enforce MFA hardware token on root, (2) use root-exclusive email as a separate alias, (3) set password recovery to impossible and seal it away.

OU Design Standard: 5 Core OUs from AWS SRA

AWS's official SRA recommends these 5 OUs as the foundation.

💡 Memory tip: OU is not "organizational chart" but "common policy unit". Group accounts by which SCP will apply to them. Copying the company org chart (Sales·Dev·HR departments) directly to OUs means almost no common policies between OUs, making SCP pointless.

🎯 Scenario: "A global financial company operates in three regions: US, EU, APAC, each with separate regulation (SOX, GDPR, PCI-K). How should we design OUs?" — Answer: Region OUs (US/EU/APAC) + Prod/Non-Prod nesting inside each. Common SCP (e.g., GDPR data sovereignty) applies only to the EU OU. PCI-DSS spans all regions' payment workloads, so it could be a separate PCI OU. Key: group by unit where common SCP applies.

Account Separation Decision: When to Split and When to Merge

🔍 Going deeper: "One account per microservice" is common over-engineering. 100 services = 100 accounts leads to (1) IAM Identity Center Permission Set explosion, (2) Cross-Account calls everywhere, (3) CloudTrail Org Trail event noise. Even big tech like Netflix and Amazon group by domain (Bounded Context) and separate services within each domain using IAM Role. On the Pro exam, "microservice per account" is usually a trap.

📚 Case study: Capital One scaled to roughly 2,500 accounts (as of 2022). But all were auto-created by a vending machine, had consistent baselines, and were IaC-managed in SCM. So despite many accounts, operational burden is light because of automation. Without automation, more accounts mean the ops team collapses.

Management Account Risk and Isolation Pattern

The Management account is the Organization's headquarters. If compromised, all member accounts are at risk. It has the highest security demands.

⚠️ Pitfall: SCP doesn't apply to Management accounts. Billing rolls up to Management, but policies are members-only. On the Pro exam, "block unauthorized regions in Management via SCP" is a 100% trap.

🔍 Going deeper: In 2022, AWS strengthened Organizations' trust model for GovCloud / China Regions / separate partition environments. Patterns emerged: move Management IAM Users to a separate partition or automate break-glass procedures. Some enterprises enforce Management account dual sign-in (two-person rule) + all actions sent via SNS to the security team. Like nuclear launch procedures with dual control.

New Account Auto-Creation: 4 Options

🔍 Going deeper: CreateAccount API is async. The call returns only CreateAccountRequestId; actual creation takes minutes to hours in the backend. Must poll with DescribeCreateAccountStatus. Bulk-creating 100 hits quota throttling; SQS + Step Functions to serialize is the standard pattern.

Consolidated Billing: Effects of Payment Integration

💡 Memory tip: Automatically applied on Org join. No extra setup. RI/SP sharing requires Linked Account Sharing option on (default is ON).

⚠️ Pitfall: Cost Explorer is only fully visible from Management. Member accounts see only their own. To split costs by department, Cost Allocation Tag must be enabled and tagged on all resources.

Trusted Access and Delegated Administrator

Certain AWS services (CloudFormation StackSets, GuardDuty, Security Hub, Config, IAM Access Analyzer, etc.) need "Trusted Access" enabled to operate at the Org level. Then Delegated Administrator can be appointed.

🔍 Going deeper: Delegated Administrator reduces Management's burden of operating security tools. Example: Management handles only billing; Audit account becomes GuardDuty Delegated Admin to collect threat detection results from all members. This separation of billing and security responsibilities is key.

CLI Direct Look

# Create Org (once, in Management account)
aws organizations create-organization --feature-set ALL
 
# Create OU
aws organizations create-organizational-unit \
  --parent-id r-xxxx --name Workloads
 
# Create new account (async)
aws organizations create-account \
  --email prod-app-a@example.com \
  --account-name "App-A-Prod"
 
# Poll creation status
aws organizations describe-create-account-status \
  --create-account-request-id car-xxxxx
 
# Move to OU
aws organizations move-account \
  --account-id 111111111111 \
  --source-parent-id r-xxxx \
  --destination-parent-id ou-yyyy
 
# View full Org structure
aws organizations list-roots
aws organizations list-organizational-units-for-parent --parent-id r-xxxx
aws organizations list-accounts-for-parent --parent-id ou-yyyy

Summary

The picture we've drawn today is threefold. First, multi-account is a tool solving 4 distinct dimensions simultaneously: isolation, billing, compliance, operations. Second, Organizations operates on a 3-layer hierarchy of Root → OU → Account, and OUs group by common policy, not org chart. Third, Management accounts hold billing and Org management only—never deploy workloads—and new accounts are automated via Account Factory (or AFT).

This threefold vision is the starting point of Domain 1. Next we explore Service Control Policy (SCP) attached atop OUs. SCP is the most frequently appearing single topic in the Pro exam, and understanding "it's a ceiling, not a grant" is half the battle.