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.

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:

• 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.

1. 1

   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.

2. 2

   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.

3. 3

   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.

4. 4

   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.

{
  "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.

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.

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.

Common mistakes that cost hours

1. 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.
2. 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.
3. 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.
4. Creating IAM users in every account. That's credential sprawl waiting to leak. Centralize identity and use assumed, short-lived roles.
5. 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.
6. 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

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.