If your organisation’s Azure environment has ever started to resemble a messy workbench, with half‑finished projects, cables everywhere, and no one sure who owns what then you already understand why Azure Landing Zones (ALZ) exist.

The latest refresh of Microsoft’s Azure Landing Zone and Secure Landing Zone architecture is like upgrading from a faithful stovetop espresso to a precision‑calibrated machine: same goal, but vastly improved consistency, control, and flavour.

This post breaks down what’s new, how the reference design has evolved, and why it’s now easier than ever to create compliant, secure, and scalable environments from day one.

What is an Azure Landing Zone?

An Azure Landing Zone is Microsoft’s reference architecture and deployment pattern for building a secure, governed cloud foundation. It defines how to organise resources, apply policy, manage identity, and connect workloads. It’s the scaffolding every Azure environment should start from.

From Enterprise‑Scale to the Unified ALZ

Older architectures like Enterprise‑Scale Landing Zone and CAF foundations acted as blueprints for large enterprises. However, Microsoft has now folded those frameworks directly into the unified Azure Landing Zone guidance. The goal: a single, modular reference that fits startups through to global multi‑tenant enterprises.

So rather than a single monolith of templates, ALZ now offers a modular, design‑area‑driven approach where you choose which elements to adopt, iterate on them over time, and evolve the platform in step with cloud maturity.

The Eight Core Design Areas

The latest design defines eight interconnected areas, each representing a pillar of your landing zone foundation:

These areas combine to form an adaptable foundation governed by Landing Zone and Secure Landing Zone reference models.

How It Works

The Landing Zone design leverages Azure’s native control plane hierarchy The Entra ID tenant, management group, subscription, resource group, and resource — to distinguish governance from workload operations.

Below is a simplified view of the reference structure using updated terminology:

This structure enables tight control of policy inheritance and delegation, ensuring that corporate standards cascade from the top management groups but still allow agility within workload subscriptions.

What’s Changed in the Latest Reference Design

1. Secure Landing Zone (SLZ) Becomes First‑Class
   Security controls are no longer a bolt‑on. SLZ is now an integral model with pre‑mapped controls aligning directly to Zero Trust and Defender for Cloud benchmarks.

2. Eight‑Area Alignment
   The legacy “design principle” view is now formalised into these eight well‑defined areas, which together cover every subscription lifecycle from governance to DR.

3. Automation‑First Paradigm
   Microsoft’s emphasis has shifted: Landing Zones should be deployed and maintained via automation pipelines, not manual configurations. The supporting ALZ‑Bicep repository and modular template packages make this achievable.

4. Platform Resources Redefined
   The hierarchy now groups Identity, Connectivity, and Security under Platform Resources — clarifying ownership boundaries and improving access segregation.

5. Enhanced Resilience Focus
   ALZ now embeds BCDR as a design area, recommending Azure Backup, Site Recovery, and region pairing guidance as baseline expectations.

6. Retirement of Enterprise‑Scale Terminology
   The previous ESLZ guidance is now deprecated in favour of this unified pattern. The concepts remain, but the language and modularity are refined.

Real‑World Impact

☕ Customer 1 – Greenfield Azure: A Clean Start with Guardrails

A mid‑sized enterprise is preparing to migrate from its on‑prem environment — a single flat network with little role segmentation or billing separation — into Azure.
They’ve built a consistent naming convention locally but know it’s not directly cloud‑ready.

Their priorities:

• Segment environments into Prod, Dev, Test, and DMZ tiers.
• Maintain consistent security and policy enforcement without added complexity.
• Avoid unnecessary spend by keeping the network layout simple.
• Centralise connectivity through a hub‑and‑spoke or Virtual WAN topology.

Using the Azure Landing Zone design areas, the roadmap looked like this:

• Resource Organisation & Governance:
  Adopted the standard management group hierarchy (Platform, Workloads, Management), applying environment tags and subscription separation per environment.
  CAF‑aligned naming conventions were re‑tooled to ensure scalability across environments.

• Network Topology and Connectivity:
  Built a shared Connectivity subscription hosting the hub virtual network and Azure Firewall Manager. Spokes represented the segmented environments (Prod, Dev, etc.), each with segregated subnets but governed by central routing and policy.

• Secure Landing Zone:
  Security baselines were enforced through pre‑built policy initiatives — encrypting storage accounts, restricting VM SKUs, and standardising region deployment.

