Einblicke · Cloud Engineering · 18. August 2026 · 5 min
Die Landing Zone gehört vor den ersten Workload, nicht hinter den zehnten.
Ein Azure-Fundament lässt sich früh günstig aufbauen und später nur teuer nachrüsten. Was dazugehört, was nicht und wie es schlank bleibt.
Die Azure-Landschaft, die wir am häufigsten sehen, ist Projekt für Projekt entstanden. Das erste Team hat eine Subscription und ein virtuelles Netzwerk angelegt. Das zweite hat beides kopiert, mit kleinen Abweichungen. Beim zehnten Workload gibt es neun Netzwerkentwürfe, vier Ansätze für Identität, drei Logging-Konfigurationen und niemanden, der erklären kann, wofür die monatliche Rechnung anfällt.
Ein Fundament unter laufenden Workloads nachzurüsten, ist möglich. Es ist auch der teuerste Weg, eines zu bekommen.
Was eine Landing Zone ist
Eine Landing Zone bündelt Entscheidungen, die jeder Workload übernehmen sollte, statt sie selbst zu treffen:
| Entscheidung | Einmalig in der Landing Zone festgelegt |
|---|---|
| Wo sind Subscriptions eingeordnet? | Management-Group-Hierarchie mit Richtlinienvererbung |
| Wie fließt der Datenverkehr? | Hub-and-Spoke oder Virtual WAN mit zentraler Firewall, DNS und privaten Endpunkten |
| Wer darf was? | Entra-ID-Gruppen, Rollenzuweisungen je Subscription und privilegierter Zugriff mit Freigabe |
| Was wird durchgesetzt? | Azure Policy: zulässige Regionen, Tags, Verschlüsselung, Diagnoseeinstellungen und keine öffentlichen IP-Adressen |
| Wohin gehen die Logs? | Zentraler Log-Analytics-Arbeitsbereich mit Aufbewahrungs- und Zugriffsregeln |
| Was kostet es? | Budgets und Warnungen je Subscription sowie Tags zur Zuordnung zu Kostenstellen |
| Wie wird es geändert? | Terraform in einem Repository mit Pipeline, Reviews und State Locking |
Alles in dieser Tabelle ist unspektakulär, und genau darum geht es. Ein Workload-Team sollte sagen können: „Wir brauchen eine Subscription für dieses System“, und eine erhalten, in der Netzwerk, Identität, Richtlinien, Logging und Kostenerfassung bereits eingerichtet sind.
Was nicht dazugehört
Landing Zones scheitern in zwei Richtungen. Sie sind entweder zu dünn aufgestellt: eine Subscription und ein Wunsch. Oder zu schwerfällig: Ein Plattformteam baut ein Jahr lang ein „Cloud Centre of Excellence“, und kein Workload kommt an. Der zweite Fehler ist teurer, weil er zusätzlich Glaubwürdigkeit kostet.
Diese Dinge gehören nicht in die erste Landing Zone:
- Kubernetes. Es ist eine Plattform für Workloads, kein Fundament. Bauen Sie sie auf, wenn der erste containerisierte Workload konkret ansteht.
- Ein Servicekatalog und ein Self-Service-Portal. Beginnen Sie mit einem Terraform-Modul und einem Pull Request. Ergänzen Sie ein Portal, wenn das Modul zwanzigmal genutzt wurde.
- Mehrere Regionen und Notfallwiederherstellung für alles. Entscheiden Sie je Workload; die Landing Zone muss es nur ermöglichen.
- Jede Azure Policy aus der integrierten Bibliothek. Beginnen Sie mit den zwanzig, die teure Fehler verhindern.
Das sinnvolle Minimum
Eine Landing Zone, die in ein Terraform-Repository passt und ein kleines Team zwei bis vier Wochen kostet:
- Management Groups: platform, landing zones (corp, online), sandbox, decommissioned.
- Drei Plattform-Subscriptions: identity, management (Logging), connectivity (Hub).
- Ein Hub-Netzwerk mit Firewall, privaten DNS-Zonen und einer vorbereiteten Anbindung für VPN oder ExpressRoute.
- Ein Modul zur Subscription-Bereitstellung: Es erstellt aus einer kurzen Eingabedatei eine Subscription, ein per Peering mit dem Hub verbundenes Spoke-Netzwerk, Rollenzuweisungen, Budget, Diagnoseeinstellungen und Tags.
- Ein Richtliniensatz: zulässige Standorte, verpflichtende Tags, Diagnoseeinstellungen, Verbot öffentlicher IP-Adressen bei PaaS und Verbot unverschlüsselter Speicherung.
- Eine Pipeline, die bei einem Pull Request den Plan erstellt und ihn beim Merge anwendet, mit State in einem gesperrten Storage Account.
Das reicht, um den ersten Workload richtig aufzunehmen und jeden weiteren auf dieselbe Weise.
Wenn es bereits anders gelaufen ist
Wenn Sie bereits neun Netzwerkentwürfe haben, starten Sie kein Migrationsprogramm. Bauen Sie die Landing Zone neben der bestehenden Landschaft auf, nehmen Sie neue Workloads ab dem ersten Tag darin auf und verlagern Sie bestehende erst, wenn es ohnehin einen weiteren Änderungsanlass gibt. Innerhalb eines Jahres wird die alte Landschaft zu einer schrumpfenden Liste statt zu einer wachsenden.
