Azure Landing Zone Checkliste: 12 Schritte zur produktionsreifen Grundlage

Die meisten gescheiterten Azure-Programme scheitern nicht an der Technik. Sie scheitern, weil jemand Subscriptions ohne Plan angelegt hat — und die nächsten zwei Jahre damit verbringt, Governance-Lücken zu stopfen. Eine sauber umgesetzte Azure Landing Zone beseitigt diese technischen Schulden, bevor auch nur ein Workload deployt wird.

Bei CC Conceptualise haben wir Landing Zones für Organisationen vom 200-Personen-Mittelständler bis zum Großkonzern gebaut. Im Folgenden die Checkliste, die wir bei jedem Projekt anwenden.

Warum Landing Zones entscheidend sind

Eine Landing Zone ist kein Terraform-Repository. Sie ist eine durchdacht gestaltete, regulierte Umgebung, die Identität, Netzwerk, Richtlinien und Kostenleitplanken bereitstellt — damit Anwendungsteams schnell arbeiten können, ohne Risiken zu erzeugen. Microsofts Cloud Adoption Framework (CAF) liefert die Referenzarchitektur; diese Checkliste macht sie umsetzbar.

Faustregel: Wenn Sie eine neue Workload-Subscription nicht innerhalb von 30 Minuten vollständig mit allen Policies bereitstellen können, ist Ihre Landing Zone nicht fertig.

Die 12-Schritte-Checkliste

1. Management-Group-Hierarchie definieren

Orientieren Sie sich an der CAF-Empfehlung: eine Root-Management-Group, darunter Ebenen für Platform, Landing Zones (Corp / Online), Sandbox und Decommissioned. Vermeiden Sie übermäßige Verschachtelung — drei bis vier Ebenen sind optimal.

Ordnen Sie jeden Geschäftsbereich oder Workload-Archetyp einer Management Group zu
Stellen Sie sicher, dass die Hierarchie Policy-Vererbung ohne übermäßige Ausnahmen unterstützt

2. Namens- und Tagging-Konvention festlegen

Bevor eine einzige Ressource angelegt wird, einigen Sie sich auf eine Namenskonvention. Wir empfehlen ein Schema, das Ressourcentyp, Workload, Umgebung und Region kodiert (z. B. rg-erp-prod-westeurope). Erzwingen Sie Pflicht-Tags — mindestens CostCenter, Owner, Environment und DataClassification — per Azure Policy mit Deny-Effekt.

3. Azure AD (Entra ID) und Identität konfigurieren

Privileged Identity Management (PIM) für alle administrativen Rollen aktivieren
Break-Glass-Konten anlegen (mindestens zwei, mit Hardware-Token geschützt, überwacht)
Conditional-Access-Richtlinien umsetzen: MFA erzwingen, Legacy-Auth blockieren, konforme Geräte für Admin-Portale verlangen
Ggf. Federation mit dem On-Premises-IdP einrichten

4. Platform-Subscriptions einrichten

Trennen Sie Management, Identity, Connectivity und Workload-Subscriptions. Platform-Subscriptions hosten gemeinsam genutzte Dienste und dürfen keine Anwendungs-Workloads enthalten.

5. Hub-Netzwerk (oder Virtual WAN) bereitstellen

Entscheiden Sie zwischen einer Hub-and-Spoke-Topologie mit Azure Firewall oder Azure Virtual WAN — abhängig von der Anzahl der Standorte und der Routing-Komplexität.

Azure Firewall Premium oder eine unterstützte NVA im Hub deployen
UDRs auf allen Spoke-Subnetzen konfigurieren, um Traffic über die Firewall zu leiten
ExpressRoute oder VPN Gateway für die Hybrid-Anbindung einrichten
DDoS Protection Standard im Hub-VNet aktivieren

6. DNS-Architektur implementieren

Azure Private DNS Zones für alle PaaS-Private-Endpoints bereitstellen (z. B. privatelink.blob.core.windows.net)
Zonen mit dem Hub-VNet verknüpfen und Conditional Forwarding vom On-Premises-DNS konfigurieren
DNS-Verwaltung in der Connectivity-Subscription zentralisieren

7. Grundlegende Azure Policies zuweisen

Deployen Sie die ALZ-Policy-Baseline und passen Sie sie an Ihre Anforderungen an. Kritische Policies umfassen:

