Was eine Landing Zone ist

Eine Azure Landing Zone ist der von Microsoft empfohlene Standardweg, eine Azure-Umgebung aufzubauen und im Betrieb zu halten. Sie ist keine einzelne Ressource und kein Produkt, sondern eine wiederholbare Struktur: eine Hierarchie aus Management-Gruppen, darin Abonnements mit klarer Aufgabe, darüber Richtlinien, die auf jedes neue Abonnement automatisch wirken.

Der Punkt ist die Wiederholbarkeit. Wenn die Struktur einmal steht, bekommt das fünfzigste Abonnement dieselben Vorgaben wie das erste, ohne dass jemand daran denken muss. Genau das unterscheidet eine Landing Zone von einer Sammlung gewachsener Abonnements.

Microsoft ordnet den Entwurf acht Bereichen zu: Azure-Abrechnung und Microsoft-Entra-Mandant, Identitäts- und Zugriffsverwaltung, Organisation von Management-Gruppen und Abonnements, Netzwerktopologie und Konnektivität, Sicherheit, Verwaltung, Governance sowie Plattformautomatisierung und DevOps. Diese acht Bereiche sind die Tagesordnung für den Entwurfsworkshop.

Platform Landing Zone und Application Landing Zone

Die wichtigste Unterscheidung fällt am Anfang und wird oft übersprungen.

Die Platform Landing Zone stellt gemeinsame Dienste für Identität, Konnektivität, Verwaltung und Sicherheitsüberwachung bereit. Welche Dienste zentral betrieben werden und wie sie auf Abonnements verteilt sind, richtet sich nach den Anforderungen der Organisation.

Eine Application Landing Zone umfasst die Ressourcen und Umgebungen eines Workloads, etwa Entwicklung, Test und Produktion. Jede Umgebung kann je nach Anforderungen ein oder mehrere Abonnements nutzen. Diese hängen unter passenden Management-Gruppen wie Corp, Online oder Local und erben deren zugewiesene Azure Policies.

Für die meisten Organisationen empfiehlt Microsoft eine Platform Landing Zone pro Entra-Mandant und mehrere Application Landing Zones. Die Trennung schafft klare Zuständigkeiten für gemeinsame Dienste und Workloads; die konkrete Isolation von Netzwerken und Zugriffen muss zusätzlich entworfen werden.

Subscription Vending: das Abonnement als Produkt

Neue Abonnements sollten nach einem einheitlichen Standard entstehen. Subscription Vending automatisiert diesen Weg: Ein Team fordert ein Abonnement an, der Prozess berücksichtigt Management-Gruppe, Rollenzuweisungen, Netzwerkanbindung, Kostenstelle und Namensschema.

Eine manuelle Bereitstellung kann anfangs kontrolliert und nachvollziehbar erfolgen. Mit wachsender Zahl von Anforderungen senkt Automatisierung den Abstimmungsaufwand und das Risiko, Vorgaben zu übersehen.

Für die Verwaltung der Application Landing Zones gibt es drei Modelle: die zentrale Verwaltung durch ein IT-Team, die vollständige Übergabe an das Anwendungsteam bei weiterhin greifenden Richtlinien der Management-Gruppe, und die geteilte Verwaltung bei Technologieplattformen wie AKS, bei denen ein zentrales Team den Unterbau betreibt und die Anwendungsteams das darauf Laufende. Die Entscheidung gehört an den Anfang, nicht in Monat neun.

Netzwerk: Hub-and-Spoke oder Virtual WAN

Die Referenzarchitektur kennt zwei Netzwerktopologien. Hub-and-Spoke ist die klassische Variante mit einem zentralen Hub-VNet für gemeinsame Dienste wie Firewall, VPN-Gateway und DNS, an das die Spokes angebunden werden. Virtual WAN verlagert die Vermaschung in einen von Microsoft verwalteten Dienst.

Hub-and-Spoke bietet viel Freiheit beim eigenen Netzwerkentwurf. Virtual WAN kann die Anbindung vieler Standorte und Regionen vereinfachen; eigene Firewall-Regeln sind auch dort möglich. Routing-Anforderungen, unterstützte Netzwerkfunktionen, Kosten und Betriebsverantwortung entscheiden gemeinsam über die passende Topologie.

Was in beiden Fällen früh entschieden werden muss, ist DNS. Ein zentrales, über Abonnements hinweg integriertes DNS-Setup ist mühsam nachzurüsten, sobald bereits produktive Arbeitslasten Namen auflösen.

Richtlinien statt Nacharbeit

Azure Policy kann technische Vorgaben an Management-Gruppen und anderen Geltungsbereichen prüfen oder durchsetzen, etwa erlaubte Regionen, Verschlüsselung, öffentliche Erreichbarkeit und Tags. Welche Regel für welche Ressourcentypen geeignet ist, muss im Entwurf geprüft werden.

Eine deny-Richtlinie kann nicht konforme Änderungen verhindern. Ob die Vorgabe im vorgesehenen Geltungsbereich wirksam ist, zeigen zusätzlich Zuweisungen, Ausnahmen und Auswertungsergebnisse. Dokumentierte Betriebsabläufe bleiben für organisatorische Maßnahmen erforderlich.

