If you’re setting up an enterprise-grade Azure platform, the Cloud Adoption Framework (CAF) “design areas” are your blueprint. Below is a practitioner-friendly take on each area, how they fit together, and what’s new in 2025—plus concrete choices, pitfalls, and implementation options you can put to work right away.

TL;DR

Azure landing zones are built around eight design areas—four “environment” foundations and four “compliance & operations” capabilities. Treat these as the control plane for scale, security, and day‑2 operations. Microsoft’s conceptual architecture and the design‑area articles are the canonical source; use them as your baseline and tailor cautiously.

The eight design areas at a glance

Use this as a checklist during platform reviews and as headings in your Architecture Decision Records (ADRs).

Category Design area What it establishes Typical artifacts & patterns
Environment Azure billing & Entra tenant Correct tenant creation, enrollment model, and billing alignment CSP/EA/MCA enrollment, billing scope, tenant provisioning checklist, incident/ownership contacts
Identity & access management Primary security boundary and trust fabric Entra tenant design, PIM/MFA/CA baselines, RBAC strategy, tenant/landing zone role model, break‑glass accounts
Resource organization Subscription strategy, management group (MG) hierarchy, naming & tagging MG hierarchy (platform vs. application LZs), subscription vending process, tagging taxonomy, cost boundaries
Network topology & connectivity Intra‑/inter‑subscription connectivity and north‑south controls Hub‑and‑spoke or vWAN, Azure Firewall, Private DNS/Link, DDoS plans, hybrid connectivity (ER/VPN)
Compliance & operations Security Controls to protect workloads & platform Defender for Cloud plans, policy initiatives, Sentinel (placement strategy), key/vault strategy, secrets hygiene
Management Visibility, operations compliance, backup/recovery Monitor/Log Analytics workspace topology, AMA data collection rules, update management, runbooks, inventory
Governance Automated auditing & enforcement Azure Policy assignments at MGs, blueprinting via policy sets, regulatory initiatives aligned to MG scopes
Platform automation & DevOps How you deploy the platform itself (repeatable & safe) IaC pipelines, change management, AVM modules/ALZ accelerator, canary testing for platform changes

How the design areas fit together

Microsoft’s latest conceptual architecture shows platform landing zones (shared services) clearly separated from application landing zones (workloads), with subscriptions as the core unit of management—this supports subscription democratization and policy‑driven governance. Use the Visio/PDF if you need to brief stakeholders visually.

Key decisions & anti‑patterns—by design area

Design area Decide on… Good default Anti‑patterns to avoid
Billing & tenant Enrollment model, invoicing, cost scope Single authoritative tenant; document billing scopes Mixing personal/MSAs; unclear owner for cost anomalies
Identity & access Admin model, PIM, MFA/CA, role model Enforce MFA; PIM for privileged roles; least‑privileged RBAC at scope Long‑lived standing admin rights; custom roles without governance
Resource organization Subscription purpose & scale, MG hierarchy Separate platform vs application LZs; standard naming & tags; automated subscription vending Treating RGs (not subscriptions) as the main boundary; ad‑hoc subscription creation
Network topology Hub choice (vWAN vs hub‑spoke), DNS, Private Link Centralized DNS; Private Link for PaaS; firewall as choke point Peering sprawl; public endpoints for critical control‑plane components
Security SIEM/SOAR placement, Defender coverage Dedicated Security MG + Subscription; scope Sentinel there Co‑locating SIEM with ops logs; unclear SoD for security tooling
Management Log topology, telemetry, updates, backup Single (or dual‑region) central LAW; AMA; Update rings; platform backup MMA legacy agents; unmanaged diagnostic settings; single‑region for critical ops data
Governance Policy initiatives, exemptions, debt mgmt Assign initiatives at MGs; track posture & assignment drift Initiative assignment only at subscription level; untracked exemptions
Platform automation & DevOps IaC standard, pipelines, change control AVM for Platform Landing Zones via the ALZ IaC Accelerator; canary approach Monolithic scripts; no versioning; platform changes without staged validation

What’s new (or newly emphasized) in 2025

1) Security Management Group & Subscription
The ALZ conceptual architecture now calls out a dedicated Security MG and Security Subscription (empty by default) so you can deploy Sentinel and security tooling independently of operational logs. This improves separation of duties and aligns with customers’ observed operating models. Tooling updates follow the guidance over time.

2) From the “ESLZ” monolith to AVM modules
The long‑lived terraform‑azurerm‑caf‑enterprise‑scale module is now in extended support and slated for archiving on August 1, 2026. For new deployments, Microsoft recommends Azure Verified Modules (AVM) for Platform Landing Zones, surfaced via the ALZ IaC Accelerator. This shift gives you smaller, well‑tested modules and faster feature velocity.

