Landing Zones
A landing zone is a pre-provisioned, governed Azure environment that workloads deploy into — the management-group hierarchy, identity, networking, policy, and monitoring already in place, so each team is not rebuilding the foundation. It is the difference between an organized estate and a sprawl of subscriptions configured ad hoc by whoever created them.
The idea is to separate the platform from the applications. A small platform team builds and governs the landing zone once; application teams get subscriptions that already inherit the guardrails. Skipping this and letting teams self-provision subscriptions with no shared foundation is how cloud estates become ungovernable — the problem landing zones exist to prevent.
What a Landing Zone Is
A landing zone bundles the cross-cutting concerns every workload needs — identity and access, network topology, policy guardrails, logging and monitoring, and a security baseline — into a repeatable environment. Microsoft's Cloud Adoption Framework provides reference architectures and accelerators so an organization does not design it from a blank page.
Management Group Hierarchy
Management groups sit above subscriptions and let policy and access apply to many subscriptions at once. A typical hierarchy separates platform subscriptions (identity, management, connectivity) from landing-zone subscriptions for workloads, with policy assigned at the right level so guardrails inherit down. The hierarchy is the skeleton governance hangs on.
Platform vs Application Landing Zones
Platform landing zones host shared services — connectivity (the hub network), identity, and management — run by the platform team. Application landing zones are the governed subscriptions where workloads live, pre-wired to the platform. The split keeps shared infrastructure stable and centrally owned while application teams move fast within their guardrails.
Subscription Vending
Subscription vending is the automated process of issuing new application landing zones on demand — a team requests one, and automation provisions a subscription already peered to the network, assigned the right policies, and wired to logging. It scales the landing-zone model: governance is applied at creation, not bolted on later when it is painful.
- Letting teams self-provision subscriptions with no shared foundation, producing an ungovernable sprawl that is expensive to retrofit.
- Designing a landing zone from scratch instead of starting from the Cloud Adoption Framework accelerators.
- Assigning policy at the subscription level repeatedly instead of at management groups, so governance is inconsistent and hard to maintain.
- Mixing platform shared services into application subscriptions, coupling team workloads to central infrastructure.
- Provisioning landing zones by hand, so governance is applied inconsistently and slowly instead of through vending.
- Treating the landing zone as done at launch and never evolving it as requirements change.
- Separate the platform from applications — a small team owns the landing zone; app teams inherit its guardrails.
- Start from the Cloud Adoption Framework reference architectures and accelerators.
- Apply policy and access at the management-group level so guardrails inherit down to subscriptions.
- Keep platform shared services (connectivity, identity, management) in their own subscriptions.
- Automate subscription vending so governance is applied at creation, not retrofitted.
- Evolve the landing zone as the estate's requirements change.
Knowledge Check
What problem do landing zones solve?
- Ad-hoc, ungovernable subscription sprawl — they give workloads a pre-governed foundation to deploy into
- Slow application code, by tuning and optimizing the language runtime and the JIT compiler at deploy time
- The need for a central container registry to store and version images
- High inference latency when serving large AI models in production
Why apply policy at the management-group level in a landing zone?
- So guardrails apply to many subscriptions at once and inherit down consistently
- Because individual subscriptions cannot carry their own Azure Policy assignments at all
- To reduce the per-policy cost Azure charges for each assignment
- Management groups are the only scope where RBAC role assignments work
What is subscription vending?
- Automated, on-demand issuing of governed application landing zones already wired to the platform
- Selling unused subscription capacity back to Azure for a partial credit applied to the next bill
- A billing model for committing to reserved instances up front
- A way to merge several existing subscriptions into a single one
You got correct