Landing Zone & Topologie

Eine Landing Zone ist mehr als ein vorbereitetes Netzwerk

Landing Zone — Eine vorbereitete Cloud-Umgebung mit Ressourcenhierarchie, Identitätsanschluss, Richtlinien, Protokollierung, Netzgrundlage, Kostenzuordnung und einem wiederholbaren Weg, neue Workload-Bereiche bereitzustellen.

Microsoft trennt eine zentrale Platform Landing Zone von Application Landing Zones, in denen Workloadteams ihre Ressourcen betreiben. AWS beschreibt seine Landing Zone als organisationsweiten Multi-Account-Rahmen; Google führt die Ressourcenkette von Organisation über Folder zu Project. Die Namen unterscheiden sich, der Betriebszweck ist ähnlich: Neue Workloads sollen nicht jedes Mal Identität, Audit, Netzanschluss und Governance neu erfinden.

Drei Anbieter, dieselbe Entwurfsfrage

AWS

Organization → Organizational Unit → Account → Ressource

Azure

Tenant Root → Management Group → Subscription → Resource Group → Ressource

Google Cloud

Organization → Folder → Project → Ressource

Gemeinsame Frage

An welcher Ebene werden Richtlinie, Ownership, Kosten, Quota und Ausfallwirkung sinnvoll gebündelt?

Diese Zeilen sind keine Gleichsetzung. Ein AWS Account, eine Azure Subscription und ein Google-Cloud-Project haben unterschiedliche Diensteigenschaften, Limits und Sicherheitsdetails. Für die Topologieentscheidung sind sie dennoch vergleichbare Managementcontainer: In ihnen liegen Workloadressourcen, Berechtigungen, Abrechnungssignale und viele dienstbezogene Kontingente. Die konkrete Dokumentation des gewählten Providers entscheidet, welche Grenze tatsächlich wirksam ist.

• Die oberste Organisation bindet zentrale Verwaltung und organisationsweite Richtlinien.
• Zwischenebenen gruppieren Container mit gemeinsamen Kontrollen.
• Workloadcontainer begrenzen tägliche Administration, Kostenansicht und viele Änderungen.
• Regionen und Availability Zones sind Fehlerdomänen, aber keine Ersatzhierarchie.
• Tags oder Labels helfen beim Suchen und Zuordnen, ersetzen jedoch keine harte Verwaltungsgrenze.

Auch die obersten Verwaltungskonten sind Sonderfälle. AWS weist darauf hin, dass SCPs Principals im Management Account nicht beschränken. Deshalb gehört dort im Regelfall kein gewöhnlicher Workload hin; der Account dient den wenigen Organisationsaufgaben, die nur dort möglich sind. Vergleichbare Root- oder Tenant-Ebenen verdienen getrennte privilegierte Identitäten, minimale tägliche Nutzung und eine Auditspur. Eine Policy oberhalb aller Workloads schützt nicht automatisch die Stelle, von der diese Policy verwaltet wird.

Nach Kontrollen schneiden, nicht nach Organigramm

AWS empfiehlt OUs nach Funktion oder gemeinsamem Kontrollsatz statt als Kopie der Berichtslinien. Microsoft rät ebenfalls von einer tiefen Abbildung der Organisation ab und sieht Management Groups vor allem als Ebene für gemeinsame Policy. Ein Organigramm ändert sich aus Personalgründen; eine Cloudhierarchie ändert den wirksamen Steuerungskontext. Werden beide gekoppelt, wird jede Reorganisation zu einem Infrastruktur-Change.

Gemeinsame regulatorische Vorgabe

Guter Grund für eine gemeinsame Policy-Ebene.

Gleiches Konnektivitätsmodell

Kann eine Produktlinie wie intern, online oder isoliert rechtfertigen.

Gemeinsamer Lebenszyklus

Produktion, Sandbox und stillgelegte Container brauchen oft verschiedene Kontrollen.

Abteilungsname

Nur tragfähig, wenn daraus dauerhaft ein eigener Kontroll- oder Verantwortungsvertrag folgt.

Region

Meist Eigenschaft der Ressourcen; nur bei eigenständigen Standortvorgaben eine Hierarchieachse.

