Free lesson · DevOps and Platform Engineering on AWS
The multi-account landing zone - designing the account topology
The Account Is The Only Boundary That Holds
Course 1 Module 01 Topic 7 established the multi-account structure and Module 10 Topic 11 covered Control Tower. This topic is the design decision: how many accounts, split by what, and why.
The premise everything rests on:
Important: An account boundary cannot be misconfigured around. Every other isolation mechanism - a security group, an IAM policy, a naming convention, a tag - is a rule someone can get wrong, and eventually someone does.
A typo in a resource name deploys to the wrong environment. A typo cannot cross an account boundary, because the credentials are different, the endpoints are different, and there is no path.
That single property is why account topology is the most consequential design decision in a platform, and why it is worth spending real time on before there are forty accounts to reorganise.
Five things an account boundary gives you at once: a security blast radius, cost attribution with no tagging discipline required, a service quota boundary, a compliance scope boundary, and an IAM namespace.
What Should Drive A Split
| Driver | Split when |
|---|---|
| Environment | Always. Production is a separate account from non-production. |
| Blast radius | A failure or compromise here must not reach there |
| Compliance scope | Keeping PCI or HIPAA scope small - Course 1 Module 10 Topic 13 |
| Quota isolation | One workload's scaling must not consume another's limits |
| Cost attribution | A team or product needs an unambiguous bill |
| Different security posture | A sandbox and a regulated workload cannot share controls |
| Team autonomy | A team needs to move without coordinating |
Environment is non-negotiable. Everything else is a judgement about how far to go.
The Core Structure
graph TD
R[Root] --> M[**Management account**<br/>Organizations only.<br/>No workloads. Ever.]
R --> SEC[Security OU]
R --> INF[Infrastructure OU]
R --> WL[Workloads OU]
R --> SB[Sandbox OU]
R --> SUS[Suspended OU]
SEC --> LA[Log Archive]
SEC --> AUD[Security Tooling]
INF --> NET[Network / Shared Services]
INF --> TOOL[CI/CD Tooling]
INF --> BAK[Backup]
WL --> PROD[Prod OU]
WL --> NP[Non-Prod OU]
PROD --> P1[workload-a-prod]
PROD --> P2[workload-b-prod]
NP --> N1[workload-a-dev]
NP --> N2[workload-a-staging]
This diagram shows a multi-account organisation structure. Under the root sits the management account, which runs Organizations only and never hosts workloads. Alongside it are organisational units for Security, Infrastructure, Workloads, Sandbox, and Suspended accounts. The Security organisational unit contains the Log Archive and Security Tooling accounts. The Infrastructure organisational unit contains Network and Shared Services, CI/CD Tooling, and Backup accounts. The Workloads organisational unit splits into Production and Non-Production, each containing per-workload accounts.
Warning: Nothing runs in the management account. This is the most consequential structural rule and it is violated constantly.
Service Control Policies do not apply to the management account. Its root user cannot be restricted. It holds the organisation's billing and the ability to close every member account. A compromise there is a compromise of everything, and none of your guardrails apply.
It happens because the management account is the first one created, so the initial experiments land there and never leave. If you have workloads there now, migrating them is a priority ahead of almost anything else in this course, and it gets harder every month.
The core accounts, and what each is for:
| Account | Holds | Why separate |
|---|---|---|
| Log Archive | CloudTrail, Config, centralised logs | An attacker in a workload account cannot delete the evidence |
| Security Tooling | GuardDuty, Security Hub, Detective, Macie delegated admin | Security team's blast radius, separate from workloads |
| Network | Transit Gateway, shared VPCs, DNS, Direct Connect | Central network ownership, shared via RAM |
| CI/CD Tooling | Pipelines, artifact stores | Holds deployment credentials for every environment |
| Backup | Backup vaults, with Vault Lock | Ransomware isolation - Module 05 Topic 3 |
| Identity | Identity Center, if not delegated | Access control plane |
Log Archive and Backup deserve the strongest isolation in the estate, because both exist specifically for the scenario where another account is compromised.
How Far To Split Workloads
The judgement call, and there are three common models.
| Model | Accounts | Suits |
|---|---|---|
| Per environment only | 2–4 total | Small teams, one product |
| Per team per environment | Teams × environments | Mid-size, team-aligned ownership |
| Per workload per environment | Workloads × environments | Large, strong isolation requirements |
Tip: Per-workload-per-environment is the strongest isolation and it has a real cost that is rarely modelled. Every account needs its own VPC endpoints, its own NAT Gateways or a shared egress path, its own baseline services, and its own place in every cross-account permission model.
VPC endpoints and NAT are the specific line items. Interface endpoints are charged per endpoint per Availability Zone per hour, so ten accounts each with eight endpoints across three AZs is 240 endpoint-hours continuously - before any traffic. At forty accounts that is a substantial number for something with no workload attached.
The mitigations are architectural: centralised endpoints in the network account shared via PrivateLink and Route 53 Resolver rules, and centralised egress through a shared NAT. Module 01 Topic 3 covers both. Design that in before you have forty accounts, because retrofitting it means renumbering routing across all of them.
A reasonable default: per-team-per-environment for most workloads, with per-workload accounts reserved for anything with a genuinely different security posture, a compliance scope you want to keep small, or a blast radius requirement.
Rough sizing: an organisation of 50 engineers typically lands between 10 and 25 accounts. At 500 engineers it is hundreds. If the number feels uncomfortable, the problem is usually that account creation is manual - with vending automated, an account is a cheap unit.
OUs Are For Policy, Not For The Org Chart
An OU exists to attach a Service Control Policy to a set of accounts. That is its function.
Structuring OUs to mirror the organisational chart is the common mistake, and it produces a tree that reorganises every time the company does - while the policies you actually need are environment- and workload-shaped.
Structure by policy requirement: production accounts need a stricter SCP than development, so they belong in different OUs. A regulated workload needs different controls, so it gets its own OU.
Two OUs worth having that people forget:
A Suspended OU with a deny-almost-everything SCP. Moving a decommissioned account there stops it accruing cost and stops anything running, while retaining the account and its audit history for the retention period. It converts "we should close that account eventually" into an immediate reversible action.
A Policy Staging OU containing one throwaway account, for testing SCPs before they reach anything real. Module 05 Topic 1 explains why this matters more than it sounds.
Account Vending
Manual account creation is what keeps organisations at too few accounts, because each one is a ticket and a week.
Vending should deliver an account with: organisation membership and correct OU placement, CloudTrail and Config flowing to Log Archive, GuardDuty and Security Hub enabled via delegated admin, Identity Center permission sets assigned, a budget with alerts, required tags, network attachment or an explicit decision of none, default EBS encryption, the default VPC removed, and a named owner.
Control Tower Account Factory, AFT, or your own automation - Course 1 Module 10 Topic 11 compares them. The mechanism matters less than the property: an account arrives compliant, and nothing depends on someone remembering.
Metadata on the account itself - owner, cost centre, environment, data classification, and a review date. Account tags are available in Organizations and they are what makes an inventory possible later.
The Lifecycle Nobody Designs
Accounts get created and never closed. Design the other end:
Request and approval - who may request, who approves, what information is required.
Ownership validation - an account whose owner has left is an account nobody reviews. Validate periodically against your directory.
Decommissioning - confirm no dependencies, export anything worth keeping, move to the Suspended OU, wait a defined period, then close. Note that closing an account is subject to a waiting period and cannot be undone afterwards.
Migrating From One Account To Many
The realistic starting position for most organisations.
The sequence that works:
- Enable Organizations from the existing account, which becomes the management account.
- Create the core accounts - Log Archive, Security Tooling, Network, Tooling.
- Move centralised services out - CloudTrail to Log Archive, security tooling to its account.
- Empty the management account. Anything running there moves first.
- Create new workloads in new accounts - stop adding to the original.
- Migrate existing workloads by criticality, lowest first.
Warning: The original account is now the management account and it probably has workloads in it. That inversion is the awkward part of every migration and there is no clean shortcut.
The alternative some organisations take is creating a new management account and inviting the original in as a member - which is cleaner structurally and means the original's identity, billing history, and existing agreements move rather than stay. Evaluate both before starting, because switching approach later is expensive.
Either way, emptying the management account is the highest-priority item, ahead of migrating anything else. Every day workloads remain there is a day your guardrails have an exception.
When Not To Split
Too many accounts is its own failure mode.
The costs: cross-account IAM complexity multiplied, per-account baseline services, endpoint and NAT charges, more places for configuration to drift, and an operational surface that grows faster than the value.
The signal you have gone too far: engineers spend meaningful time on cross-account access rather than on the workload, or the platform team's work is dominated by account plumbing.
The signal you have not gone far enough: a change in one team's workload affects another's, cost cannot be attributed without an argument, or a compliance audit scopes the entire estate because nothing is segmented.
Common Failure Modes
Warning: Workloads in the management account. No SCPs apply.
OUs mirroring the org chart. Reorganises constantly, policies do not fit.
Log Archive not isolated. An attacker deletes the evidence.
No Suspended OU. Decommissioning never happens.
No Policy Staging account. SCPs tested in production.
Manual account creation. Keeps the estate at too few accounts.
No account baseline. Compliance depends on memory.
Per-account endpoints and NAT unmodelled. A large charge with no workload attached.
No account owner, or an owner who has left.
No decommissioning process. Accounts accumulate forever.
CIDR allocation not planned before accounts multiply. Module 01 Topic 3.
Splitting further than the team can operate.
Why This Matters In An Interview
Interview: This is a senior platform design question and the strong answers cover both directions - why to split and why not to.
What interviewers are listening for:
- The account as the only boundary that cannot be misconfigured around.
- Nothing in the management account, with the SCP reason.
- OUs structured by policy, not by org chart.
- The cost of splitting, named specifically.
Common follow-ups:
- "How many accounts should a 200-person engineering organisation have?" → Environment split is non-negotiable, then per team or per workload depending on isolation needs - likely 40 to 100. Then note that the number is only manageable with automated vending, and that per-account endpoint and NAT costs need a centralised design.
- "Why can't workloads run in the management account?" → SCPs do not apply to it and its root user cannot be restricted. Every guardrail you build has an exception there.
- "You have one account with everything in it. What is the migration path?" → Enable Organizations, create the core accounts, move centralised services, empty the management account first, create all new workloads in new accounts, then migrate existing ones by criticality. Consider a fresh management account with the original invited as a member.
- "What is the cost of too many accounts?" → Per-account baseline services, endpoint and NAT charges, cross-account IAM complexity, and operational surface. Centralised endpoints and egress mitigate the first two, and they must be designed early.
Practice
Exercise: Starter. Audit an existing organisation: what runs in the management account, whether Log Archive is isolated, and whether every account has an identifiable owner.
Intermediate. Design the OU structure for a stated organisation, justifying each OU by the SCP it will carry rather than by the team it represents.
Advanced. Model the cost of per-workload-per-environment accounts at your projected scale, including per-account endpoints and NAT. Compare against a centralised endpoint and egress design.
Related Topics
- Topic 2 - Identity across these accounts
- Topic 3 - Network topology and the centralised services that make many accounts affordable
- Module 05 Topic 1 - SCPs attached to these OUs
- Course 1 Module 01 Topic 7 - The multi-account model
- Course 1 Module 10 Topic 11 - Control Tower and account vending