Landing Zones and Account Structure

A landing zone is the pre-baked, opinionated, multi-account (or multi-project / multi-subscription) foundation you build before the first real workload lands — an environment where new accounts arrive already wired with identity, network segmentation, centralized logging, and policy guardrails, rather than being configured by hand one at a time. AWS defines it as “a well-architected, multi-account environment that’s based on security and compliance best practices … the enterprise-wide container that holds all of your organizational units (OUs), accounts, users, and other resources” (AWS Control Tower docs). Google frames it as “a cloud foundation” and a “modular and scalable configuration that enables organizations to adopt Google Cloud” — explicitly “not a zone or zonal resources” despite the name (Google Cloud landing zones). Microsoft calls it “the standardized and recommended approach for all organizations utilizing Azure … a consistent way to set up and manage your Azure environment at scale” (Azure CAF). The single most important idea: a landing zone makes governance the default state of a new account instead of a checklist someone hopefully remembers to run.

The concept lives in §8 (Governance) of the Cloud Architecture MOC. This note teaches the primitive — the governed multi-account baseline — and names the three vendors’ implementations inline. The preventive/detective controls that ride on top of a landing zone are their own concept; see the sibling Guardrails and Service Control Policies. How you provision the landing zone as code (Terraform, CloudFormation, Bicep) belongs to the Infrastructure as Code MOC; how you operate the running estate belongs to Site Reliability Engineering MOC. This note owns what a landing zone is and why a governed baseline beats per-account manual setup.

Why a Governed Baseline Beats Manual Setup

The naive way to run a company on the cloud is one account (or project, or subscription) that everything shares. That collapses under three pressures almost immediately. Blast radius: a compromised credential or a runaway Terraform apply in a shared account can touch production, billing, and the audit logs all at once — there is no wall. Attribution: when finance, dev, and the data team all bill to one account, the invoice is an undifferentiated lump and no team owns its own spend (the problem Resource Tagging and Cost Allocation exists to solve, but tags cannot rebuild an account boundary that was never there). Consistency drift: every account set up by hand ends up subtly different — one has flow logs, one does not; one enforced encryption, one forgot — and this divergence-from-intent is exactly what AWS names drift (Control Tower docs).

The multi-account answer is to make the account (project/subscription) the fundamental unit of isolation — for security blast radius, for billing, and for quota/service limits — and then to solve the resulting problem: if every workload gets its own account, you now have dozens or hundreds of them, and configuring each one by hand is both slow and unreliable. A landing zone resolves that tension by making account creation a governed, automated act: the account is vended from a template that has the baseline already stamped in. AWS puts the value plainly — “if you are hosting more than a handful of accounts, it’s beneficial to have an orchestration layer that facilitates account deployment and account governance” (Control Tower docs).

flowchart TB
    subgraph MANUAL["Per-account manual setup — does not scale"]
        M1["New account requested"] --> M2["Human runs a checklist<br/>(IAM, VPC, logging, policies)"]
        M2 --> M3["Some steps skipped<br/>or done differently"]
        M3 --> M4["DRIFT: every account<br/>subtly inconsistent"]
    end
    subgraph GOVERNED["Landing zone — governance is the default"]
        G1["New account requested"] --> G2["Account Factory /<br/>Subscription vending<br/>stamps the baseline"]
        G2 --> G3["Baseline already present:<br/>identity · network · logging · guardrails"]
        G3 --> G4["Consistent, compliant<br/>by construction"]
    end

What it shows and the insight: the two paths start identically — someone needs a new account — but diverge at step 2. Manual setup depends on a human executing a checklist perfectly every time and produces drift; the landing zone replaces the human with a vending mechanism (AWS Account Factory, Azure subscription vending, GCP project factory) so the baseline is present by construction. The insight: a landing zone does not make governance possible — it makes non-governance the harder path.

The Anatomy: Four Baked-In Layers

Across all three clouds a landing zone bakes the same four capabilities into every account it produces. (1) A resource hierarchy — the tree of grouping nodes that policies attach to and inherit down. (2) Identity — centralized single sign-on and short-lived credentials so humans never carry long-lived keys per account. (3) Networking — a pre-designed topology (typically hub-and-spoke) with segmentation and connectivity already laid out. (4) Logging and guardrails — a dedicated, tamper-resistant place where audit logs land, plus the preventive and detective controls that enforce non-negotiables. Google names the mandatory design decisions as exactly “identity provisioning, resource hierarchy, network design, [and] security controls” (Google Cloud landing zones); Azure’s eight design areas cover the same ground plus management and platform automation (Azure CAF).

