Multi-Account / Landing Zone Strategy & Governance

Multi-Account / Landing Zone Strategy & Governance

The single account that becomes a liability

Every cloud journey starts in one account. Dev, staging, and prod all share it. Everyone has broad access because it's easier. The bill is one big undifferentiated number. It works, right up until it doesn't. A test script in "dev" deletes a production bucket. A leaked key has the keys to the entire kingdom. Finance asks what the data team spent and nobody can answer. One account means one blast radius, and that radius is everything.

This is why mature organizations deliberately run many accounts, sometimes hundreds, and tie them together under a single organization with central governance. It feels like more complexity, and it is, but it buys you isolation, clean billing, and enforceable guardrails that a single account fundamentally cannot provide. This article explains the why and the how: org structure, OUs, SCPs, centralized logging and identity, and the thing that ties it together, a landing zone.

Note: Who this is for: Engineers and platform/architecture folks moving beyond a single account toward real organizational structure. We use AWS Organizations terms (accounts, OUs, SCPs); Azure (management groups + subscriptions) and GCP (folders + projects) have direct equivalents.

Why many accounts beats one big one

An account is the strongest isolation boundary the cloud gives you. Many accounts means many independent blast radii - a failure or breach in one is naturally contained from the rest. Think of accounts as separate buildings rather than rooms in one building. A fire in one building doesn't spread; a key to one building doesn't open the others; you can meter each building's utilities separately. That's exactly what the multi-account model gives you:

One account = one building with everything inside. Multi-account = a campus of isolated buildings.

• Blast-radius isolation - a compromised or misconfigured account can't reach into the others.
• Environment separation - prod lives in its own account, so dev experiments physically cannot touch it.
• Clean billing & cost attribution - each account is a billing line, so you know exactly what each team/workload costs.
• Tailored guardrails - a sandbox account can be permissive; a production account locked down. One size never fits all.

The shape of an organization

Accounts are grouped into a tree. At the top sits a management account (it does almost nothing except own the org and consolidate billing - you do not run workloads in it). Below it, organizational units (OUs) group accounts by purpose, and policies attached to an OU flow down to every account inside it.

• Management account at the root: It owns the organization and consolidates billing for every account. It holds no workloads and almost no users - its blast radius must be near zero, because compromising it compromises everything.
• OUs group accounts by intent: Prod, Non-Prod, Sandbox, Security. Grouping by purpose means you write a policy once and it applies to every account in that OU, and every new account you add later.
• Guardrails attach to OUs: A Service Control Policy on the Prod OU (say, "deny disabling CloudTrail") automatically governs every production account, present and future. That's the leverage of the tree.
• Shared services are centralized: Logging and identity get their own accounts so every workload account streams logs to one tamper-resistant place and authenticates against one identity source.

Guardrails: SCPs set the outer boundary

A Service Control Policy (SCP) is the most important governance tool in the model. It does not grant permissions - it sets the maximum boundary of what's possible in an account, no matter what IAM permissions someone has. Even a full administrator in a workload account cannot do something an SCP forbids. It's a ceiling that IAM operates beneath.

scp-deny-leave-org.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrgAndDisableLogging",
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization",
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    }
  ]
}

Attach that to the org root and no account anywhere can leave the organization or turn off its audit trail - not even a root user. SCPs are how you enforce "thou shalt not" rules organization-wide.

The mental model: SCPs define what's permissible; IAM defines what's permitted within that. If you're shaky on that distinction, start with cloud IAM from first principles.

SCPs and IAM are complementary, not competing - a permission must be allowed by BOTH to take effect.

Warning: Don't lock yourself out: SCPs apply to everyone, including your automation and break-glass roles. A too-broad deny (e.g. denying a whole region or service your CI uses) can silently break deploys org-wide. Always exempt your platform/automation roles via condition keys, and test SCPs on a non-prod OU before touching the root.

Centralize logging and identity

