Azure Landing Zones Governance

Brewing the Latest Azure Landing Zone – The Anatomy of an ALZ

Breaking down the building blocks — from management groups to platform resources.

Designing an Azure Landing Zone (ALZ) can feel like crafting the perfect flat white — you need the right blend of structure and flexibility, delivered consistently every time. Miss the proportions and you’ll either over‑govern or under‑secure your environment.

With Microsoft’s latest ALZ guidance evolving through the Cloud Adoption Framework (CAF), understanding what makes up an ALZ — and how these pieces interlock — is key to setting up a platform that scales cleanly across workloads and teams.

In this post, we’ll unpack the anatomy of an ALZ from the ground up: management groups, baseline services, connectivity, logging, and what parts are open for customisation versus “hands‑off” prescriptive control.

What is an Azure Landing Zone?

An Azure Landing Zone (ALZ) is a collection of Azure resources, policies, and configurations that establish a secure and governed foundation for deploying workloads. It’s essentially the “control plane” for the rest of your cloud estate — defining how resources are structured, secured, and connected.

Microsoft’s Cloud Adoption Framework (CAF) describes ALZs as reference implementations that help organisations balance enterprise guardrails with developer agility. They span critical design areas such as:

  • Identity and access management
  • Network topology and connectivity
  • Security and compliance baseline
  • Resource organisation and policy
  • Monitoring and management

The current ALZ architecture (v3 and beyond) continues to evolve toward modularity and automation, allowing partial or full deployment through templates, pipelines, or tools like Azure Developer CLI (azd).

How It Works

Every ALZ is built around a management group hierarchy, baseline policies, governance services, and shared platform resources. Think of it as the skeleton of your Azure estate.

1. Management Group Hierarchy

At the top sits the Tenant Root Group, followed by a recommended structure like this:

1
2
3
4
5
6
7
8
9

Tenant Root
 ├── Platform
 │   ├── Identity
 │   ├── Management
 │   ├── Connectivity
 │   └── Shared Services
 └── Workloads
     ├── Corp
     └── Online

Each branch enforces scope‑specific policy assignments and role inheritances.

For example:

  • Platform → central services like Firewall, DNS, and Hub networks
  • Corp → internal workloads following restricted egress/internet controls
  • Online → internet‑facing or public workloads with isolated routing

A simplified Mermaid diagram helps illustrate this structure.

graph TD A[Tenant Root Group] A --> B[Platform] A --> C[Workloads] B --> D[Identity] B --> E[Management] B --> F[Connectivity] C --> G[Corp] C --> H[Online]

2. Baseline Services

Under the Platform branch, Azure policy, Defender for Cloud, logging, and network topologies take shape:

  • Azure Policy and Initiative Assignments: Enforce naming, tagging, resource restrictions, security mandates, and region constraints.
  • Defender for Cloud (DfC): Enables Cloud Security Posture Management (CSPM) and threat protection across subscriptions.
  • Networking: Hub‑and‑spoke is still the go‑to, though the Virtual WAN model is gaining traction for global routing needs.
  • Monitoring: Azure Monitor, Log Analytics, and Activity Logs are centralised in a management subscription for visibility and response.

3. Connectivity and Hub-and-Spoke Evolution

The “Connectivity” management group or subscription houses baseline resources such as:

  • Virtual Network (Hub)
  • Network Security Groups (NSGs) and Azure Firewall
  • Private DNS zones
  • VPN/ExpressRoute Gateways

Many teams now use Virtual WAN hubs for unified global routing and security, combining multiple regions or geographies into a standardised topology.

4. Control Plane vs. Workload Plane

An ALZ effectively splits your estate into two operating domains:

  • Control Plane: The policies, RBAC assignments, and platform resources managed typically by a central platform team.
  • Workload Plane: Application subscriptions that inherit governance and integrate using shared services.

This separation enables autonomy without loss of oversight — the hallmark of a mature Azure platform.

Real‑World Impact

A well‑structured ALZ provides three tangible benefits to real‑world operations:

  1. Faster workload onboarding — Teams can deploy workloads without re‑creating identity, networking, or monitoring from scratch.
  2. Consistent compliance — Built‑in policies ensure resources automatically align with regulatory or security requirements.
  3. Scalable governance — As new workloads or business units appear, they slot neatly into the existing hierarchy with inherited guardrails.

Example: A financial services customer adopted the latest ALZ baseline and halved provisioning time for new environments, while achieving automatic DfC coverage across all subscriptions.

Implementation Examples

Using the Azure Portal

  1. Navigate to Azure Landing Zone Accelerator in the Azure Portal.
  2. Select Deploy to Azure using the CAF‑aligned Bicep templates.
  3. Choose your management group root and desired topology (Hub & Spoke or VWAN).
  4. Review policy and role assignments, then deploy baseline resources.

Bicep Example

A shortened snippet defining part of the management group hierarchy and a policy assignment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

targetScope = 'tenant'

resource platformMgmtGroup 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-platform'
  displayName: 'Platform'
  parent: {
    id: tenantResourceId('Microsoft.Management/managementGroups', 'tenant-root')
  }
}

resource workloadsMgmtGroup 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-workloads'
  displayName: 'Workloads'
  parent: {
    id: tenantResourceId('Microsoft.Management/managementGroups', 'tenant-root')
  }
}

resource policyAssign 'Microsoft.Authorization/policyAssignments@2021-06-01' = {
  name: 'audit-tagging'
  properties: {
    displayName: 'Audit required tags'
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/audit-tags'
    scope: platformMgmtGroup.id
  }
}

This modular design means the same hierarchy can be reused or modified via pipelines or automation frameworks.

Gotchas & Edge Cases

  • Policy Overlaps: Avoid redundant policy assignments between management groups; precedence can override higher‑level settings unexpectedly.
  • Hub Peering Limits: Virtual network peers across regions can hit subscription or region limits; plan capacity early.
  • Role Assignment Delays: Tenant‑level role changes can take minutes to propagate, complicating automated deployments.
  • Cross‑Tenant Scenarios: ALZ assumes single‑tenant governance; cross‑tenant or B2B integration often needs manual override policies.

Best Practices

  • Start with the CAF Baseline and customise incrementally—don’t boil the ocean on day one.
  • Separate Platform and Workload subscriptions to maintain isolation.
  • Enable Defender for Cloud early for unified posture management.
  • Centralise monitoring and logs using Azure Monitor and Sentinel.
  • Template everything — deploy ALZ Scaffolding with Bicep or Terraform to stay consistent across environments.
  • Use feature flags or config maps to control rollout of new policies safely.

Brewed Insights

Your ALZ is only as strong as its hierarchy. Treat it like the espresso shot in your morning brew — get the foundation right, and everything built on top flows smoother. Naming “Workloads” instead of “Landing Zones” keeps the hierarchy intuitive and clear for stakeholders managing real application estates.

Learn More