The Resource Hierarchy — Where Policy Attaches

The hierarchy is the spine, because it is where policy inheritance happens. All three vendors provide a tree of grouping nodes above the individual account:

Concept	AWS	Google Cloud	Azure
Root of the tree	Organization (management account)	Organization node	Root management group (tenant)
Grouping node	Organizational Unit (OU)	Folder (nestable)	Management Group (nestable)
Isolation / billing unit	Account	Project	Subscription
Leaf resource	Resource (e.g. S3 bucket)	Resource (e.g. GCS bucket)	Resource (e.g. Blob container)
Policy that inherits down	Service Control Policy (SCP)	Organization Policy constraint	Azure Policy

The key mechanical property is downward inheritance: a policy set on a grouping node applies to everything beneath it. Google states it directly — the hierarchy “provides attachment points for access control and organization policies, which flow down the hierarchy,” and “descendants of the resource to which the organization policy is attached inherit the organization policy” (GCP hierarchy, GCP Org Policy). AWS says a Control Tower control “applies to an entire organizational unit (OU), and every AWS account within the OU is affected” (Control Tower controls). Azure application landing zones are “nested under appropriate management groups … to inherit Azure Policy definitions from the parent management group(s)” (Azure CAF). This is why the hierarchy design is the governance design: where you place an account in the tree determines which guardrails it inherits.

flowchart TD
    ORG["Organization / Root MG<br/>(management or platform account)"]
    ORG --> SEC["Security OU / Folder<br/>log-archive + audit accounts"]
    ORG --> INFRA["Infrastructure OU<br/>shared networking, tooling"]
    ORG --> WL["Workloads OU / 'Landing zones' MG"]
    WL --> PROD["Production OU<br/>strict guardrails inherited"]
    WL --> NONPROD["Non-Prod OU<br/>looser guardrails"]
    ORG --> SANDBOX["Sandbox OU<br/>experimentation, capped"]
    PROD --> A1["prod-payments acct"]
    PROD --> A2["prod-web acct"]
    NONPROD --> A3["dev-web acct"]

    style SEC fill:#f9d5d5
    style PROD fill:#d5e8f9

What it shows and the insight: a representative account tree. Grouping nodes (OUs / folders / management groups) carry the policies; leaf accounts inherit them. A policy that says “no public storage buckets” placed on the Production OU automatically binds prod-payments and prod-web without either account opting in. The Security OU holds the dedicated log-archive and audit accounts that even administrators of other accounts cannot tamper with. The insight: you govern groups, not individual accounts — the tree is the lever.

AWS: Control Tower, Organizations, and Account Factory

AWS’s landing-zone product is AWS Control Tower, which “orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour” (Control Tower docs). The layering matters: AWS Organizations is the underlying primitive that provides the account tree, consolidated billing, and the ability to attach Service Control Policies and Resource Control Policies; Control Tower is the opinionated orchestration on top that sets up a best-practice landing zone and keeps it from drifting. You can run Organizations without Control Tower (rolling your own landing zone), but Control Tower gives you the prescriptive version out of the box.

The mechanism that makes account creation cheap is Account Factory — “a configurable account template that helps to standardize the provisioning of new accounts with pre-approved account configurations,” built “as an abstraction on top of provisioned products in AWS Service Catalog” and often nicknamed the “vending machine” (Control Tower docs). When a team requests an account through Account Factory, the workflow creates the AWS account, places it in the right OU, and “automates the process of applying controls and policies to those accounts” — the four baked-in layers, applied automatically.

sequenceDiagram
    participant Dev as Application team
    participant AF as Account Factory<br/>(Service Catalog)
    participant Org as AWS Organizations
    participant IdC as IAM Identity Center
    participant Log as Log Archive account
    Dev->>AF: Request new account (name, OU, config)
    AF->>Org: Create account, place in target OU
    Org-->>AF: Account inherits OU's SCPs (guardrails)
    AF->>IdC: Wire SSO / permission sets
    AF->>Log: Route CloudTrail + Config to central log archive
    AF-->>Dev: Governed account, ready to use
    Note over Org,Log: Baseline present by construction —<br/>no manual checklist

