Multi-account structure as a security decision
Twenty accounts with no owner and no guardrails are worse than three accounts with both, so the number is not the goal and account sprawl is a real failure mode. What makes the boundary worth the administrative cost is that it is the only cloud control that survives a full administrative compromise: permissions do not cross an account boundary unless something explicitly allows them to. Every other control on this pillar is editable by an account administrator. This one is not.
When is a single account still the right answer?
Almost never for production, but the honest threshold is lower than the reference architectures imply. If you are one team running one product with no regulated data, the minimum structure worth having is three: one for production, one for everything else, and one to hold logs that neither of the others can reach. That is a day of work, and it delivers most of the containment benefit available.
The reason to stop there for a while is that each account carries recurring cost in access, network connectivity, tooling enrolment and someone remembering it exists. Accounts created faster than they can be enrolled become the estate's blind spots, and an unenrolled account is where the incident happens because it has no logging, no guardrails and no owner. Growth should be driven by a specific need rather than by a diagram.
The needs that genuinely justify more are concrete: a workload with different regulatory obligations, a team whose mistakes must not reach another team's data, anything intentionally public, a sandbox where people can experiment without touching anything real, and separate security tooling so an intruder in a workload account cannot disable the tooling watching it.
What does an account boundary actually give you?
A default of no access, which no other mechanism in cloud provides. Inside an account, isolation depends on policies being written correctly and staying correct, and a single over-broad grant collapses it. Across accounts, access requires a deliberate arrangement in both directions, so an intruder holding administrator rights in one account has, by default, nothing in the next one. That is the entire argument, and it is sufficient on its own.
There are practical benefits alongside it. Service quotas are per account, so one runaway workload cannot exhaust capacity another depends on. Cost becomes attributable without relying on tagging discipline nobody sustains. Blast radius from automation is bounded, which matters because infrastructure code applied to the wrong target is a more frequent cause of damage than attackers. And an account can be closed, which is the cleanest possible end state for a project or an acquisition.
The vocabulary differs by provider while the concept holds, and mapping it early avoids a great deal of confusion in mixed estates. The table below gives the equivalences that matter for security design rather than a full feature comparison.
| Purpose | AWS | Azure | Google Cloud |
|---|---|---|---|
| Top-level container | Organisation | Tenant | Organisation |
| Grouping for policy | Organisational unit | Management group | Folder |
| Primary isolation unit | Account | Subscription | Project |
| Preventive policy from above | Service control policy | Azure Policy with deny effect | Organisation policy constraint |
| Identity source | Identity Centre or external provider | Entra ID | Cloud Identity or Workspace |
| Where logs should land | A dedicated log archive account | A dedicated logging subscription | A dedicated logging project |
What does a landing zone need, and what is over-built?
Six things do the work: an organisation with a grouping structure, federated human identity so nobody has local credentials, a log archive the source accounts cannot touch, preventive policies applied from above, a network baseline including address planning, and a repeatable way to create a new account with all of that already applied. Everything else in a landing zone offering is refinement on top of those.
The common over-build is network. A full transit topology with inspection appliances, redundant connectivity and centralised egress is a serious piece of engineering that a two-workload estate does not need, and building it first delays the account structure and the guardrails, which deliver more security per day of effort. Address planning is the part you cannot defer, because overlapping ranges block future connectivity and are painful to fix later.
The second over-build is process. An account creation pipeline with approvals, budgets and a service catalogue is worth building at twenty accounts and is a distraction at five, where a documented checklist and a template achieve the same result. Judge each element by whether it would have prevented or contained a plausible incident, and defer the ones that only make a diagram tidier.
Which structural mistakes are expensive to undo?
Running workloads in the organisation's management account is the most costly, because that account holds the policy and billing authority for everything else. Once applications live there, engineers and pipelines need access to it, and the account you most needed to keep quiet becomes the busiest. Separating it later means migrating workloads, which usually means recreating resources rather than moving them.
Overlapping address ranges come second. Two accounts using the same private range cannot be connected without translation, and the discovery usually happens when a business requirement demands the connection at short notice. Allocate ranges from a central plan on the day you create the second account, even if you have no intention of connecting anything, because the allocation costs nothing and the retrofit is a project.
Third is organising accounts around the organisation chart. Reorganisations happen every couple of years, and a structure keyed to team names then describes a company that no longer exists, leaving accounts whose grouping implies policies that no longer suit their contents. Group by the policy the workloads need instead: regulated, production, non-production, sandbox, public. Those categories are stable, which is the only property that matters for a structure you cannot easily change.
How do you keep new accounts from becoming blind spots?
Make enrolment part of creation rather than a follow-up task. A new account should arrive with logging pointed at the archive, guardrail policies inherited from its group, security tooling read roles in place, federated access configured, an owner recorded and a budget alert set. If any of those is a manual step performed afterwards, some proportion will be skipped, and the skipped ones cluster in the accounts created in a hurry.
Then reconcile regularly against the source of truth, which is the provider's own account list and your billing data, not your inventory spreadsheet. Compare that list against enrolment in each central control and treat any account appearing in billing but not in logging as an incident to close this week. This one report catches most of the ways an estate silently loses coverage, including accounts created outside the process and accounts inherited through acquisitions.
Record an owner as a person or a rota, not a team name that may not exist next year, and re-confirm ownership periodically. Unowned accounts are where credentials go stale, where public resources survive and where nobody responds to a finding, and the correlation between unowned accounts and incidents is strong enough to justify treating ownership as a control in its own right.
What can you check this week?
Pull the list of every account, subscription or project in your organisation from billing rather than from documentation, then answer three questions for each: who owns it, is it sending logs to the archive, and does it inherit your preventive policies. The gap between the billing list and the enrolled list is the most useful security number most organisations have never calculated.
Then look specifically at the management account and list every workload, pipeline and human with access to it. Anything there that is not policy, billing or identity administration is a candidate for migration, and knowing the size of that job now is better than discovering it during an incident when you would like to restrict access sharply.
Finally, check who can create a new account and whether that action alerts anybody. Account creation is a legitimate operation that also makes an excellent hiding place, because a new account starts with no monitoring and no owner, and in many organisations nobody would notice one appearing for months.
Common questions
- Why use multiple cloud accounts instead of one?
- Because an account boundary is the only cloud control that survives a full administrative compromise. Inside an account, isolation depends on policies staying correct, and one over-broad grant collapses it. Across accounts, access requires a deliberate arrangement on both sides, so an attacker holding administrator rights in one account has nothing in the next by default. Quotas, cost attribution and bounded automation blast radius come as secondary benefits.
- What is the minimum sensible cloud account structure?
- Three: production, non-production, and a log archive the other two can write to but cannot read, modify or delete. That takes about a day to set up and provides most of the containment available. Add accounts for specific reasons after that, such as differing regulatory obligations, intentionally public content, a sandbox, or separate security tooling. Accounts created faster than they can be enrolled become the estate's blind spots.
- What should a cloud landing zone include?
- An organisation with a grouping structure, federated human identity so nobody holds local credentials, a log archive the source accounts cannot touch, preventive policies applied from above the account, a network baseline including a central address plan, and a repeatable way to create an account with all of that already applied. Other elements are refinements, and a full transit network is usually premature.
- Should workloads run in the cloud management account?
- No, and this is the most expensive structural mistake to reverse. The management account holds policy and billing authority for the whole organisation, so once applications live there, engineers and pipelines require access to the account you most needed to keep quiet. Moving them later generally means recreating resources rather than migrating them, along with copying data and changing addresses.
- How should cloud accounts be grouped?
- By the policy the workloads need, not by the organisation chart. Categories like regulated, production, non-production, sandbox and public content are stable across reorganisations, while team-based grouping describes a company that changes every couple of years and leaves accounts inheriting policies that no longer suit their contents. Stability is the property that matters most for a structure that is awkward to change.
- How do you stop new cloud accounts becoming unmonitored?
- Make enrolment part of creation. A new account should arrive with logging directed at the archive, inherited guardrail policies, security tooling access, federated sign-in, a recorded owner and a budget alert. Then reconcile the provider's billing list against enrolment in each central control on a schedule, and treat any account that appears in billing but not in logging as something to fix that week.