Lege die Entscheidung als kleine Tabelle im Topologie-Repository ab: Pfad, Kontrollsatz, delegierter Owner, erlaubte Workloadtypen und Exitbedingung. Dann lässt sich eine neue Anforderung gegen vorhandene Ebenen prüfen, bevor jemand einen weiteren Zweig erzeugt. Fehlt etwa nur eine andere Kostenansicht, können Tags oder Billing-Zuordnungen genügen. Braucht ein regulierter Workload dagegen andere Standortregeln und eine getrennte Administration, trägt eine eigene Policy-Ebene wahrscheinlich mehr als ein Label.

Der Workloadcontainer begrenzt mehrere Wirkungen zugleich

Ein eigener Account, eine Subscription oder ein Project kann tägliche Rechte, Budgetdaten, dienstbezogene Quotas und den Umfang vieler Fehlkonfigurationen trennen. Diese Grenze ist stark, aber nicht absolut. Ein gemeinsam genutztes Netzwerk, ein zentraler Identity Provider, eine organisationsweite Fehlpolicy oder ein übergreifender Schlüsselpfad kann mehrere Container gleichzeitig betreffen. Der Entwurf muss deshalb sowohl den Container als auch seine geteilten Abhängigkeiten nennen.

Die Zahl der Container ist trotzdem kein Reifegrad. Mehr Accounts oder Subscriptions erzeugen Grundkosten, Inventar, Rollenbindungen, Limits und zusätzliche Stellen für Fehlkonfiguration. Zu wenige Container koppeln dagegen Rechte und Änderungen. Die richtige Einheit entsteht aus einer benannten Trennanforderung: eigener Owner, eigener Kontrollsatz, eigener Lebenszyklus oder eine Wirkung, die andere Workloads nicht treffen darf. Fehlt dieser Grund, ist eine zusätzliche Grenze wahrscheinlich nur Verwaltungsarbeit.

Platform und Workload Landing Zones haben verschiedene Owner

Die Platform Landing Zone trägt Fähigkeiten, die viele Workloads benötigen: etwa zentrale Audit-Senken, Sicherheitsdienste, Konnektivität, Identity-Anbindung und die Hierarchie selbst. Application beziehungsweise Workload Landing Zones enthalten die Ressourcen eines Dienstes und seiner Umgebungen. Microsoft betont, dass Workloadteams diese Bereiche innerhalb der zentralen Guardrails betreiben.

Plattformbereich

Hierarchie, zentrale Policy, Logging-Ziel, gemeinsames Netz, Identity-Anschluss, Vending-Automation

Workloadbereich

Anwendungsressourcen, workloadbezogene Rollen, Daten, Skalierung, Dienstkonfiguration und Betriebsbereitschaft

Übergabe

Container-ID, Parent, Baselineversion, Owner, Kostenstelle, Netzprodukt und Nachweisstatus

Geteilte Abhängigkeit

Mit eigenem Owner und Ausfallvertrag behandeln; nicht stillschweigend zwischen den Zeilen verstecken.

Zentralisierung ist kein Selbstzweck. Microsoft empfiehlt, nur Fähigkeiten zu zentralisieren, die über mehrere Workloads einen klaren Governance-, Betriebs- oder Wirtschaftsvorteil liefern. Ein gemeinsamer Dienst senkt Doppelarbeit, vergrößert aber seinen Schadensradius und macht Kapazität, Recovery und Support zu Plattformpflichten.

Vererbung macht die Position wirksam

AWS-Policies, Azure Policy und Google-Cloud-Organisationseinstellungen können an höheren Hierarchieebenen wirken. Welche Regeln am Workload ankommen, hängt vom jeweiligen Policytyp und seiner Auswertungslogik ab. Bei Google Cloud werden Organization Policies an Nachfahren vererbt; Allow-Policies tieferer Ebenen sind additiv, Deny-Policies werden vor Allows ausgewertet. Bei Azure erben Subscriptions Policy- und RBAC-Zuweisungen ihrer Management Groups.

Das gilt auch für Ausnahmen. Eine Ausnahme an der falschen Ebene kann mehr Nachfahren treffen als beabsichtigt; eine lokale Freigabe kann an einer übergeordneten Deny-Regel wirkungslos bleiben. Deshalb gehören Zielpfad, erwartete effektive Änderung und Rückweg in jedes Policy-Review.

Dokumentiere dabei nicht nur einzelne Policy-Dateien, sondern ihre Herkunft. Ein Befund wie compute.locations blockiert die Bereitstellung hilft erst, wenn das Team erkennt, ob die Regel am Project, am Parent-Folder oder an der Organisation entsteht. Ein Topologieinventar sollte deshalb Parent-IDs, direkt gebundene Policies und den berechneten Effekt gemeinsam zeigen. So wird eine Ablehnung zur prüfbaren Kette statt zu einer Suche durch mehrere Portale.

