Landing Zone & Topologie

Konto, Subscription, Projekt — dieselbe Grenze

Jeder große Anbieter hat eine oberste Container-Ebene für Ressourcen: Konto, Subscription oder Projekt. Wie sie heißt, ist zweitrangig. Entscheidend ist, dass an dieser Grenze mehrere Dinge gleichzeitig enden — und dass sie deshalb keine Verwaltungsfrage ist, sondern die erste Architekturentscheidung einer Landing Zone.

Was an der Grenze endet	Warum das im Betrieb zählt
Rechte	Zugriff über die Grenze hinweg muss ausdrücklich eingeräumt werden. Ohne Freigabe sieht die eine Seite die andere nicht.
Kontingente und API-Ratenlimits	Sie werden in der Regel je Konto bzw. Projekt zugeteilt. Eine Lastspitze drosselt dann nur den eigenen Bereich.
Kostenzuordnung	Die Grenze ist die verlässlichste Kostenstelle. Tags verfeinern das, ersetzen es aber nicht.
Wirkung einer Fehlkonfiguration	Ein zu weites Recht oder ein Löschbefehl wirkt zuerst innerhalb der Grenze.
Nachweis	Wer darf was wird pro Grenze prüfbar, statt über tausende Einzelressourcen.

Woran du schneidest — und woran nicht

Blast Radius bedeutet hier: Wie weit reicht ein Zwischenfall, bevor eine Grenze ihn stoppt? Diese Frage entscheidest du vor dem Bauen, indem du die Topologie schneidest. Vier Kriterien tragen den Schnitt:

Datenklasse — personenbezogene, regulierte oder besonders schützenswerte Daten bekommen eine eigene Grenze, damit der Kreis der Zugriffsberechtigten klein und beweisbar bleibt.
Berechtigtenkreis — wenn Externe, ein anderes Team oder ein anderer Betriebsmodus Zugriff braucht, verläuft dort eine Grenze.
Ausfallradius — was gleichzeitig ausfallen darf, darf zusammenliegen. Was niemals gleichzeitig ausfallen darf, nicht.
Umgebung — Produktion und Nicht-Produktion haben andere Kontrollen und andere Lastprofile. Das ist in der Praxis der häufigste erste Schnitt.

Woran du nicht schneidest: am Organigramm. Die Landing-Zone-Leitfäden von AWS, Google Cloud und Microsoft raten davon ab, die Berichtsstruktur des Unternehmens unreflektiert in eine tiefe Ressourcenhierarchie zu kopieren, und empfehlen stattdessen einen Schnitt entlang gemeinsamer Sicherheits- und Betriebsanforderungen. Die betriebliche Begründung dahinter ist Erfahrungswissen, kein Zitat: Abteilungen werden umorganisiert, Fehler- und Rechtegrenzen nicht — und eine Abteilungsgrenze trennt Produktion und Test desselben Teams gerade nicht.

Zentrale Hierarchie, delegierter Rest

Über den Konten liegt eine Hierarchie aus Gruppierungsknoten — je nach Anbieter Organizational Unit, Ordner oder Management Group. Sie ist kein Ordnungsschema für Menschen, sondern der Ort, an dem Regeln vererbt werden: Was an einem Knoten gilt, gilt für alles darunter. Genau deshalb gehört an den Knoten nur, was zentral garantiert werden muss.

Zentral am Hierarchieknoten	Beim Team in der eigenen Grenze
Vererbte Guardrails: erlaubte Regionen, verbotene Konfigurationen, Pflichteinstellungen	Die Workload-Ressourcen selbst und ihre Konfiguration
Abrechnungs-Rollup und Budgetgrenzen über alle Konten hinweg	Kostenoptimierung innerhalb des eigenen Budgets
Zentrale, schreibgeschützte Ablage für Protokolle und Audit-Ereignisse	Anwendungslogs und deren Auswertung
Provisionierung neuer Grenzen samt Grundausstattung	Deployments und Rechtevergabe innerhalb der eigenen Grenze

Eine nachträgliche Umhängung — ein Konto wechselt den Elternknoten — ist ein einziger Verwaltungsschritt und trotzdem eine echte Änderung. Zwei Wirkungen musst du auseinanderhalten. Erstens: Die Guardrails des neuen Knotens werden auf jede weitere Anfrage angewandt, also auch auf Änderungen an bestehenden Ressourcen und nicht nur auf neu angelegte. Zweitens: Wo die Hierarchie zusätzlich Zugriffsrechte vererbt, entfallen die am alten Knoten gewährten Rechte mit ihm. Das gilt nicht überall — bei manchen Anbietern wirken Hierarchieknoten ausschließlich begrenzend und gewähren nie etwas. Kläre für deine Umgebung, welches der beiden Modelle greift; im Zweifel beide.

Vererbte Regeln des Zielknotens gegen den Ist-Zustand des Kontos prüfen
Abweichungen beheben oder befristet und sichtbar ausnehmen
Konto umhängen
Effektive Rechte und Regeln nach der Umhängung verifizieren

Gleich entscheidest du diese Achsen selbst

Entlang welcher Linie eine gewachsene Ein-Konto-Umgebung zuerst geschnitten wird.
Ob ein neues Produkt eine eigene Grenze bekommt oder eine bestehende mitnutzt.
Was in der zentralen Hierarchie bleibt und wie eine nachträgliche Umhängung sicher abläuft.

Alle drei Entscheidungen fallen, bevor gebaut wird. Wie du eine einzelne Änderung später im laufenden Betrieb eingrenzt, ist eine andere Achse — die kommt im Modul zur Change-Kontrolle.