Erlaubte Regionen (Datenresidenz)
Public IP auf NICs unterbinden in Corp-Landing-Zones
Diagnoseeinstellungen deployen an einen zentralen Log-Analytics-Workspace
TLS 1.2 erzwingen auf allen PaaS-Diensten
Unmanaged Disks auditieren / unterbinden

8. Logging und Monitoring konfigurieren

Zentralen Log Analytics Workspace in der Management-Subscription anlegen
Microsoft Defender for Cloud auf allen Subscriptions aktivieren (mindestens für Server, SQL, Storage, Key Vault und Container)
Activity Logs, NSG Flow Logs und Firewall-Logs an den Workspace weiterleiten
Azure Monitor Alerts für kritische Plattformereignisse einrichten

9. Kostenmanagement-Leitplanken etablieren

Budgets und Alarme pro Subscription und Ressourcengruppe setzen
Per Azure Policy teure SKUs in Nicht-Produktionsumgebungen einschränken
Azure Reservations oder Savings Plans für stabile Workloads implementieren
Automatisches Herunterfahren von Dev/Test-VMs einplanen

10. Subscription Vending automatisieren

Manuelle Subscription-Erstellung skaliert nicht. Bauen Sie eine Subscription Vending Machine — eine automatisierte Pipeline (typischerweise Terraform oder Bicep via GitHub Actions / Azure DevOps), die:

Die Subscription unter der richtigen Management Group erstellt
Das Spoke-VNet mit dem Hub peert
Baseline-Policies und RBAC anwendet
Pflichtressourcen deployt (Log-Analytics-Agent-Konfiguration, Diagnoseeinstellungen)

11. RBAC-Modell und Governance-Rollen definieren

Benutzerdefinierte Rollen sparsam einsetzen; bevorzugt Built-in-Rollen verwenden
Rollen auf Management-Group- oder Subscription-Ebene zuweisen, niemals auf einzelnen Ressourcen
Ein Platform-Engineering-Team mit Contributor auf Platform-Subscriptions und Reader übergreifend einrichten
Workload-Teams erhalten Contributor ausschließlich auf ihrer eigenen Subscription

12. Validierung mit einem Canary-Workload

Deployen Sie einen repräsentativen Workload in die Landing Zone, bevor Sie sie für Anwendungsteams freigeben. Prüfen Sie:

Netzwerkkonnektivität (On-Premises, Internet-Egress, Cross-Spoke)
Policy-Durchsetzung (versuchen Sie, eine Policy zu verletzen, und bestätigen Sie die Ablehnung)
Monitoring (Logs müssen innerhalb von Minuten im zentralen Workspace eintreffen)
Kostenverfolgung (Tags und Budget-Alarme müssen korrekt auslösen)

Häufige Fallstricke

Canary-Schritt überspringen. Teams entdecken Netzwerk- oder Policy-Probleme erst in Produktion statt in kontrollierter Umgebung.
Zu großzügiges RBAC. Workload-Teams Owner auf Subscription-Ebene zu geben, macht Ihre Governance-Investition zunichte.
Policy-Remediation ignorieren. Audit-only-Policies deployen und die Compliance-Ergebnisse nie prüfen ist gleichbedeutend mit: keine Policy.
Landing Zone als einmaliges Projekt betrachten. Landing Zones erfordern kontinuierliche Weiterentwicklung — neue Azure-Dienste, neue Compliance-Anforderungen und neue Workload-Archetypen erfordern Anpassungen.

Wie wir unterstützen

CC Conceptualise liefert Landing-Zone-Projekte als vier- bis sechswöchigen Accelerator: zwei Wochen Design, zwei Wochen Build und eine optionale zweiwöchige Härtungsphase, in der wir den ersten Produktions-Workload gemeinsam mit Ihrem Team onboarden. Jedes Projekt liefert eine As-Built-Dokumentation und ein Backlog an Verbesserungen, das Ihr Platform-Team eigenständig umsetzen kann.

Nächster Schritt: Falls Ihre Azure-Umgebung bereits existiert, aber nie auf einem Landing-Zone-Fundament aufgebaut wurde, führen wir ein Landing Zone Retrofit Assessment durch — ein einwöchiges Review mit priorisierter Remediation-Roadmap. Kontaktieren Sie uns, um Ihr Szenario zu besprechen.