Azure Landing Zone
Die architektonische Blaupause einer gut aufgestellten Azure-Umgebung. Eine Landing Zone definiert, wie Subscriptions, Netzwerke, Identities, Governance und Security strukturiert werden — bevor die erste Workload deployt wird.
Was ist eine Azure Landing Zone?
Eine Azure Landing Zone ist eine vorbereitete, fertig konfigurierte Azure-Umgebung, die ready ist für Workloads. Sie definiert Standards für:
- Identity — wer hat welchen Zugriff?
- Netzwerk — wie sind Subnetze, VNets, Firewalls strukturiert?
- Management — welche Policies, Tags, Alerts gelten?
- Security — wie ist Logging, Monitoring, Incident Response aufgebaut?
- Governance — wer darf was, wo, und wie?
Der Sinn: Workloads müssen nicht jedes Mal neu überlegen, wie Security, Netzwerk, Governance aussehen sollen. Sie werden in eine vorbereitete Landing Zone deployed und erben alle Standards automatisch.
Analogie: Wie ein Gewerbegebiet mit Anschlüssen, Straßen, Fernwärme, Sicherheit — bevor die ersten Firmen einziehen. Die Firmen müssen die Basisinfrastruktur nicht selber bauen, sondern können sich auf ihr Kerngeschäft konzentrieren.
Die Management-Group-Hierarchie
Microsoft’s Enterprise-Scale Landing Zone empfiehlt eine hierarchische Struktur mit 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 (freie Experimentier-Subs)
└── Decommissioned (auslaufende Subs)
Jede Management Group hat eigene Policies, RBAC, Compliance-Standards. Die Struktur erlaubt Governance nach Blast-Radius-Prinzip: Identity-Team hat Zugriff auf Identity-Subs, aber nicht auf Workload-Subs.
Die 8 Design-Areas einer Landing Zone
| Design-Area | Was entscheidest du hier? |
|---|---|
| 1. Enterprise Enrollment & Azure AD Tenants | Wieviele Tenants? Wie die Subs strukturiert? |
| 2. Identity & Access Management | Entra ID-Design, RBAC, PIM, Conditional Access |
| 3. Management Group & Subscription Organization | Hierarchie, Policies pro Ebene |
| 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 |
AVD Landing Zone als Workload-Template
Microsoft stellt AVD Landing Zone als spezialisiertes Template bereit. Sie baut auf der generischen Enterprise-Scale Landing Zone auf und fügt AVD-spezifische Patterns hinzu:
AVD-spezifische Komponenten
- Eigene Subscription(s) für AVD (getrennt von Corp-Workloads)
- Dediziertes VNet für Session Hosts, mit Peering zum Hub
- FSLogix-Storage (Azure Files Premium oder NetApp) in separater Subscription
- Shared Image Gallery für Gold Images, zentral verwaltet
- Log Analytics-Integration mit AVD-spezifischen Dashboards
- Entra-Joined Session Hosts oder Hybrid-AD-Integration
- Conditional-Access-Policies für AVD-Apps vordefiniert
Vorteil: „Compliant by Default“
Wenn AVD in einer korrekt aufgesetzten Landing Zone deployt wird, sind viele Compliance-Anforderungen automatisch erfüllt — BitLocker, Encryption at Rest, Audit-Logging, Defender-Integration, Backup. Keine separate Compliance-Arbeit pro Workload mehr.
Wie baut man eine Landing Zone?
Drei Reifegrade
- Manuell (Level 1): Azure-Portal klicken. Für kleine POCs okay, aber nicht skalierbar oder reproduzierbar.
- Declarative (Level 2): ARM/Bicep/Terraform-Templates. Versionierbar, reproduzierbar, aber mit Initial-Aufwand.
- CI/CD (Level 3): Landing Zone-Änderungen als Pull Requests, automatische Deployments. Der Gold-Standard.
Starter-Optionen
- Azure Landing Zones Accelerator — Microsoft’s offizielle Referenz-Implementation (Terraform)
- CAF Terraform Modules — fertige Module für jede Design-Area
- Enterprise-Scale Bicep — Microsoft-validated Bicep-Templates
- Azure Blueprints (deprecated) — alte Lösung, wird durch Deployment Stacks ersetzt
Landing-Zone-Patterns in DaaS Maps
Die DaaS Maps zeigen AVD- und W365-Landing-Zone-Templates mit realen Architektur-Diagrammen. Für Diskussionen zu Cloud Adoption Framework und Enterprise-Scale trefft ihr mich auf LinkedIn.