Guardrail und Berechtigung sind nicht dasselbe

AWS dokumentiert für Service Control Policies eine häufig missverstandene Grenze: Ein SCP gewährt keine Berechtigung. Es setzt die maximal verfügbaren Rechte für Principals in Member Accounts; tatsächliche Rechte brauchen weiterhin Identity- oder Resource-Policies. Ein großzügiges SCP macht daher niemanden automatisch zum Administrator. Umgekehrt kann eine IAM-Allow-Regel eine vom SCP ausgeschlossene Aktion nicht wieder erlauben.

Guardrail

Begrenzt, was innerhalb eines Hierarchiezweigs maximal zulässig ist.

Rollenbindung

Gewährt einem Principal benannte Aktionen im erlaubten Rahmen.

Ressourcenpolicy

Regelt Zugriff aus Sicht einer Ressource nach der Providerlogik.

Effektive Berechtigung

Ergebnis der zutreffenden Policytypen, Bedingungen, Grenzen und expliziten Denies.

Gemeinsame Dienste verbinden getrennte Container

Eine saubere Hierarchie beseitigt keine Kopplung durch zentrale Dienste. Ein Transitnetz, ein DNS-Resolver, eine Logsenke oder ein Identity-Anschluss kann Hunderte Workloadcontainer bedienen. Der Vorteil ist ein einheitlicher Vertrag; der Preis ist ein großer Fehler- und Kapazitätsradius. Der Landing-Zone-Entwurf muss diese Dienste deshalb als eigene Plattformprodukte mit Owner, Quota, Signalen und Recoveryweg führen.

• Konnektivität: Wer darf einen Workload anschließen, und welche Routen werden dadurch geteilt?
• Namensauflösung: Welche Zonen und Resolver hängen am zentralen Pfad, und wie wird ein Ausfall erkannt?
• Audit: Kann ein Workload seine eigene Spur löschen, oder liegt sie in einem getrennt verwalteten Ziel?
• Identity: Welche Anmeldung und welche Notfallidentität funktionieren, wenn der normale Verbund gestört ist?
• Kosten und Quota: Welches Wachstum eines Mandanten kann den gemeinsamen Dienst sättigen?

Geteilte Dienste brauchen außerdem einen Anschlussvertrag. Ein Workload darf nicht durch eine manuell gesetzte Peering-Verbindung oder eine persönliche DNS-Freigabe dauerhaft von der Plattform abhängen. Die Landing-Zone-Ausgabe sollte Anschlusskennung, erlaubte Präfixe oder Namensräume, zuständige Plattformfähigkeit und Status nennen. Dadurch lässt sich beim Incident unterscheiden, ob der Workloadcontainer gesund ist und sein zentraler Anschluss fehlt oder ob die Störung innerhalb des Workloads liegt.

Umgebungen brauchen Isolation und gemeinsame Baselines

AWS empfiehlt getrennte Prod- und SDLC-Zweige, wenn ihre Policies verschieden sind, und verlangt, dass Nichtproduktion keine Produktionsabhängigkeiten besitzt. Microsoft empfiehlt häufig getrennte Subscriptions je Anwendungsumgebung, ordnet sie aber unter denselben archetypischen Management Groups ein, statt für Entwicklung, Test und Produktion eine parallele Management-Group-Hierarchie zu bauen. Die genaue Form ist provider- und workloadabhängig; die zwei Ziele bleiben stabil: Wirkung trennen und Baselines gemeinsam steuern.

Getrennter Container

Eigene Rollen, Quotas, Budgets und geringerer Radius versehentlicher Änderungen.

Gemeinsame Parent-Ebene

Gleiche grundlegende Policy für denselben Workloadtyp ohne Kopieren jeder Zuweisung.

Sandbox-Zweig

Experimentierraum mit begrenztem Netz, Budget und Datenzugriff; kein verstecktes Vorproduktionssystem.

Stilllegungs-Zweig

Zugriffe reduzieren und Aufbewahrung beziehungsweise Nachweise kontrollieren, bevor der Container endet.

Eine Sandbox außerhalb der Organisation wäre leichter frei zu halten, verliert aber zentrale Sicht und Guardrails. Ein besserer Entwurf lässt Experimente innerhalb der Organisation zu und beschränkt gezielt Daten, Konnektivität, Kosten und erlaubte Dienste. Freiheit entsteht durch eine passende Produktlinie, nicht durch Unsichtbarkeit.

