Landing Zones

A landing zone is the pre-built baseline the infrastructure lands on before the first workload ships. Account and organization structure, identity, network skeleton, logging, and guardrails are stood up once, as code, so every later environment inherits the same controls instead of re-deriving them by hand.

The structure of the landing zone fixes the blast radius. A flat single account puts production, staging, and the security tooling in one trust boundary; a multi-account organization with per-environment and per-team accounts contains a compromise to the account it started in. The same account boundaries reveal which credentials reach which systems, the first thing an attacker enumerates on contact.

        flowchart TB
  Root["Organization root"]
  Mgmt["Management account<br/>billing, policy, vending"]
  Root --> Mgmt
  Root --> SecOU["Security OU"]
  Root --> InfraOU["Infrastructure OU"]
  Root --> WorkloadsOU["Workloads OU"]
  SecOU --> Log["Log archive account"]
  SecOU --> Audit["Security / audit account"]
  InfraOU --> Net["Network hub account"]
  InfraOU --> Shared["Shared services account"]
  WorkloadsOU --> Prod["Prod accounts"]
  WorkloadsOU --> NonProd["Non-prod accounts"]
  WorkloadsOU --> Sandbox["Sandbox accounts"]
    

Hierarchy

The infrastructure is a tree. A single organization root owns everything, groups of accounts hang off it under organizational units, and the individual account is the hard isolation boundary where workloads actually run. Policy attaches to a node and flows down, so a control set on an organizational unit reaches every account beneath it without being copied.

The operator keeps the tree shallow enough to reason about and deep enough to separate what must not share a blast radius. Environments (prod, non-prod, sandbox) split first because they fail independently; teams and applications split underneath when their credentials should not reach each other. See Environments for the development, training, and operational tiers these accounts carry.

Accounts

A landing zone reserves a handful of foundational accounts before any workload account exists. Each one isolates a concern that would be dangerous to co-locate with running services.

Account	Purpose
Management	Organization root. Holds billing, organization policy, and account vending. Runs no workloads.
Log archive	Write-once destination for org-wide audit and access logs. Locked down so a compromised account cannot erase its tracks.
Security / audit	Read-only cross-account access for the security team and detection tooling. The seat the blue team works from.
Network	The shared network hub. Transit, central egress, DNS, and inspection live here.
Shared services	Directory, CI runners, golden images, and internal tooling used across the org.
Sandbox	Disposable accounts for experiments, isolated from production and capped on spend.
Workload	One per application and environment. Where the services the mission cares about actually run.

Guardrails

Guardrails are the controls the landing zone enforces from above so no account can opt out. Preventive guardrails block a disallowed action before it happens; detective guardrails flag drift after the fact. A guardrail left in detect-only mode is a tripwire, not a wall, and the operator should know which is which on a target.

Guardrail	Effect
Deny org leave	Block an account detaching itself from the organization.
Deny log tampering	Block disabling or deleting the organization audit trail.
Region lockdown	Deny resource creation outside approved regions.
Root user guard	Block root-credential use and access-key creation.
Public-access guard	Block public object storage and public disk snapshots.

A preventive guardrail is a policy document attached high in the tree. The denial below stops every account under it from leaving the organization, regardless of what permissions a local admin grants.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrg",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Identity

Identity is centralized once and federated everywhere. One identity provider holds the humans, the cloud trusts it through SSO, and permission sets map from groups onto accounts. No account carries local users, and no automation carries a long-lived key.

• Federate, one IdP via SAML or OIDC, MFA enforced, short sessions.

• Assume, never store, workloads take short-lived roles instead of holding keys.

• Scope by account, a group’s reach stops at the accounts its permission set names.

• Break glass, one sealed, hardware-MFA account, monitored, used only when SSO is down.

Network

The address plan is drawn before the first subnet exists. Ranges are carved non-overlapping across every account so they can peer later without renumbering, and the spokes attach to a central hub that owns transit, egress, and inspection. See Network Topology for the topology patterns the hub implements.

• Plan the space, non-overlapping CIDR ranges allocated per account up front.

• Hub and spoke, a transit gateway, shared VPC, or hub VNet the workload accounts attach to.

• Central egress, outbound traffic crosses one inspected, logged point.

• Private reach, private endpoints to provider services so traffic skips the public internet.

Logging

Every account ships its record of itself to the log archive account, where the operator (or the operator’s adversary) cannot quietly rewrite history. The trail is org-wide so a newly vended account is covered the moment it exists.

• Org-wide trail, every control-plane API call captured org-wide.

• Write once, object-lock or immutability on the archive bucket.

• Centralize the rest, flow logs, access logs, and config snapshots land in the same account.

• Alert on the trail itself, a disabled or deleted trail is a high-signal event.

Provisioning

The landing zone is itself code. The baseline lives in a Git repository, a pipeline applies it, and new accounts are vended from a factory that wires in the identity, network, logging, and guardrail defaults before anyone logs in. Click-ops account creation is the thing the factory exists to kill, because a hand-built account is one that drifted from the baseline on day zero. See Infrastructure as Code for the tooling that applies it.

Providers

The pattern is identical across providers; only the nouns change. The operator who learns the structure once carries it onto any infrastructure.

Concept	AWS	GCP	Azure
Top of hierarchy	Organization	Organization	Tenant root group
Grouping node	Organizational unit	Folder	Management group
Isolation boundary	Account	Project	Subscription
Preventive guardrail	Service control policy	Organization policy	Azure policy
Baseline framework	Control Tower	Cloud Foundation Toolkit	Azure Landing Zones
Central audit log	CloudTrail	Cloud Audit Logs	Activity Logs

Pitfalls

• Workloads in the management account, its blast radius is the whole organization.

• Detect-only guardrails, controls that report a violation but never stop it.

• No break-glass path, an SSO outage locks every operator out at once.

• Overlapping CIDR ranges, addresses chosen per account block later peering.

• Account sprawl, new accounts vended without a factory drift from the baseline.

• One account for every environment, prod and sandbox sharing a single trust boundary.

References

• Network Topology for the network hub the landing zone stands up.

• Tenancy for the isolation model the account boundaries enforce.

• Security for the control layers each account inherits.

• Infrastructure as Code for the code that provisions the zone.

• Clouds for the provider-specific primitives.

• AWS Control Tower

• AWS Organizations

• Google Cloud landing zones

• Azure landing zones