Two things should never be scattered across accounts: your logs and your identities. Both get their own dedicated accounts.

Centralized logging: Every account streams its audit logs (CloudTrail, config history) into a single, dedicated log-archive account that almost nobody can write to or delete from. Why: if an attacker compromises a workload account, they cannot also erase the evidence - the logs live somewhere they can't reach. Centralized logs are also how you investigate across the whole org from one place instead of stitching together dozens of accounts.

Centralized identity: You do not create separate users in every account - that's unmanageable and insecure. Instead, identity lives in one place (an identity provider / SSO) and people assume short-lived roles into the accounts they're allowed to touch. One person, one identity, scoped access to many accounts, no long-lived credentials sprawled everywhere.

Tip: The single biggest security win of the multi-account model: humans get zero standing access to production. They authenticate centrally and assume a time-limited role only when needed, every action logged to the tamper-resistant archive. That alone closes off a huge class of incidents.

So what is a 'landing zone'?

Everything above - the org tree, OUs, SCP guardrails, centralized logging, centralized identity, a baseline of security settings, assembled and automated as a starting point - is a landing zone. It's the pre-built, governed foundation you land new workloads into, so every account is born compliant instead of being secured after the fact.

A landing zone is a pre-configured, secure, multi-account environment - the governed "ground" your teams build on, so nobody starts from a blank, ungoverned account. The key benefit is secure by default at account creation. When a team needs a new account, they request one and it's vended automatically, already in the right OU, already covered by the right SCPs, already streaming logs to the archive, already wired to central identity. Nobody has to remember to bolt on security.

AWS Control Tower, Azure Landing Zones, and GCP's foundation blueprints are managed implementations of exactly this idea.

Tip: You don't need hundreds of accounts on day one. Start small: a management account, a log-archive account, and separate prod/non-prod accounts. The pattern matters more than the count - get the tree, the guardrails, and centralized logging right early, because retrofitting governance onto a sprawl of accounts later is genuinely painful.

Common mistakes that cost hours

• Running workloads in the management account. It owns billing and the whole org - its blast radius must be minimal. Keep it nearly empty; never deploy apps there.
• Writing SCPs that lock out your own automation. A broad deny that catches your CI/CD or break-glass role breaks deploys silently across every account. Exempt platform roles and test on non-prod first.
• Letting each account manage its own logs. If logs live in the same account as the workload, an attacker who owns the account owns the evidence. Stream everything to a separate, write-restricted archive.
• Creating IAM users in every account. That's credential sprawl waiting to leak. Centralize identity and use assumed, short-lived roles.
• Treating SCPs as permission grants. SCPs only ever restrict. If you attach an SCP and expect it to give access, you'll be confused for an afternoon. IAM grants; SCPs cap.
• Retrofitting governance too late. Bolting OUs and guardrails onto 80 ungoverned accounts is far harder than getting the structure right while you have three.

Takeaways - The whole article in eight lines

1. One account = one blast radius covering everything. Mature orgs use many accounts on purpose.
2. Accounts are the strongest isolation boundary: separate buildings, not separate rooms.
3. Multi-account buys blast-radius isolation, environment separation, clean billing, and tailored guardrails.
4. Org tree: management account (billing only) → OUs (group by purpose) → workload accounts.
5. SCPs set the outer boundary of what's possible; IAM grants permissions beneath it. Access = intersection of both.
6. Centralize logging (tamper-resistant archive) and identity (SSO + short-lived roles).
7. A landing zone is all of this pre-built and automated, so new accounts are secure by default.
8. Get the structure right early - retrofitting governance onto a sprawl is the expensive path.

Where to go next

Governance sits on top of identity and the cloud's resource hierarchy. Solidify those, then design your org structure.

• Cloud IAM from first principles - the identity model SCPs and central identity build on.
• Cloud resource hierarchy (concept lab) - how accounts, OUs, and resources nest.
• The Cloud Engineer path - the full progression from fundamentals to governance.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.