Für Prüfungen nach CIS-Benchmark oder BSI-Grundschutz lassen sich geeignete technische Anforderungen in Policy-Initiativen bündeln. Diese liefern einen Teil der Nachweise; Verantwortlichkeiten, Prozesse und weitere Auditnachweise werden dadurch nicht ersetzt.

Als Code aufbauen und weiterentwickeln

Microsoft empfiehlt für Aufbau und Pflege der Platform Landing Zone Infrastructure as Code mit Bicep oder Terraform und stellt dafür einen Accelerator sowie Azure Verified Modules bereit. Daneben bleibt ein Portal-Accelerator verfügbar, etwa für Organisationen ohne IaC-Erfahrung.

IaC erleichtert Versionierung, Reviews und wiederholbare Bereitstellung. Eine über das Portal aufgebaute Landing Zone bleibt eine Landing Zone, erfordert aber mehr Aufwand, um Änderungen konsistent nachzuhalten. Auch mit IaC muss eine Rücknahme auf ihre Auswirkungen geprüft werden. Wie Teams an diesem Code arbeiten, steht in Terraform im Team.

Wo AWS anders aussieht

Die Idee überträgt sich, die Begriffe nicht. AWS beschreibt dasselbe Problem als Multi-Account-Strategie: Das AWS-Konto ist die Isolationsgrenze für Identität und Zugriff, und zwischen Konten ist standardmäßig kein Zugriff erlaubt. Konten werden in Organizational Units gruppiert, Leitplanken kommen über Service Control Policies.

AWS empfiehlt ausdrücklich, bereits beim Einstieg mehrere Konten zu verwenden statt eines einzigen, und die Security-OU sauber zu halten, also dort nur die von AWS Control Tower vorgesehenen Konten abzulegen und weitere sicherheitsnahe Konten in eine eigene OU zu geben.

Wer beide Clouds betreibt, sollte die Begriffe bewusst nebeneinanderlegen: Management-Gruppe entspricht ungefähr der Organizational Unit, Azure Policy ungefähr der Service Control Policy, das Abonnement ungefähr dem Konto. Ungefähr, nicht genau.

Fünf Fehler, die teuer werden

  1. Die Trennung von Platform und Application Landing Zone auslassen. Das rächt sich beim ersten Anwendungsteam, das eigene Netzwerkregeln braucht.
  2. Abonnements ohne Standard anlegen. Ohne wiederholbaren Prozess können Zuständigkeiten und Vorgaben auseinanderlaufen.
  3. DNS später klären. Zentrales DNS über Abonnements hinweg nachzurüsten, während produktive Systeme laufen, ist ein eigenes Projekt.
  4. Policy-Ergebnisse ohne Folgeprozess lassen. Audit-Modus hilft bei der Einführung. Danach braucht es Verantwortliche für Befunde und die Entscheidung, welche Regeln durchgesetzt werden.
  5. Änderungen nicht nachvollziehbar pflegen. Ohne versionierte Vorgaben und geregelte Reviews wird die Weiterentwicklung aufwändiger.
Kernaussage

Eine Landing Zone verbindet gemeinsame Plattformdienste, abgegrenzte Workload-Umgebungen und überprüfbare Leitplanken. Ein standardisierter Bereitstellungsweg hält neue Abonnements konsistent. IaC erleichtert Änderungen und Wiederholbarkeit; klare Zuständigkeiten und laufende Kontrollen bleiben Teil des Betriebs.

Was Sie danach entscheiden können

  • Ob Ihr Netz als Hub-and-Spoke oder über Virtual WAN entsteht und wer die zentralen Firewall-Regeln pflegt.
  • Welches der drei Verwaltungsmodelle für Application Landing Zones zu Ihren Teams passt: zentral, übergeben oder geteilt.
  • Ob Ihre bestehende Umgebung eine Landing Zone ist oder eine Sammlung gewachsener Abonnements, und wo der Umbau beginnt.

Häufige Fragen

Brauchen wir eine Landing Zone auch für eine einzige Anwendung?

Nicht jede Umgebung braucht die volle Referenzarchitektur. Auch eine einzelne Anwendung benötigt eine passende Grundlage für Identität, Netzwerk, Sicherheit und Betrieb. Den Umfang bestimmen Schutzbedarf, Verfügbarkeitsziele und die geplante Weiterentwicklung.

Wir haben schon Abonnements in Betrieb. Ist es zu spät für eine Landing Zone?

Nein. Je nach Ausgangslage wird die bestehende Struktur schrittweise angepasst oder eine neue Umgebung für geplante Migrationen aufgebaut. Auswirkungen auf Berechtigungen, Richtlinien, Netzwerk und DNS gehören vor Änderungen geprüft.

Bicep oder Terraform?

Beides trägt, Microsoft stellt für beide Accelerator und Azure Verified Modules bereit. Wer nur Azure betreibt, fährt mit Bicep gut; wer mehrere Clouds oder bestehende Terraform-Erfahrung hat, bleibt bei Terraform. Wichtiger als das Werkzeug ist, dass die Umgebung als Code entsteht.

Quellen

Weiterlesen
Cloud & Platform Was ist eine Landing Zone? Cloud & Platform Terraform im Team: Zustand, Module, Review Cloud & Platform Internal Developer Platform: wann sie sich lohnt Leistung Cloud Engineering Leistung Platform Engineering