2.2.2.1. AWS Account Structures & Best Practices

2.2.2.1. AWS Account Structures & Best Practices

A single AWS account is a single blast radius. One compromised credential, one misconfigured IAM policy — and everything in that account is affected.

AWS recommended account structure:

• Management account: Only for Organizations management and billing. No workloads.
• Security account: Centralized CloudTrail, GuardDuty, Security Hub
• Log archive account: Immutable storage for audit logs (S3 with Object Lock)
• Shared services account: Active Directory, DNS, CI/CD pipelines
• Workload accounts: Separate per environment (dev/staging/prod) per application

Organizational Units (OUs) group accounts for policy inheritance:

Root
├── Security OU          → Security + Log Archive accounts
├── Infrastructure OU    → Shared Services, Networking
├── Workloads OU
│   ├── Production OU    → Strict SCPs, change management
│   ├── Staging OU       → Moderate restrictions
│   └── Development OU   → Permissive, cost controls
└── Sandbox OU           → Experimental, auto-cleanup

Account vending: Control Tower's Account Factory automates new account creation with pre-configured guardrails, VPC settings, and SSO access. For custom provisioning, use Service Catalog with a CloudFormation template that calls organizations:CreateAccount.

Shared VPCs (AWS RAM): the networking account owns the VPCs and shares subnets with accounts in the same organization through AWS Resource Access Manager, so workload teams launch EC2, RDS or Lambda into central subnets without building their own VPCs (VPC peering and Transit Gateway instead connect separate VPCs). Only the owner manages the VPC, subnets, route tables and NACLs. Each participant creates and manages its own security groups and resources, and can't modify the owner's or other participants' — unless the owner explicitly shares a security group with it.

Exam Trap: The management account cannot be restricted by SCPs — SCPs only affect member accounts. Workloads should never run in the management account. To restrict actions in the management account, use IAM policies and permission boundaries, not SCPs.