A landing zone is the account structure, identity model, network topology, logging pipeline and guardrails that everything else in a cloud organization is built on top of. It is the layer no workload owns and every workload inherits. Get it right and most security and compliance questions have boring answers. Get it wrong and every subsequent decision is made inside a constraint nobody chose.
The reason it matters more than it looks is simple: the account boundary is the strongest isolation a cloud provider gives you. A security group is a rule inside an environment. An IAM policy is a rule inside an account. An account boundary is enforced above both, by the provider, and it holds even when the thing inside it is compromised. It is also the boundary that billing, quotas, audit scope and blast radius all happen to follow.
Why account structure is a security control
Most teams arrive at the multi-account question from the wrong direction. They start with one account because one account is simple, add a second when production and development collide, and end up with a structure that records their history rather than their requirements.
Three properties make the account boundary different from anything inside it:
- It is enforced by the provider. Cross-account access has to be granted explicitly. There is no default path, no shared network, no accidental permission inherited from a policy someone wrote in a hurry.
- It is the natural audit scope. “Which systems handle regulated data” becomes a list of accounts instead of a survey of tags.
- It fails safe. A misconfiguration inside an account is contained by the account. A misconfiguration in a single shared account is contained by nothing.
The trade-off is real: more accounts mean more automation is required, because manual management does not scale past about three. That is the actual decision. Not “how many accounts” but “are we willing to automate the boundary we need”.
A worked example: 14 accounts, 2 organizational units
Abstract advice about landing zones is easy to agree with and hard to use. So here is a concrete one. The AWS Enterprise Baseline — the AWS edition of the BuiltForProd Baseline — deploys one AWS Organization with 14 accounts across 2 organizational units. The numbers below describe that edition specifically.
The management account is empty
core-root sits outside both organizational units and runs nothing. It exists to own the organization: the account tree, the service control policies, the tag policy. That is all.
This is the decision in the layout that pays back the most for the least effort. The management account is the one account that can change the rules everything else lives under. If a workload runs there, then compromising that workload means compromising the guardrails, and every other control in the organization is downstream of a thing an attacker now owns. Keeping it empty is not fastidiousness. It removes an entire class of incident.
Nine core accounts, each with one job
| Account | What lives there | Why it is separate |
|---|---|---|
security |
Delegated administration for the security services, and the observability sink | The account that watches everything should not be an account that runs anything |
audit |
The log archive and the configuration aggregator | Evidence must survive a compromise of the thing it is evidence about |
identity |
The single sign-on directory and permission sets | One place to grant and, more importantly, revoke |
network |
The hub network, address management, private DNS | Network topology is shared infrastructure, not a workload concern |
dns |
Public DNS zones | Public name resolution has a different risk profile from private |
artifacts |
Container registries | Build outputs are shared across environments and outlive any one of them |
auto |
CI/CD federation, deployer roles, runners | The automation identity is a high-value target; it gets its own boundary |
corp |
Internal tooling | Employee-facing systems are not customer-facing systems |
public |
Assets that are deliberately public | Making “public” an explicit place stops it becoming an accident elsewhere |
The pattern is the same in every row: a capability that belongs to the organization rather than to a workload gets its own boundary, so that granting access to it is a deliberate act.
Four workload accounts from one template
sandbox, dev, staging and prod are generated from a single definition. They differ in sizing, retention and who may act in them — not in structure. That is what makes “it works in staging” a meaningful sentence: staging and production are the same code with different inputs, so a difference between them is a bug rather than a fact of life.
Prod is also where the network stops being permissive. In this edition, the transit gateway carries deliberate blackhole routes between the production and non-production isolation domains: they cannot reach each other, by construction rather than by firewall rule.
The test: what does adding an account cost?
A landing zone is healthy when growth is cheap. The question to ask about any structure — yours or a vendor’s — is not how many accounts it has today. It is what happens when you need the fifteenth.
In the AWS Enterprise Baseline, a new account is an entry in a map and a folder in a repository: two pull requests, reviewed and applied by the same pipeline as everything else. The same property holds for regions. A region is a folder; the address plan, the region-restriction policy and the tag policy discover it automatically. The address plan itself is sized for 16 regions with 8 workload stages each, so expansion is a decision rather than a redesign.
When adding an account is a project, three things follow, and they follow every time: teams share accounts they should not share, environments diverge because nobody wants to touch the structure, and the eventual restructure lands during the quarter when something urgent is already happening.
What a landing zone does not solve
Being honest about the boundary of the idea:
- It does not make your application secure. It makes the failure of your application survivable.
- It does not produce compliance. It produces the evidence sources that make compliance work possible — a different and much smaller claim. We wrote about that distinction in SOC 2 on cloud infrastructure.
- It does not remove the need for people who understand it. It reduces the number of things they have to hold in their heads, and it writes the rest down.
Where to start
If you are on a single account today, the useful first move is not a migration. It is a map: list every system, the data it touches, who may change it, and what would happen if it were compromised. The account boundaries usually draw themselves from that list, and the ones that do not are the ones worth arguing about.
If you would rather inherit a structure than design one, that is what the BuiltForProd Baseline is: a foundation deployed into your own accounts, with the repositories and documentation handed over, so the thing you run is yours rather than rented. If you want an outside read first, the BuiltForProd Assessment exists for that, and we will tell you if we are not the right fit.