What it shows and the insight: the Account Factory vending flow. The developer’s single request fans out into placement (inheriting OU guardrails), identity wiring, and centralized logging — the account is compliant the instant it exists. The insight: the value is not any one step but that all of them happen atomically and identically every time.

Control Tower also actively watches for drift — divergence from the landing-zone’s intended configuration — and surfaces it on a dashboard so administrators can see, for example, an SCP that was manually detached or a guardrail that was disabled (Control Tower docs). A crucial design detail: the management account is exempt from Control Tower controls, intentionally, because “it prevents the management account from entering into an unusable state” — the same reason SCPs do not apply to the management account (Control Tower controls). This is why best practice is to keep the management account nearly empty and run no workloads in it.

Google Cloud: Resource Hierarchy, Organization Policy, and Blueprints

Google’s landing zone is assembled from the resource hierarchy (organization → folders → projects → resources), the Organization Policy Service for configuration guardrails, and IAM for access — deployed via published landing-zone blueprints and the Cloud Foundation Toolkit / Fabric FAST framework. Google’s own definition centers on the four mandatory design decisions (identity, hierarchy, network, security) and stresses that “a landing zone is dynamic and grows as your enterprise adopts more cloud-based workloads over time” (Google Cloud landing zones).

The GCP analog of an OU is the folder, which “provides isolation boundaries and enables delegation” and can model departments or legal entities, nesting arbitrarily (GCP hierarchy). Guardrails come from Organization Policy constraints — a topic for the sibling note, but in short: constraints restrict how resources can be configured (e.g. constraints/gcp.resourceLocations to pin data residency), inherited down the hierarchy exactly as SCPs are. A distinctive GCP construct baked into serious landing zones is VPC Service Controls, which “isolate service and resources” to mitigate data-exfiltration risk — a service perimeter that has no exact one-to-one AWS/Azure equivalent (Google Cloud landing zones).

Azure: Cloud Adoption Framework Landing Zones and Management Groups

Azure’s landing zone is defined by the Cloud Adoption Framework (CAF) and split into a platform landing zone and one or more application landing zones. The platform landing zone “provides shared services (identity, connectivity, management) to applications,” typically realized as dedicated Identity, Management, and Connectivity subscriptions run by central teams; an application landing zone “contains the resources for hosting a single workload/application,” one per environment (dev/test/prod) (Azure CAF). This platform-vs-application split is Azure’s cleanest articulation of an idea implicit in all three clouds: a foundational tier of shared plumbing, and a workload tier that consumes it.

The Azure hierarchy node is the management group, which nests and carries Azure Policy; subscriptions sit beneath management groups and are the isolation/billing unit. New application subscriptions are created through subscription vending — Azure’s Account-Factory equivalent — “pre-provision[ing] application landing zone subscriptions through code” (Azure CAF). Microsoft explicitly recommends deploying and managing the whole thing as Infrastructure as Code via the ALZ Accelerator (Bicep or Terraform via Azure Verified Modules), calling IaC “the recommended approach” over the portal accelerator (Azure CAF) — the seam where this concept hands off to the Infrastructure as Code MOC.

flowchart LR
    subgraph AWS
        A1["Organization"] --> A2["OUs"] --> A3["Accounts"]
        A4["Control Tower<br/>+ Account Factory"]
    end
    subgraph GCP
        G1["Organization"] --> G2["Folders"] --> G3["Projects"]
        G4["Landing-zone blueprints<br/>+ Cloud Foundation Toolkit"]
    end
    subgraph Azure
        Z1["Root MG"] --> Z2["Management Groups"] --> Z3["Subscriptions"]
        Z4["CAF ALZ Accelerator<br/>+ subscription vending"]
    end

What it shows and the insight: the same three-tier pattern — root → grouping node → isolation unit — realized under three vendors’ names, each with its own vending/blueprint tooling. The insight: “landing zone” is one portable idea; only the nouns change. Learn the pattern once and the vendor mapping is mechanical.