3) Out‑of‑the‑box compliance assignments
The ALZ portal accelerator makes it easier to assign regulatory initiatives (ISO, PCI DSS, etc.) to your MG hierarchy during deployment—great for establishing a baseline posture on day one.

Implementation options (Terraform‑centric)

Option What it is When to choose Notes
AVM for Platform Landing Zones A set of Terraform AVM “pattern modules” composed to deploy the platform landing zone (MGs+Policy, management, connectivity, DNS, gateways/vWAN). Default for new builds; modularity needed; faster updates Backed by AVM program standards; available in Terraform Registry (e.g., hub‑and‑spoke connectivity).
ALZ IaC Accelerator Bootstrap + pipelines + opinionated repo to deploy AVM patterns (GitHub/Azure DevOps). You want a jumpstart with best‑practice repo layout & Workload Identity Federation. Accelerator defaults to AVM; supports multi‑region & resilience out‑of‑the‑box.
CAF Enterprise‑Scale TF module The former “monolith” module. Existing estates; keep it patched during transition. Extended support; plan migration landing zones to AVM before 2026.

Sequencing the work: a pragmatic order of operations

1) Identity & tenant → 2) Resource organization → 3) Governance (baseline policy initiatives) → 4) Network topology → 5) Management (telemetry, update, backup) → 6) Security (enable plans, sentinel placement) → 7) Platform automation (pipelines, canary) → 8) Regions (add new regions via tested patterns). The CAF docs provide region‑agnostic guidance and steps for adding regions to an existing platform.

Subscription vending: scale without chaos

Automate subscription creation with vending modules to enforce: MG placement, tags, RBAC, network attach (hub/vWAN), and DDoS plans—before teams deploy anything. This operationalizes subscription democratization while keeping governance intact.

Quick “definition of done” per design area

Design area Minimal “green” outcome
Tenant & billing Enrollment & invoicing verified; cost owner documented; incident/billing contacts set.
Identity & access PIM + MFA enforced; break‑glass tested; RBAC model documented; admin segregation verified.
Resource organization MG hierarchy deployed; subscription vending live; tags/naming enforced by policy.
Network Chosen topology (hub/vWAN) deployed; DNS & Private Link standardized; hybrid links resilient.
Security Defender plans scoped; Sentinel strategy (now in Security Subscription) defined; secrets hygiene in place.
Management LAW(s) with AMA DCRs; update/backup policies assigned; diag settings enforced by policy.
Governance Regulatory initiatives assigned at MG scope; exemption workflow; drift report via AzGovViz.
Platform automation & DevOps ALZ Accelerator + AVM in CI/CD; change approvals; canary/test subscriptions for platform changes.

Field tips (learned the hard way)

  • Separate ops vs. security telemetry: Keep operational logs in the Management subscription and security telemetry in the Security subscription to simplify RBAC and SoD—and to control Sentinel costs independently.
  • Treat policies as code: Store initiative parameters and exemptions in source control; track policy assignment drift with AzGovViz and close gaps in sprints.
  • Design for region moves: Even if you start single‑region, ensure the platform can add regions without refactoring (vWAN or dual‑region hub patterns).
  • Modernize your IaC stack: Prefer AVM modules and the ALZ Accelerator for new work; plan a managed transition from the ESLZ module where it’s still in place.

Further reading & resources

  • Design areas & conceptual architecture (Microsoft Learn) — the authoritative baseline.
  • What is an Azure landing zone? — platform vs. application LZs, conceptual diagram.
  • Design principles — subscription democratization, policy‑driven governance, and trade‑offs.
  • Regions & landing zones — adding/migrating regions safely.
  • Start with enterprise‑scale — background and evolving guidance.
  • AVM for Platform Landing Zones (Learn) — Terraform AVM patterns overview.
  • AVM project hub (GitHub) and Terraform Registry examples for ALZ connectivity.
  • GA announcement: AVM for ALZ — details and Accelerator updates.
  • ALZ update: Security MG & Subscription — why Sentinel moved and how to adopt the new design.
  • Regulatory initiatives at deploy time — assign compliance policies at MG scope.
  • Subscription vending — automate subscription creation aligned to governance.
  • ESLZ module deprecation — extended support through Aug 1, 2026. Plan migrations.

Example Terraform-based deployment script

Here’s an example Terraform-based deployment script using Azure Verified Modules (AVM) and the ALZ IaC Accelerator pattern. This script bootstraps a Platform Landing Zone with:

  • Management Group hierarchy
  • Policy assignments
  • Logging & monitoring
  • Connectivity (Hub-and-Spoke)
  • Security MG & Subscription placeholder

main.tf – Example Deployment Script

