Eine Landing Zone ist die vorbereitete Grundstruktur einer Cloud-Umgebung. Sie entsteht idealerweise vor dem ersten produktiven Workload, kann aber auch in eine bestehende Umgebung eingeführt werden. AWS beschreibt eine Mehrkonten-Umgebung mit Sicherheits- und Compliance-Leitplanken [3]. Microsoft bietet dafür eine anpassbare Referenzarchitektur für Azure [1].

Sie ist kein Produkt, das man kauft, und keine einzelne Ressource. Sie ist eine Entwurfsentscheidung, die sich in Konfiguration niederschlägt: Wo verläuft die Grenze zwischen zwei Anwendungen, wer darf was, welche Regeln gelten überall, und wie entsteht die nächste Umgebung.

Warum die Grundstruktur vor die erste Anwendung gehört

Der übliche Ablauf ist umgekehrt. Ein Projekt braucht kurzfristig eine Umgebung, jemand legt sie an, es funktioniert. Beim zweiten Projekt wiederholt sich das, beim zwanzigsten kennt niemand mehr alle Umgebungen.

Danach fehlen drei Dinge gleichzeitig: eine belastbare Grenze zwischen den Umgebungen, eine Stelle, an der Regeln für alle gelten, und eine Zuordnung von Kosten zu Verantwortlichen. Jede dieser Lücken lässt sich einzeln schließen, aber nur mit laufendem Betrieb daneben.

AWS empfiehlt deshalb ausdrücklich, schon beim Einstieg mehrere Konten zu verwenden statt eines einzigen, weil das Konto die Isolationsgrenze für Identität und Zugriff ist: Zwischen Konten ist standardmäßig kein Zugriff erlaubt, geteilte Zugriffe müssen ausdrücklich freigegeben werden [4].

Der Aufwand verschwindet also nicht, er verschiebt sich. Vor dem ersten produktiven Workload kostet die Struktur Entwurfszeit. Nach dem fünfzigsten kostet ihr Nachbau ein eigenes Projekt.

Die Bausteine, unabhängig vom Anbieter

Sieben Bausteine tauchen in jeder Umsetzung auf. Die Namen wechseln, die Aufgaben bleiben.

  • Mandanten- und Kontenschnitt. Welche Einheit trennt zwei Anwendungen voneinander, und wonach wird geschnitten: je Anwendung, je Umgebung, je Team? Diese Einheit ist zugleich die Grenze für Rechte, Kontingente und meist auch für die Abrechnung.
  • Netzwerkgrundgerüst. Adressbereiche, Übergänge nach außen, Anbindung ans eigene Rechenzentrum und die Namensauflösung. Adressplan und DNS sind die beiden Entscheidungen, die sich später am schlechtesten korrigieren lassen.
  • Identität und Rechte. Woher kommen die Konten der Menschen, woher die der Maschinen, und welche Rolle gilt auf welcher Ebene? Ohne diese Antwort entstehen persönliche Zugänge mit Dauerrechten.
  • Richtlinien und Leitplanken. Technische Vorgaben werden möglichst zentral geprüft und durchgesetzt, etwa erlaubte Regionen, Verschlüsselung und Tags. Zuweisungen, Ausnahmen und Prüfergebnisse liefern Nachweise. Organisatorische Maßnahmen benötigen ergänzende Dokumentation.
  • Protokollierung. Wer hat wann was geändert, und wo liegt diese Spur? Sie gehört in eine Umgebung, auf die die Anwendungsteams keinen Schreibzugriff haben.
  • Kostenzuordnung. Jede Einheit bekommt einen Verantwortlichen und eine Kostenstelle. Werden diese erst später zugeordnet, kann die rückwirkende Aufteilung aufwändiger oder unvollständig werden.
  • Bereitstellung als Code. Versionierte Vorlagen erleichtern konsistente Bereitstellung, Reviews und Änderungen. Manuelle Schritte bleiben möglich, benötigen aber dieselben Vorgaben und einen nachvollziehbaren Ablauf.

Diese Entscheidungen hängen zusammen: Zugriffsmodelle brauchen klare Grenzen, zentrale Leitplanken einen passenden Geltungsbereich. Code macht die vereinbarte Struktur leichter wiederholbar. Den Ansatz erklärt Was ist Infrastructure as Code?

Drei Umsetzungen nebeneinander

