What a landing zone is

An Azure landing zone is the standard way Microsoft recommends for building an Azure environment and keeping it in operation. It is not a single resource and not a product, but a repeatable structure: a hierarchy of management groups, subscriptions inside it with a clear purpose, and above them policies that automatically apply to every new subscription.

Repeatability is the point. Once the structure stands, the fiftieth subscription gets the same guardrails as the first, without anyone having to remember them. That is exactly what separates a landing zone from a collection of grown subscriptions.

Microsoft organises the design into eight areas: Azure billing and Microsoft Entra tenant, identity and access management, management group and subscription organisation, network topology and connectivity, security, management, governance, and platform automation and DevOps. These eight areas are the agenda for the design workshop.

Platform landing zone and application landing zone

The most important distinction comes at the start and is often skipped.

The platform landing zone provides shared capabilities for identity, connectivity, management and security monitoring. Which services are centralised and how they are divided into subscriptions depend on the organisation’s requirements.

An application landing zone contains a workload’s resources and environments, such as development, test and production. Each environment can use one or more subscriptions according to its requirements. These sit under suitable management groups such as Corp, Online or Local and inherit their assigned Azure Policies.

For most organisations, Microsoft recommends one platform landing zone per Entra tenant and multiple application landing zones. This separates responsibility for shared services and workloads; network and access isolation still need an explicit design.

Subscription vending: the subscription as a product

New subscriptions should follow a consistent standard. Subscription vending automates this process: a team requests a subscription, and the workflow applies the management group, role assignments, network connection, cost centre and naming scheme.

Manual provisioning can initially be controlled and traceable. As demand grows, automation reduces coordination work and the risk of overlooking requirements.

For managing application landing zones there are three models: central management by an IT team, full handover to the application team while the management group's policies keep applying, and shared management for technology platforms such as AKS, where a central team operates the foundation and the application teams operate what runs on top. That decision belongs at the start, not in month nine.

Networking: hub-and-spoke or Virtual WAN

The reference architecture knows two network topologies. Hub-and-spoke is the classic variant with a central hub VNet for shared services such as firewall, VPN gateway and DNS, to which the spokes are connected. Virtual WAN moves the meshing into a service managed by Microsoft.

Hub-and-spoke offers flexibility in designing your own network. Virtual WAN can simplify connecting many sites and regions; it also supports custom firewall rules. Routing requirements, supported network features, cost and operational ownership together determine the appropriate topology.

What has to be decided early in both cases is DNS. A central DNS setup integrated across subscriptions is painful to retrofit once productive workloads are already resolving names.

Policies instead of rework

Azure Policy can assess or enforce technical requirements at management groups and other scopes, including allowed regions, encryption, public access and tags. The design must establish which policies are appropriate for the resource types in use.

A deny policy can prevent non-compliant changes. Assignments, exemptions and evaluation results help demonstrate whether the requirement is effective within its intended scope. Documented operating procedures remain necessary for organisational measures.

For assessments against CIS benchmarks or BSI Grundschutz, suitable technical requirements can be grouped into policy initiatives. These supply part of the evidence; they do not replace responsibilities, processes or other audit evidence.

Build and evolve through code

Microsoft recommends infrastructure as code with Bicep or Terraform for deploying and maintaining the platform landing zone, supported by an accelerator and Azure Verified Modules. A portal accelerator remains available, for example for organisations without IaC experience.

IaC makes versioning, reviews and repeatable deployment easier. A landing zone built through the portal remains a landing zone, but requires more effort to track changes consistently. Even with IaC, reversing a change requires an assessment of its effects. The team workflow is covered in Terraform for teams.

Where AWS looks different

The idea carries over, the terms do not. AWS describes the same problem as a multi-account strategy: the AWS account is the isolation boundary for identity and access, and between accounts no access is allowed by default. Accounts are grouped into organizational units, guardrails come through service control policies.

AWS explicitly recommends using multiple accounts from the start instead of a single one, and keeping the security OU clean, meaning only the accounts provided for by AWS Control Tower go there and further security-related accounts go into their own OU.

Whoever operates both clouds should deliberately lay the terms side by side: a management group corresponds roughly to an organizational unit, Azure Policy roughly to a service control policy, the subscription roughly to the account. Roughly, not exactly.

Five mistakes that get expensive

  1. Skipping the separation of platform and application landing zone. That takes its revenge with the first application team that needs its own network rules.
  2. Creating subscriptions without a standard. Without a repeatable process, ownership and requirements can drift apart.
  3. Sorting out DNS later. Retrofitting central DNS across subscriptions while productive systems are running is a project of its own.
  4. Leaving policy findings without follow-up. Audit mode helps during introduction. Findings then need owners and a decision on which policies to enforce.
  5. Failing to track changes. Without versioned requirements and regular reviews, evolving the landing zone becomes harder.
Key takeaway

A landing zone connects shared platform services, separate workload environments and verifiable guardrails. A standard provisioning process keeps new subscriptions consistent. IaC makes changes and repeatability easier; clear ownership and ongoing checks remain part of operations.

What you can decide afterwards

  • Whether your network is built as hub-and-spoke or over Virtual WAN, and who maintains the central firewall rules.
  • Which of the three management models for application landing zones fits your teams: central, handed over or shared.
  • Whether your existing environment is a landing zone or a collection of subscriptions that just grew, and where the rebuild starts.

Frequently asked questions

Do we need a landing zone even for a single application?

Not every environment needs the full reference architecture. Even one application needs an appropriate identity, network, security and operations baseline. Protection requirements, availability targets and planned growth determine its scope.

We already run subscriptions. Is it too late for a landing zone?

No. Depending on the starting point, the existing structure can be adapted incrementally or a new environment built for planned migrations. Assess the effects on permissions, policies, networking and DNS before making changes.

Bicep or Terraform?

Both hold up; Microsoft provides accelerators and Azure Verified Modules for each. Whoever runs Azure only does well with Bicep; whoever has several clouds or existing Terraform experience stays with Terraform. More important than the tool is that the environment is created as code.

Sources

Read on
Cloud & Platform What is a Landing Zone? Cloud & Platform Internal Developer Platform: when it pays off API Operations Tyk, Kong or Azure API Management Service Cloud Engineering Service Platform Engineering