Vending macht die Topologie wiederholbar

Vending — Der standardisierte Ablauf, über den ein Team einen Account, eine Subscription oder ein Project mit Parent, Baseline, Ownership und angebundenen Plattformdiensten erhält.

Azure beschreibt Subscription Vending als standardisierten Anforderungs-, Bereitstellungs- und Governanceprozess. AWS Control Tower bietet Account Factory und automatisierte Wege, die nach der Kontoerzeugung Blueprints und Controls anwenden. Der Produktname ist weniger wichtig als die Vollständigkeit: Ein leerer Container ist noch keine betriebsbereite Landing Zone.

Die Eingaben des Vending-Vertrags müssen fachliche Entscheidungen aufnehmen, keine Providerkonsole nachbauen. Ein Feld wie connectivityClass: internal kann eine geprüfte Kombination aus zentralem Transit, privater Namensauflösung und Egresskontrolle wählen. Die Plattform hält die konkrete Umsetzung dahinter. Gleichzeitig veröffentlicht sie, was die Klasse zusagt und nicht zusagt. Ohne diese sichtbare Semantik wird ein kurzer Produktname zur versteckten Architekturentscheidung.

Zu den Ausgaben gehören mindestens die unveränderliche Container-ID, der tatsächlich gesetzte Parent, die Baselineversion, Owner, Kostenstelle, verbundene Plattformprodukte und der Status der Abnahme. Anzeigenamen reichen nicht: Sie ändern sich und sind nicht zwingend eindeutig. Nachgelagerte IaC-Repositories und Auditabfragen müssen dieselbe stabile Kennung verwenden, damit Umbenennen oder Umhängen die Zurechnung nicht zerreißt.

Umhängen ist eine Policy- und Zugriffsänderung

Google warnt beim Verschieben eines Projects ausdrücklich vor den Folgen geänderter vererbter IAM- und Organization Policies; das dokumentierte Beispiel zeigt einen möglichen Dienstausfall durch verlorene geerbte Rechte. Azure weist ebenfalls darauf hin, dass eine verschobene Subscription Rechte und Policies des neuen Parents erbt. Ein Drag-and-drop in der Hierarchie ist deshalb ein produktiver Change, kein Aufräumen.

Der Rückweg eines Moves ist nicht bloß das Zurückschieben. Während der Zeit am Ziel können neue Ressourcen, Rollenbindungen oder Datenflüsse entstehen, die unter dem alten Parent nicht zulässig oder nicht erreichbar sind. Definiere deshalb vorab ein Zeitfenster, in dem keine unabhängigen Strukturänderungen stattfinden, und entscheide, welcher Zustand bei einem Abbruch erhalten bleiben darf. Nach dem Rückmove müssen dieselben positiven und negativen Proben erneut laufen; die sichtbare alte Position beweist nicht, dass alle Nebenwirkungen verschwunden sind.

Die Topologie wird am effektiven Zustand abgenommen

Ein Diagramm und ein erfolgreiches IaC-Apply belegen Absicht und Ausführung, nicht die vollständige Wirkung. Die Abnahme liest deshalb die Hierarchie vom Provider, prüft effektive Policies am Ziel, testet die zentrale Auditspur, kontrolliert Owner und Kostenstelle und führt einen erlaubten sowie einen verbotenen Beispielzugriff aus. Erst positive und negative Probe zeigen, ob Delegation und Guardrail gleichzeitig funktionieren.

• Parent und Container-ID entsprechen dem genehmigten Topologieplan.
• Effektive Policy enthält die erwarteten Baselines und keine unerklärte Ausnahme.
• Workloadrolle kann die benötigte Aktion ausführen, aber keine Plattformgrenze verändern.
• Auditereignis erreicht das getrennte zentrale Ziel und bleibt dem Vorgang zuordenbar.
• Budget, Quota-Owner und zentrale Abhängigkeiten sind auffindbar.
• Stilllegungs- und Move-Verfahren sind dokumentiert, bevor der erste Workload startet.

Die folgenden Übungen prüfen genau diese Kette: den ersten Schnitt, Platform gegen Workload, die Providerobjekte, ein vollständiges Vending-Request, die Wirkung eines Parent-Wechsels, Fehler in einem Topologieplan und die sichere Reihenfolge von der Anfrage bis zur Übergabe.