AWS Account Structure Diagram
The multi-account layout that makes an AWS estate governable — what each account is for, the guardrails that apply across all of them, and the network boundaries, drawn as separations rather than steps.
SVG. No sign-up, no email.
The most consequential AWS decision is not which services to use. It is how many accounts you have and what separates them. An account is the strongest isolation boundary AWS offers — stronger than a VPC, stronger than IAM policy — and organisations that started with one account and grew spend years unpicking it.
Accounts are boundaries, not steps#
Nothing in the top lane flows into anything else — that is the point of drawing it without arrows. Each account is a wall.
Management exists to own the organisation and the bill, and to do nothing else. No workloads, no experiments, minimal access. It is the account from which every guardrail is set, which makes it the account whose compromise is worst.
Security receives logs and findings from everywhere and is the one place an attacker who takes a workload account cannot reach. Audit trails written into the same account as the workload are evidence an intruder can edit.
Shared services holds the things genuinely used by everything: DNS, base images, build infrastructure. Keep this list short — it grows into a second production account otherwise.
Production and development are separate accounts, not separate VPCs. This is the separation that stops a development mistake becoming a production incident, and it is why the count of accounts is the decision that matters. Per workload is a reasonable default; per team is a common and workable alternative.
Guardrails apply everywhere, including to accounts that do not exist yet#
The middle lane is set once at the organisation level, and this is what makes a multi-account estate governable rather than merely numerous.
Service control policies define what cannot be done anywhere — including by an administrator, including in an account created next year. Deny leaving the organisation, deny disabling the audit trail, deny regions you do not operate in. These are cheap and they hold when everything else fails.
Central identity with roles assumed per account replaces long-lived keys in each account. Long-lived keys are the credential that appears in every public breach write-up, and the point of central identity is that there are none to leak.
An organisation-wide audit trail written to the security account, and Config plus budgets per account, complete the set: what happened, what changed, and what it cost — each answerable without asking the team that owns the workload.
Network boundaries#
A VPC per account means a network mistake is contained by the account boundary as well as the network one. Workloads sit in private subnets and are never directly public. VPC endpoints are worth calling out specifically: they keep traffic to AWS services off the public path and off the NAT gateway, which is charged hourly and per GB, and is a recurring entry on the list of bills nobody could explain.
Using this diagram#
Count your accounts. If the answer is one, the fastest meaningful improvement available is separating production from everything else — before any tooling, any tagging strategy, or any cost review. If the answer is many but the guardrails lane is empty, you have the overhead of multi-account with none of the control it exists to provide.