Dasselbe Konzept auf drei Plattformen. Für jede stehen dieselben drei Fragen: Wie heißt das Konstrukt, was ist die kleinste Einheit, und wie werden Leitplanken durchgesetzt?

Azure

Microsoft nennt die eigene Umsetzung Azure Landing Zone und beschreibt sie als den standardisierten Weg für alle Organisationen, die Azure nutzen [1]. Die Struktur ist eine Hierarchie aus Management-Gruppen, unter denen die Abonnements hängen.

Ein wichtiger Organisationsschnitt in Azure ist das Abonnement. Die Platform Landing Zone stellt gemeinsame Dienste bereit. Eine Application Landing Zone umfasst die Umgebungen eines Workloads; jede Umgebung kann ein oder mehrere Abonnements nutzen. Diese können standardisiert über Subscription Vending bereitgestellt werden [1].

Die Leitplanken kommen über Azure Policy. Eine Zuweisung gilt für ihren Geltungsbereich, und alle untergeordneten Ressourcen erben sie; ausgenommen werden kann nur ausdrücklich [2]. Der Effekt deny lehnt eine Änderung ab, die gegen die Regel verstößt. Microsoft empfiehlt, mit einem prüfenden Effekt zu beginnen und erst danach zu erzwingen [2]. Für den Aufbau empfiehlt Microsoft ausdrücklich Infrastructure as Code mit Bicep oder Terraform statt des Portal-Wegs [1].

Die Details, von der Netzwerktopologie bis zu den Fehlern, die teuer werden, stehen im Praxisartikel Azure Landing Zone: Bausteine, Entscheidungen, Fehler.

AWS

AWS behandelt dieselbe Aufgabe als Multi-Account-Strategie. Eine Landing Zone ist dort die an Sicherheits- und Compliance-Vorgaben ausgerichtete Mehrkonten-Umgebung, der unternehmensweite Behälter für Organizational Units, Konten, Benutzer und Ressourcen, die geregelt sein sollen [3].

Die kleinste Einheit ist das AWS-Konto. Es ist die Isolationsgrenze für Identität und Zugriff, und zwischen Konten ist standardmäßig kein Zugriff erlaubt [4]. Konten werden in Organizational Units gruppiert; AWS empfiehlt außerdem, die Security-OU sauber zu halten und weitere sicherheitsnahe Konten in eine eigene OU zu legen [4].

Die Leitplanken heißen dort Controls, umgangssprachlich Guardrails. AWS Control Tower richtet die Landing Zone ein und wendet Controls an, damit die Umgebung nicht von den Vorgaben abweicht; es gibt vorbeugende, aufdeckende und proaktive [3]. Darunter liegen Service Control Policies: Sie erteilen keine Rechte, sondern setzen die Obergrenze dessen, was Benutzer und Rollen eines Mitgliedskontos überhaupt tun dürfen [5]. Neue Konten entstehen über die Account Factory, eine konfigurierbare Kontovorlage, die das Anwenden der Controls mit erledigt [3].

STACKIT

STACKIT ist der Cloud-Anbieter von Schwarz Digits, der IT- und Digitalsparte der Schwarz Gruppe [6]. Die Regionen liegen nach Anbieterangabe ausschließlich in Deutschland (eu01) und Österreich (eu02) [7]; STACKIT begründet die Souveränität mit Rechenzentren in der EU, dem Anbietersitz in Deutschland und offener Technologie [6]. Das ist der Grund, aus dem die Plattform überhaupt in eine Auswahl kommt: wenn eine Vorgabe festlegt, wo Daten liegen und wer dem Anbieter rechtlich zugreifen könnte. Wer eine Region außerhalb dieser beiden Länder braucht, braucht eine andere Plattform.

Das Konstrukt heißt Resource Manager. Die Hierarchie lautet Organisation, Ordner, Projekt, Ressource. Die Organisation ist die Wurzel und Voraussetzung für jeden Dienst; Ordner gruppieren Projekte, etwa nach Abteilung, Umgebung oder Region, sind aber einstufig: Ein Ordner kann keine weiteren Ordner enthalten [8]. Das ist ein sichtbarer Unterschied zu Azure, wo eine Management-Gruppe untergeordnete Management-Gruppen tragen kann [2]. Wer eine mehrstufige Gruppierung gewohnt ist, plant hier mit genau zwei Ebenen über dem Projekt.

