Landing Zone

A landing zone is a cloud environment prepared for workloads, including accounts or subscriptions, identity, networking, policy guardrails, and shared services. Microsoft’s Azure guidance treats it as an architecture for governing, securing, and scaling a multi-subscription environment.

The word is worth being precise about because it is often used for a slide deck describing standards. A landing zone is deployed configuration: accounts, identity, network, and policy that already exist and that workloads can use.

The foundation, and the spaces built on it

Ownership is divided between two kinds of landing zone.

• Platform landing zone. The platform team owns the shared governance, security, and resource foundation. Microsoft generally recommends one per Entra tenant, rather than a separate foundation for each department.
• Application landing zones. Workload teams deploy and operate resources within platform guardrails. In the Azure guidance, each workload’s landing zone contains its environments, and an environment can use one or more subscriptions according to workload needs, ownership boundaries, and limits.

This separation lets each team make routine changes within its delegated scope. Changes to shared identity, routing, DNS, or other service contracts still require impact review and coordination; ownership does not remove the dependencies.

The management group hierarchy applies governance across subscriptions. Platform and workload resources can inherit common baseline controls while receiving additional policies appropriate to their roles. Separate scopes do not mean disjoint policy sets.

What it contains

Contents vary with the organization. As a baseline example, an organization that wants to hand a team an environment rather than a document typically needs each of the following, adjusted to its own identity, connectivity, and governance requirements.

• An account hierarchy with a place for a new workload to go.
• Identity — a defined identity model, commonly a central directory with federated access and roles assumed rather than credentials distributed.
• Network — allocated address space that does not overlap with the networks it must connect to, connectivity to shared services and, where the organization needs it, to on-premises networks, and a defined approach to private name resolution.
• Policy guardrails attached to the hierarchy, so a new environment inherits them rather than being configured correctly by hand.
• Baseline observability and security monitoring, switched on by default rather than requested.

Centralize capabilities when governance, operational, or economic benefits justify the shared dependency and maintenance. This can include delivery tooling or managed data services as well as identity and networking. Keep application decisions with the teams that understand them, and judge shared services by the work they remove and the waiting they introduce.

Vending supplies it repeatedly

A repeatable process handles requests, creation, and handover of application landing zones; Microsoft’s guidance calls it subscription vending, and the same idea is called account vending when the environments are accounts. It can begin manually; automation becomes more valuable as request volume grows. The provisioned environment must satisfy its baseline regardless of the fulfillment mechanism.

A deployed environment can govern the workloads already in it without such a process, but every new application landing zone then depends on ad hoc effort. The process is what turns a one-time foundation into a service teams can rely on. Where requests wait long or the route is unclear, teams may create their own accounts rather than wait, and the sprawl the landing zone was meant to prevent can follow, leaving a governance document that describes an environment few teams use.

An easy default can make a compliant environment simple to obtain. A golden path may allow alternative implementations, but required security and governance controls still apply, and exceptions need approval from the designated authority. Treating the foundation as a product with users and support commitments is platform engineering applied to infrastructure.

Do not wait until it is finished

Designing a complete policy catalog and network before testing them with a workload risks committing to assumptions that the first real deployment cannot satisfy. Early workload feedback helps reveal those gaps while the foundation can still be adjusted.

Start with the identity model, hierarchy, address plan, required guardrails, observability, and a way to provision environments. Extend them as workloads reveal new needs. Update shared policies with impact review; a foundation designed to evolve still needs controlled change.

Group environments by their policy requirements where that makes the hierarchy easier to manage. Those requirements and team structures can both change. Review inherited access and policy when moving accounts or subscriptions; changing a parent does not always require migrating resources.

How the hierarchy, guardrails, network topology, shared services, and cost allocation fit together is worked through in Before the First Workload.

References:

• Microsoft Learn, What is an Azure landing zone?
• Microsoft Learn, Azure management groups
• CNCF, Platforms White Paper