terraform { required_version = ">= 1.5.0" required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.100" } } } provider "azurerm" { features {} } # ------------------------- # 1. Management Groups & Policy # ------------------------- module "alz_management" { source = "Azure/avm-ptn-alz/azurerm" version = "x.y.z" # pin exact version root_management_group_id = "alz-root" deploy_policy = true policy_assignments = ["alz-default", "alz-security", "alz-compliance"] subscription_ids = { platform = "00000000-0000-0000-0000-000000000000" security = "11111111-1111-1111-1111-111111111111" } tags = { environment = "platform" owner = "cloud-team" } } # ------------------------- # 2. Management Resources (Log Analytics, Automation) # ------------------------- module "alz_management_resources" { source = "Azure/avm-ptn-management-alz/azurerm" version = "x.y.z" location = "westeurope" log_analytics_workspace = { name = "law-platform" sku = "PerGB2018" retention_in_days = 30 } enable_update_management = true } # ------------------------- # 3. Connectivity (Hub-and-Spoke) # ------------------------- module "alz_connectivity" { source = "Azure/avm-ptn-alz-connectivity-hub-and-spoke-vnet/azurerm" version = "x.y.z" location = "westeurope" hub_virtual_network = { name = "hub-vnet" address_space = ["10.0.0.0/16"] } enable_firewall = true enable_ddos = true } # ------------------------- # 4. Security Subscription Placeholder # ------------------------- # Sentinel and security tooling will be deployed here later

variables.tf – Key Inputs

variable "root_management_group_id" { description = "Root MG for ALZ" type = string } variable "subscription_ids" { description = "Platform and Security subscription IDs" type = map(string) }

pipeline.yml – ALZ Accelerator CI/CD (Azure DevOps)

trigger: branches: include: - main stages: - stage: Validate jobs: - job: terraform_validate steps: - script: terraform init && terraform validate displayName: "Validate Terraform" - stage: Deploy jobs: - job: terraform_apply steps: - script: | terraform init terraform plan -out=tfplan terraform apply -auto-approve tfplan displayName: "Deploy ALZ Platform"

How to run locally

terraform init terraform plan -var="root_management_group_id=alz-root" \ -var="subscription_ids={platform=\"<GUID>\",security=\"<GUID>\"}" terraform apply

Why this matters:

  • Uses AVM modules (future-proof, modular).
  • Aligns with CAF design areas (MGs, governance, connectivity, management).
  • Compatible with ALZ IaC Accelerator pipelines for GitHub or Azure DevOps.

References

Azure landing zone design areas - Cloud Adoption Framework

What is an Azure landing zone? - Cloud Adoption Framework

Azure landing zone design principles - Cloud Adoption Framework ...

Subscription Vending, now and beyond | Microsoft Community Hub

A New Platform Management Group & Subscription for Security in Azure ...

Keep your Azure Landing Zones policy assignments up to date with Azure ...

Azure Verified Modules for Platform Landing Zones (ALZ)

Azure landing zones Terraform module - GitHub

Announcing General Availability of Terraform Azure Verified Modules for ...

New feature: easily assign regulatory compliance policies to your Azure ...

GitHub - Azure/Azure-Verified-Modules: Azure Verified Modules (AVM) is ...

avm-ptn-alz-connectivity-hub-and-spoke-vnet - Terraform Registry

Landing zone regions - Cloud Adoption Framework | Microsoft Learn

Start with Cloud Adoption Framework enterprise-scale landing zones ...

Why this matters — especially for security

Landing zones are not just an architectural nicety; they are the security backbone of your Azure estate. Here’s why:

  • Identity is the first perimeter
    Without a well‑designed Entra tenant and RBAC model, attackers can exploit privilege sprawl or stale accounts. PIM, MFA, and conditional access are non‑negotiable.
  • Management Groups and Policy enforce guardrails at scale
    A single misconfigured subscription can expose sensitive data. Policy‑driven governance ensures every workload inherits the same security posture from day one.
  • Network topology defines your blast radius
    Hub‑and‑spoke or vWAN patterns with Private Link and firewalls prevent lateral movement and reduce exposure to the public internet.
  • Dedicated Security Subscription = Separation of Duties
    Placing Sentinel and security tooling in their own subscription isolates telemetry, simplifies RBAC, and prevents operational teams from tampering with security data.
  • Automation is your ally
    Manual deployments invite drift and human error. Using AVM modules and the ALZ Accelerator ensures repeatable, tested, and auditable changes—critical for compliance and incident response.
  • Regulatory alignment from day zero
    Assigning ISO, PCI DSS, or NIST initiatives at the management group level means you’re not retrofitting compliance later under pressure.

Bottom line

A landing zone designed with these principles is your control plane for trust. It reduces attack surface, enforces least privilege, and provides the telemetry you need to detect and respond quickly. In a world of increasing cloud breaches, this isn’t optional—it’s your first and best line of defence.

Archives