Die kleinste Einheit ist das Projekt. Die Dokumentation nennt es den grundlegenden Behälter für Cloud-Ressourcen, der den Rahmen für Eigentümerschaft, Ressourcenverbrauch und Zugriffskontrolle festlegt; jede Ressource gehört zu genau einem Projekt, und Kontingente greifen auf Projektebene [9]. Beim Anlegen werden übergeordnete Organisation oder Ordner, Projekttyp und Abrechnungskonto gesetzt [10]. Damit fällt die Kostenzuordnung an derselben Stelle wie der Schnitt.

Die Leitplanken laufen über das Rollenmodell. STACKIT arbeitet mit rollenbasierter Zugriffskontrolle: Eine Policy weist einem Subjekt eine Rolle für eine Ressource zu, und ohne Rollenbindung hat niemand Zugriff [11]. Berechtigungen aus Rollenbindungen auf Organisation und Ordner werden entlang der Hierarchie an Ordner und Projekte vererbt; eine geerbte Berechtigung lässt sich nur dort entfernen, wo sie vergeben wurde [11]. STACKIT empfiehlt genau deshalb den Ordner als Ebene für Umgebung oder Team, weil dort gesetzte Regeln und Zugriffsrechte alle Projekte darunter absichern [12].

Die Mechanismen sind nicht gleichwertig. Azure Policy prüft Ressourceneigenschaften; AWS Service Control Policies begrenzen erlaubte Aktionen und können dabei unterstützte Bedingungen auswerten [2][5]. Die genannten STACKIT-Dokumente beschreiben Rollenbindungen und Projektkontingente. Ergänzende Vorgaben lassen sich im Bereitstellungsweg prüfen. Damit diese Prüfungen nicht umgangen werden, müssen direkte Änderungsrechte begrenzt und Ausnahmen kontrolliert werden.

Das passt zum Rest des Werkzeugkastens. Ein Projekt lässt sich über das STACKIT-Portal, die CLI und die API anlegen [10], und für die Infrastruktur darin gibt es einen offiziellen Terraform-Provider von STACKIT [13]. Der Weg über Code ist damit derselbe wie auf Azure und AWS, nur mit weniger Ebenen darüber.

Frage Azure AWS STACKIT
Name der Struktur Azure Landing Zone Landing Zone, Multi-Account-Umgebung Resource Manager
Ebene darüber Management-Gruppe, verschachtelbar Organizational Unit Organisation und Ordner, Ordner einstufig
Organisationsgrenze Abonnement Konto Projekt
Leitplanken Azure Policy, vererbt, Effekt deny Controls und Service Control Policies vererbte Rollenbindungen und Kontingente
Neue Einheit entsteht per Subscription Vending über die Account Factory über Portal, CLI oder API
Als Code Bicep oder Terraform, von Microsoft empfohlen Account Factory for Terraform [18] offizieller Terraform-Provider
Dieselbe Aufgabe in drei Begriffswelten. Die Zuordnung ist ungefähr, nicht deckungsgleich.

Was in allen drei Umsetzungen gleich bleibt

Drei Punkte gelten unabhängig vom Anbieter, und sie sind der Grund, warum sich der Entwurf überhaupt übertragen lässt.

Neue Umgebungen entstehen nach einem verbindlichen Standard. Automatisierung macht diesen Weg bei wachsendem Bedarf zuverlässiger. Auch eine manuelle Bereitstellung kann kontrolliert und nachvollziehbar erfolgen; entscheidend sind konsistente Vorgaben und die Prüfung ihrer Umsetzung [1].

Vererbung braucht eine passende Hierarchie. Alle drei Plattformen vererben bestimmte Vorgaben oder Berechtigungen [2][5][11]. Regeln können je nach Plattform zusätzlich durch Geltungsbereiche, Bedingungen oder Ausnahmen differenziert werden. Der Entwurf muss deshalb die tatsächlichen Durchsetzungsmechanismen berücksichtigen.

Zugriff und Richtlinien ergänzen sich. Rollen legen fest, welche Aktionen eine Identität ausführen darf. Zusätzliche Richtlinien können Aktionen oder Ressourcenzustände weiter begrenzen. Für den Entwurf muss klar sein, welcher Mechanismus welche Vorgabe abdeckt [2][5].

Wo die Regulierung ins Spiel kommt

Prüfungen betrachten technische und organisatorische Nachweise. Eine Landing Zone kann belegen helfen, wie Cloud-Vorgaben umgesetzt und kontrolliert werden. Welche Anforderungen und Nachweise nötig sind, hängt vom jeweiligen Prüfungsumfang ab.