Outcome:
Within weeks, the customer established a clean, well‑segmented environment with predictable connectivity and security built‑in. They avoided sprawl and surprise charges while achieving a structure ready for workload migrations.

☕ Customer 2 – Brownfield Azure: Evolving Towards the Landing Zone Pattern

Another customer already operates in Azure but realises their environment has grown organically — inconsistent tagging, scattered resources, and no clear linkage between dev, test, and production workloads.

Their challenges:

• Existing structure doesn’t fully align with the proposed Landing Zone pattern.
• Tagging taxonomy is inconsistent and not providing real business value.
• Desire to centralise connectivity for better security visibility and control.
• Need to apply policy guardrails to limit region sprawl and costly VM SKU choices.

Their approach:

• Assessment via CAF Readiness Review:
  Mapped the current environment against the eight design areas to identify remediation scope and technical debt.

• Incremental Landing Zone Adoption:
  Decided not to “lift‑and‑shift” the entire estate, but instead deploy the new ALZ structure in parallel. Existing production workloads started migrating gradually, while new projects launched directly inside Landing Zone subscriptions.

• Automation and Governance Enhancements:
  Introduced Azure Policy initiatives for allowed SKUs, region restrictions, and tagging enforcement.
  Leveraged Azure Resource Graph queries to discover and remediate old resources outside governance boundaries.

• Centralised Connectivity:
  Built a new hub network under the Platform management group and rerouted spokes via Virtual Network Peering.
  This central hub established consistent ingress/egress controls and visibility via Network Watcher and NSG Flow Logs.

Outcome:
Within a few months, the organisation achieved much better visibility, control, and cost predictability.
While legacy resources still coexist, the Landing Zone architecture provided a north star for modernisation — replacing chaos with incremental, systematic improvement.

Both cases show how Azure Landing Zones are not only for new cloud adopters but also a practical refactoring target for existing Azure estates.
Whether greenfield or brownfield, the framework turns fragmented footprints into repeatable, monitored, and governed platforms — proving that the perfect brew is achievable, even when you start with yesterday’s grounds.

Implementation Examples

Deploy via Azure Portal

1. Open the Azure Landing Zone Accelerator.
2. Select the Secure Landing Zone definition.
3. Configure:
   • Management Group hierarchy
   • Connectivity type: Hub‑Spoke or Virtual WAN
   • Defender for Cloud plan onboarding
4. Deploy directly or export configuration for IaC pipeline integration.

Bicep Foundation Example

Here’s a refreshed sample to spin up the management group scaffolding from Automation pipelines:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

param rootMG string = 'mg-root'

resource mgManagement 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-management'
  parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
  displayName: 'mg-management'
}

resource mgPlatform 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-platform'
  parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
  displayName: 'mg-platform'
}

resource mgLanding 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-workloads'
  parentId: tenantResourceId('Microsoft.Management/managementGroups', rootMG)
  displayName: 'mg-workloads'
}

You can then import the modular ALZ‑Bicep packages for policies, connectivity, and monitoring:

1
2
3

az bicep install
bicep install az:alz
bicep build ./main.bicep

Gotchas & Edge Cases

• Policy sequencing: Order of policy assignments still matters. Deploy policy baseline modules before workload‑specific ones to avoid blocking legitimate resources.
• Cross‑tenant identity: Multi‑directory environments may require explicit configuration for Entra cross‑tenant access.
• CIDR overlap: When migrating legacy hubs, ensure address space planning aligns with vWAN or secure hub modules.
• Drift detection lag: If automation is disabled, ALZ configurations can drift — leverage compliance scans and DevOps triggers to correct automatically.

Best Practices

• Adopt ALZ components incrementally — not every design area needs to be deployed on day one.
• Use Bicep or Terraform pipelines for repeatable deployment and compliance validation.
• Map landing zone policy initiatives directly to CAF policy categories for clarity in audits.
• Integrate Defender for Cloud and Log Analytics early to baseline secure posture.
• Apply Privileged Identity Management (PIM) for tenant and management group administrators.
• Align naming and tagging conventions with your Resource Organisation strategy.
• For resiliency, configure Geo‑replicated backups and pair regions for core workloads.
• Treat Automation and DevOps as part of platform design, not post‑deployment tooling.

Learn More

• Azure Landing Zone Conceptual Overview
• Azure Landing Zone Bicep Modules on GitHub
• Microsoft Cloud Adoption Framework (CAF)