Failure Modes and Common Misunderstandings

Treating the management/root account as a normal account. Because Control Tower controls and SCPs deliberately do not constrain the AWS management account (Control Tower controls), running workloads there creates an ungoverned hole in an otherwise governed estate. Keep it empty; the same discipline applies to the Azure root management group and the GCP organization node.

Retrofitting a landing zone after sprawl. The whole point is to govern from day one. Once hundreds of accounts exist with ad-hoc configuration, importing them into a landing zone means resolving drift account by account. AWS’s own guidance to “create an OU that you can move your accounts into one at a time” when applying restrictive policies (SCP docs) is a symptom of how painful late governance is.

Confusing the hierarchy with a folder-for-organization. OUs/folders/management groups are policy attachment points, not cosmetic folders. Organizing them by environment and trust level (prod vs sandbox) is what makes inheritance useful; organizing them by team-name-of-the-month makes the tree churn every reorg.

Assuming the landing zone is one-and-done. Google is explicit that it “grows over time” (Google Cloud landing zones); Azure ships modules precisely so components can evolve. A landing zone is a living configuration under version control, not a one-time setup.

Uncertain

Verify: the claim that AWS Control Tower “build[s] a landing zone in less than an hour.” Reason: this is a vendor performance claim from the AWS docs that may vary with organization size and enabled options, and is marketing-adjacent. To resolve: treat as approximate; the architectural facts (Account Factory, drift detection, management-account exemption) are the load-bearing claims and are independently documented. #uncertain

Alternatives and When to Choose Them

The alternative to a vendored landing zone is rolling your own with the underlying primitives — AWS Organizations + custom Terraform, GCP resource hierarchy + Fabric FAST, Azure management groups + Bicep — without the opinionated orchestration product. Teams do this when the prescriptive product’s opinions clash with an existing structure, when they need multi-cloud consistency a single vendor’s product cannot give, or when a mature platform team already has the automation. The trade-off: you own the drift detection, the account-vending workflow, and the upgrade path that Control Tower / CAF Accelerator would otherwise maintain. For most organizations below a very large platform-engineering headcount, the vendored landing zone is the better default — it encodes best practices you would otherwise have to discover the hard way.

At the opposite extreme, a single-account/single-project setup is genuinely fine for a solo developer, a throwaway prototype, or a tiny startup — the multi-account tax is not worth paying before there is anything to isolate. The landing zone earns its keep the moment there are multiple teams, a production/non-production split, or a compliance requirement. This is the same single-vs-multi judgment that recurs at the strategic layer in Multi-Cloud versus Single-Cloud versus Hybrid.

Production Notes

In practice the log-archive account is the crown jewel: centralizing CloudTrail / Cloud Audit Logs / Azure Activity Logs into a dedicated account that no other account’s admins can write to is what makes an audit trail trustworthy after a breach — an attacker who compromises prod-web still cannot erase the evidence. Real landing zones also lean heavily on least-privilege plus federation: humans authenticate through IAM Identity Center / Entra ID / Cloud Identity and assume short-lived roles per account, so there are no long-lived access keys scattered across accounts (the identity discipline detailed in IAM Policy Evaluation Logic and the Cloud Architecture MOC §5). Finally, the account boundary is the cleanest cost-attribution boundary that exists — even before tags — because each account produces its own line on the consolidated bill, which is why Resource Tagging and Cost Allocation and landing zones are complementary rather than alternative answers to “who spent this money.”

See Also

• Guardrails and Service Control Policies — the preventive/detective controls that ride on top of the landing-zone hierarchy (sibling)
• Organization and Account Hierarchy — accounts/projects/subscriptions as isolation and billing units; the multi-account rationale
• Resource Tagging and Cost Allocation — the complementary, finer-grained cost-attribution layer inside accounts
• IAM Policy Evaluation Logic — how SCPs and identity policies combine in the permission decision
• Multi-Cloud versus Single-Cloud versus Hybrid — the strategic single-vs-multi judgment that this account-level judgment echoes
• Cloud Architecture MOC — §8 Governance, parent map
• Infrastructure as Code MOC — how you provision and version the landing zone (Terraform / Bicep / CloudFormation)
• Site Reliability Engineering MOC — how you operate the running estate