ISO/IEC 27001 verlangt ein Managementsystem für Informationssicherheit, einschließlich der Bewertung und Behandlung von Informationssicherheitsrisiken. Die Anforderungen sind allgemein gehalten und für Organisationen jeder Art und Größe gedacht [14].

NIST SP 800-53 ist ein Katalog von Sicherheits- und Datenschutz-Controls für Informationssysteme und Organisationen. Die Controls sind ausdrücklich anpassbar und als Teil eines organisationsweiten Risikomanagements gedacht [15].

Der Kriterienkatalog C5 des BSI beschreibt Mindestanforderungen für sicheres Cloud Computing und richtet sich an Anbieter, ihre Prüfer und ihre Kunden. Das BSI hält ausdrücklich fest, dass Kunden eine eigene Risikoeinschätzung vornehmen, den C5-Bericht des Anbieters anfordern und ihn jährlich erneut auswerten sollten [16].

Technisch abbildbare Anforderungen sollten zentral durchgesetzt und ihre Ergebnisse dokumentiert werden. Organisatorische Vorgaben, Verantwortlichkeiten und zusätzliche Nachweise bleiben Teil der Prüfung. Ein Policy-Bericht ersetzt deshalb keine vollständige Bewertung der Anforderungen [17].

Kernaussage

Eine Landing Zone verbindet klare Organisationsgrenzen, gemeinsame Dienste und überprüfbare Leitplanken mit einem standardisierten Bereitstellungsweg. Azure-Abonnement, AWS-Konto und STACKIT-Projekt übernehmen dabei ähnliche Aufgaben, sind aber nicht austauschbar. Code und Automatisierung helfen, den Entwurf konsistent weiterzuentwickeln.

Was Sie danach entscheiden können

  • Wonach Sie schneiden: je Anwendung, je Umgebung oder je Team, und welche dieser Grenzen zugleich die Abrechnungsgrenze ist.
  • Welche Regeln zentral vererbt gelten und welche davon eine Anlage ablehnen dürfen statt sie nur zu melden.
  • Ob Vorgaben zu Datenhaltung und Souveränität die Plattformwahl bestimmen oder erst nach der Auswahl geprüft werden.
  • Wer eine neue Einheit anlegt: ein automatisierter Weg oder ein Mensch mit einem Ticket.

Häufige Fragen

Ist eine Landing Zone dasselbe wie eine Azure Landing Zone?

Nein. Azure Landing Zone ist Microsofts Umsetzung des Konzepts, mit eigenen Begriffen und einer eigenen Referenzarchitektur [1]. Das Konzept selbst ist anbieterunabhängig; AWS und STACKIT lösen dieselbe Aufgabe mit anderen Konstrukten.

Brauchen wir das auch für eine einzige Anwendung?

Nicht jede Umgebung braucht den vollen Ausbau. Auch eine einzelne Anwendung benötigt klare Zuständigkeiten, passende Zugriffs- und Sicherheitsregeln sowie einen geregelten Betrieb. Schutzbedarf, Verfügbarkeitsziele und geplante Erweiterungen bestimmen die nötigen Bausteine.

Lässt sich eine Landing Zone über mehrere Anbieter hinweg gleich bauen?

Die Bausteine übertragen sich, die Begriffe und die Durchsetzung nicht. Management-Gruppe, Organizational Unit und Ordner ähneln sich, verhalten sich aber verschieden, etwa in der möglichen Tiefe. Wer beides betreibt, legt die Begriffe bewusst nebeneinander, statt sie gleichzusetzen.

Wann ist STACKIT die richtige Wahl?

Wenn eine Anforderung festlegt, wo Daten liegen und welchem Recht der Anbieter unterliegt. STACKIT nennt Rechenzentren in der EU und den Anbietersitz in Deutschland als Grundlage seiner Souveränitätsaussage [6] und betreibt Regionen in Deutschland und Österreich [7]. Wer weltweite Regionen oder eine bestimmte Nischenleistung eines Hyperscalers braucht, entscheidet anders.

Quellen

Weiterlesen

Cloud & Platform Azure Landing Zone: Bausteine, Entscheidungen, Fehler Grundlagen Was ist Infrastructure as Code? Cloud & Platform Terraform im Team: Zustand, Module, Review Leistung Cloud Engineering