Azure Landing Zone
The architectural blueprint of a well-organised Azure environment. A landing zone defines how subscriptions, networks, identities, governance and security are structured — before the first workload is deployed.
What is an Azure landing zone?
An Azure landing zone is a prepared, fully configured Azure environment that is ready for workloads. It defines standards for:
- Identity — wer hat welchen Zugriff?
- Netzwerk — how are subnets, VNets and firewalls structured?
- Management — welche Policies, Tags, Alerts gelten?
- Security — how are logging, monitoring and incident response set up?
- Governance — who may do what, where and how?
Der Sinn: Workloads do not have to work out security, networking and governance from scratch every time. They are deployed into a prepared landing zone and inherit every standard automatically.
Analogie: Like a business park with utilities, roads, district heating and security in place before the first companies move in. The companies do not have to build the basic infrastructure themselves and can concentrate on their own business.
Die Management-Group-Hierarchie
Microsoft’s enterprise-scale landing zone recommends a hierarchical structure using management groups:
Tenant Root Group
└── Contoso (Top-Level Management Group)
├── Platform
│ ├── Identity (Entra ID, AD DS VMs)
│ ├── Management (Log Analytics, Backup)
│ └── Connectivity (Hub VNet, Firewall)
├── Landing Zones
│ ├── Corp (internal production workloads)
│ ├── Online (internet-facing workloads)
│ └── SAP / Confidential / etc.
├── Sandbox (free experimentation subscriptions)
└── Decommissioned (subscriptions being retired)
Each management group has its own policies, RBAC and compliance standards. The structure allows governance along the Blast-Radius-Prinzip: the identity team has access to the identity subscriptions but not to the workload subscriptions.
The eight design areas of a landing zone
| Design area | What you decide here |
|---|---|
| 1. Enterprise Enrollment & Microsoft Entra ID Tenants | How many tenants? How are the subscriptions structured? |
| 2. Identity & Access Management | Entra ID design, RBAC, PIM, Conditional Access |
| 3. Management Group & Subscription Organization | The hierarchy and the policies at each level |
| 4. Network Topology & Connectivity | Hub-Spoke vs. VWAN, Firewalls, ExpressRoute |
| 5. Security, Governance & Compliance | Defender, Policy as Code, Compliance-Framework |
| 6. Management & Monitoring | Log Analytics, Azure Monitor, Backup, Update Mgmt |
| 7. Business Continuity & Disaster Recovery | ASR, Backup-Strategie, RTO/RPO-Ziele |
| 8. Deployment Automation / DevOps | Bicep, Terraform, pipelines, approval workflows |
The AVD landing zone as a workload template
Microsoft provides the AVD landing zone as a specialised template. It builds on the generic enterprise-scale landing zone and adds AVD-specific patterns:
AVD-specific components
- Dedicated subscriptions for AVD (separate from corporate workloads)
- Dediziertes VNet for session hosts, peered to the hub
- FSLogix-Storage (Azure Files Premium or NetApp) in its own subscription
- Shared Image Gallery for gold images, managed centrally
- Log Analytics-Integration with AVD-specific dashboards
- Entra-Joined Session Hosts or hybrid AD integration
- Conditional-Access-Policies predefined for AVD applications
Benefit: “Compliant by Default”
When AVD is deployed into a correctly built landing zone, many compliance requirements are met automatically — BitLocker, Encryption at Rest, Audit-Logging, Defender integration, backup. No separate compliance work per workload.
How do you build a landing zone?
Three levels of maturity
- Manual (level 1): clicking through the Azure portal. Acceptable for small proofs of concept, but neither scalable nor reproducible.
- Declarative (Level 2): ARM, Bicep or Terraform templates. Versionable and reproducible, but with an initial effort.
- CI/CD (Level 3): landing zone changes as pull requests, with automatic deployments. The gold standard.
Starting points
- Azure Landing Zones Accelerator — Microsoft’s official reference implementation (Terraform)
- CAF Terraform Modules — ready-made modules for each design area
- Enterprise-Scale Bicep — Microsoft-validated Bicep-Templates
- Azure Blueprints (deprecated) — the old approach, being replaced by deployment stacks
Landing-Zone-Patterns in DaaS Maps
DaaS Maps shows AVD and Windows 365 landing zone templates with real architecture diagrams. For discussion of the Cloud Adoption Framework and enterprise-scale, you will find me on LinkedIn.