Landing Zone Design

A landing zone is the pre-provisioned, guard-railed environment — account/subscription structure, policies, and baseline configuration — that a workload is deployed into before any resources are created.

At a glance

• What it is: a management group/subscription hierarchy, naming conventions, policies (allowed regions, required tags, budget alerts), and baseline security controls, set up once and inherited by every workload deployed into it.
• Why it matters: it prevents every team from inventing its own conventions and discovering security or cost problems only after deployment.
• For developers: if you’re requesting a new subscription or resource group for a project, check what landing zone policies you inherit before assuming you have full freedom over region, SKU, or network configuration.
• When to use it: before onboarding any new team or workload to the cloud platform.
• When not to use it: it always applies at some level — even a single small workload benefits from a minimal landing zone (budget alerts, tagging).
• Prerequisites: Cloud Service & Deployment Models.

Mental model

graph TD
    Tenant["Tenant / root management group"] --> Platform["Platform management group: shared services"]
    Tenant --> Landing["Landing zone management groups"]
    Landing --> Prod["Production subscription"]
    Landing --> NonProd["Non-production subscription"]
    Platform --> Policies["Policies: allowed regions, tags, budgets"]
    Policies -.applies to.-> Prod
    Policies -.applies to.-> NonProd

Step-by-step walkthrough

1. Define the management group hierarchy, separating platform (shared services) from workload landing zones.
2. Decide subscription boundaries (e.g., per environment, per business unit) based on billing, blast radius, and access needs.
3. Define and apply baseline policies: allowed regions, required tags, budget alerts, mandatory diagnostic settings.
4. Automate landing zone provisioning so it’s repeatable for the next team, not a one-off manual setup.
5. Onboard the first workload and validate the guardrails actually block or detect violations before wider rollout.

Worked example

Northwind’s new “Solaris Retail” cloud program is about to onboard its first three teams — checkout, logistics, and payments — but no cloud environment exists yet.

• Input: three teams about to deploy independently with no shared conventions.
• Process: platform engineering creates a management group hierarchy with one subscription per environment (dev/test/prod) per team, and applies policies requiring specific allowed regions, mandatory resource tags (cost center, owner), and budget alerts — before any team gets deployment access.
• Output: all three teams deploy within the same guardrails from day one — consistent tagging enables cost allocation, and no team can accidentally deploy to an unapproved region.

Common use cases

Use case	When to use	Notes
Onboarding a new business unit to the cloud	Set up dedicated subscriptions under the landing zone hierarchy	Establishes blast radius and billing isolation from day one
Enforcing tagging for cost allocation	Apply a policy requiring cost-center tags on all resources	Prevents untraceable spend
Regulated workload isolation	Dedicated subscription/management group with stricter policies	Keeps compliance scope contained

Advanced details

• Landing zones are typically provisioned via Infrastructure as Code & Provisioning so the same guardrails apply consistently as new subscriptions are added.
• Policy enforcement modes matter: “audit” flags violations without blocking, “deny” blocks them outright — start with audit to gauge impact before flipping to deny.
• Subscription boundaries should map to how you want to bill and how much blast radius you’re willing to accept if one workload is compromised — not just organizational convenience.
• This pattern has a name: Microsoft’s Cloud Adoption Framework (CAF) defines “landing zone” as exactly this pre-provisioned, policy-guardrailed environment, with reference architectures for the management group hierarchy shown above; AWS’s equivalent is Landing Zone / Control Tower, and GCP’s is the Resource Manager hierarchy with Organization Policy. Adopting the cloud provider’s own landing zone reference architecture avoids re-deriving a weaker version of guidance that already exists.

Quick reference

Term	Meaning
Management group	Container for grouping subscriptions to apply policy/RBAC at scale
Subscription	Billing and access boundary within a cloud tenant
Policy	An enforced rule (region, tags, SKU, etc.) applied across a scope
Guardrail	A control that prevents or flags out-of-bounds configuration
Blast radius	The scope of impact if a resource or subscription is compromised

Troubleshooting

Symptom	Likely cause	Fix
Cost reports can’t be attributed to a team or project	No mandatory tagging policy enforced	Apply a required-tag policy at the management group level
A workload is accidentally deployed to the wrong region	No allowed-region policy	Add an allowed-locations policy at the landing zone scope
One team’s mistake affects another team’s resources	Shared subscription across unrelated workloads	Split into separate subscriptions per workload/environment

Check your understanding

• Why might “audit” mode be a safer first step than “deny” mode when rolling out a new policy?
• What’s the tradeoff between one subscription per team versus one subscription per environment per team?

Related pages

Part of Introduction to Cloud & Infrastructure Architecture. See also Cloud Service & Deployment Models, Infrastructure as Code & Provisioning, Network Architecture & Connectivity, and the Glossary.