Azure Platform Engineering: The Complete Guide to Building an Enterprise Landing Zone

Apr 1, 2026 min read
Azure Platform Engineering: The Complete Guide to Building an Enterprise Landing Zone

Your Azure bill arrives and one line item is $47,000. Nobody on your team knows which subscription it came from. You trace it back to a developer who spun up a GPU cluster three weeks ago “just to test something.” There was no policy to stop them. There was no budget alert configured. There was no shared networking — they punched a hole through the firewall themselves. That subscription is a silo. You have fourteen more just like it.

This is what happens when your Azure estate grows without a foundation. Subscriptions accumulate as independent experiments. Security policies are applied by hand, subscription by subscription, whenever someone remembers. Networking becomes overlapping IP ranges and ad-hoc peerings that nobody fully understands. You aren’t running a cloud platform — you’re running a collection of accidents.

An Azure Landing Zone (ALZ) is the architectural foundation that prevents this. It provides the shared services — networking, identity, governance, and logging — that every application needs but no single team should manage alone. In 2026, the standard for building these foundations has shifted from monolithic modules to the Azure Verified Modules (AVM) initiative, emphasizing “Metadata-First” architectures and secret-less CI/CD.

This is the Pillar Post for the Azure Platform Engineering series. Across the next 10 articles, we will build every layer of this architecture using production-grade Bicep and Terraform.

1. The Anatomy of an Enterprise Landing Zone

A landing zone is not a single resource; it is a multi-layered ecosystem designed according to the Cloud Adoption Framework (CAF). Microsoft divides this ecosystem into eight distinct design areas, ranging from billing and identity to networking and operations.

Platform vs. Application Landing Zones

The most critical architectural distinction is between the Platform and the Application.

  • Platform Landing Zones: These are the shared services subscriptions (Connectivity, Identity, Management). They provide the hub VNet, the Entra ID tenant, and the central Log Analytics Workspace.
  • Application Landing Zones: These are the workload subscriptions where your apps actually run. They are “consumers” of the platform, inheriting its security policies and peering back to the hub.

ALZ Management Group Hierarchy

The hierarchy is the “Gavel” of your landing zone. It determines how policies and permissions cascade down to resources.

Tena[[ntP---SlaRaCIMn(otodadEofnenbxtonnaopretgxeMmcierattm]in]iyemavnegitnettmyaetnitonG)roup[[L--DaenCOc(donoRirlmenpimsgnio(esuZIsron(icntEoeeexnssrtenedt]aroln])aPlu)rge)

2. Design Area 1: Network Isolation (Hub-and-Spoke)

Networking is the foundation of isolation. In a landing zone, we use a Hub-and-Spoke topology to centralize shared network services and enforce a single egress point to the internet.

Hub-and-Spoke Core Architecture

[H[U[[-B(SACBPA(VzeaOpUNunsKpDErttERTeri(VaoVVMt]FlnNNsoieE(rE]tT/FCegiowrPAPrnaeerenlse]iwels[rvac)i(alt]DnCtliNgoe)vSri-pEtPnyrTSdirupS[vabou(an)ibVOtsn)PneitN-tsPR)/reesEmoRilsv]eesr)]

In 2026, the Azure DNS Private Resolver is the standard for hybrid name resolution, replacing the need for complex, manual VM-based DNS forwarders. When combined with Azure Firewall Premium, you gain deep packet inspection and TLS termination at the network boundary.

3. Design Area 2: Identity & Governance (Zero Trust)

API keys and standing “Owner” permissions are the primary risks in the modern cloud. Our blueprint moves to a “Keyless and Standing-Access-Free” model.

Managed Identity and OIDC

For CI/CD, we use Workload Identity Federation (OIDC). GitHub Actions and Azure DevOps runners authenticate to Azure using short-lived tokens, eliminating the need to store secrets in your repository settings.

Privileged Identity Management (PIM)

For human administrators, we enforce PIM-only access. No user holds a permanent “Owner” or “Contributor” role. Instead, they are eligible for the role and must activate it for a 4-8 hour window with a business justification and MFA.

# Example: Assigning a Management Group Contributor role to a pipeline SPN at root.
# Note: This requires Global Administrator privileges to execute.
az role assignment create \
  --role "Management Group Contributor" \
  --scope "/" \
  --assignee "<service-principal-object-id>"

4. Building with Azure Verified Modules (AVM)

In 2026, Microsoft retired two predecessor approaches: the monolithic terraform-azurerm-caf-enterprise-scale module and the classic ALZ-Bicep repository. They have been unified into Azure Verified Modules (AVM).

AVM modules are atomic, high-quality, and follows a strict “Contract” for parameters and outputs. This allows you to mix-and-match modules from both Terraform and Bicep while maintaining a consistent security posture.

Terraform AVM Example

module "spoke_vnet" {
  source  = "Azure/avm-res-network-virtualnetwork/azurerm"
  version = "~> 0.7"

  name                = "vnet-prod-app-001"
  resource_group_name = "rg-prod-app-001"
  location            = "eastus"
  address_space       = ["10.1.0.0/16"]

  # AVM includes standard telemetry and diagnostic support
  diagnostic_settings = {
    to_central_law = {
      workspace_resource_id = var.log_analytics_workspace_id # Full Resource ID
    }
  }
}

5. The Deployment Lifecycle (CI/CD)

Deploying a landing zone from a laptop is a single point of failure. A production-grade foundation requires a GitOps workflow.

The Deployment Lifecycle (AVM + CI/CD)

[145...PRLHMiUECnMRRtAGENEA&TRTESEODcVaIM]nEAWIN[2367G....ITPPEAHloNPUasVPBntILRYA/COCoN/TWmMIhmESOaeNTNtnTAS-tCIGK]fATCEREATE[AZUREPLATFORM]

6. Hands-On: Scaffolding Your Landing Zone

Start with the ALZ Accelerator. This tool generates the repository structure, OIDC identities, and initial GitHub Actions workflows for your specific environment. The defaults are designed for a demo. You’re not running a demo — run through the prompts and override what you need.

# Install the ALZ Accelerator PowerShell module
Install-Module -Name ALZ -Force -Scope CurrentUser

# Scaffolding a new environment for GitHub Actions
New-ALZEnvironment -Path "C:\Source\MyALZ" -DeploymentStrategy "GitHubActions"

Key Takeaways

  1. Defaults are Risks: Azure’s default public endpoints and standing permissions must be explicitly hardened for enterprise use.
  2. Hierarchy is the Foundation: A well-designed Management Group tree is the only way to scale policy and cost controls.
  3. Standardize on AVM: Stop building custom modules for standard Azure resources. Use Microsoft-verified patterns to reduce your maintenance debt.
  4. Shift-Left with PRs: Every change to the platform must be previewed via terraform plan or bicep what-if before a human signs off.

The transition to an enterprise landing zone is an ongoing process. As you follow the Azure Platform Engineering series, we will deep-dive into each layer — from the initial MG hierarchy to Day-2 drift detection.

Sources