Building blocks
Design goal
Create a repeatable multi-account foundation that lets workload teams move independently without rebuilding identity, audit, security, and policy controls for every account.
Success criteria
- Separate security, infrastructure, and workloads
- Standardize account provisioning
- Centralize audit/security data
- Apply preventive and detective controls
Architecture
Use an organization/OU hierarchy with shared security accounts, governed workload accounts, centralized identity, and common logging/security controls.
Architecture flow
- Identity grants workforce access
- Organizations groups accounts into OUs
- Control Tower manages landing zone controls
- Security/log archive accounts centralize oversight
- Workload accounts host applications
Architecture decisions
Use accounts as isolation boundaries
WhySeparate workloads and environments into accounts where blast-radius, ownership, billing, or policy boundaries justify it.
Trade-offMore accounts reduce blast radius and clarify ownership, but increase provisioning, networking, identity, and cost-allocation overhead.
Centralize audit and security accounts
WhySecurity monitoring and logs should not depend on administrators of each application account.
Trade-offCentralization protects evidence from workload administrators, but the shared security accounts become high-value platform dependencies that need strong controls.
Networking
Make the traffic path explicit. Choose centralized or distributed network patterns based on scale, inspection requirements, and team ownership; keep routing domains intentional.
Security
Protect the control and data paths deliberately. Use IAM Identity Center, organization-level logging, security services, and OU/account controls with least privilege.
Availability
Design for the failure domain that must be survived. Landing-zone governance should not create runtime dependency for every workload; workloads design their own application availability.
Disaster recovery
Treat regional recovery as a separate operating state. Account/OU governance persists independently of workload DR. Recovery regions/accounts should still inherit required identity, logging, and controls.
Cost drivers
- Central log storage/analysis
- Security services
- Shared network services
- NAT/inspection
- Number of active workload environments
Design assumptions
- AWS Organizations can be used
- Central security/governance ownership is defined
Implementation plan
- Define the Organizational Unit and account model around ownership, environment, security boundaries, and policy inheritance.
- Deploy the Control Tower landing zone and separate log-archive and security responsibilities from workload accounts.
- Configure IAM Identity Center, permission sets, and privileged-access controls before onboarding application teams.
- Apply preventive and detective guardrails at the correct OU scope, with a documented exception process for workloads that cannot comply.
- Define account provisioning, baseline networking/logging, and lifecycle ownership, then validate the model with a pilot workload account.
Validate the design
- Create or enroll a test account and confirm the expected OU placement, guardrails, logging, and security services are inherited.
- Verify centralized audit logs cannot be altered by workload-account administrators.
- Review permission sets, SCPs, and break-glass access against the intended privilege boundaries.
- Exercise account suspension/closure or another lifecycle path and confirm central controls remain intact.