# Landing Zone & Topologie

> Konten-, Subscription- und Projektstruktur als Blast-Radius-Entscheidung schneiden.

Track: [Cloud Infrastructure & Platform Engineering](https://opsmith.app/learn/cloud-infra)  
Kanonische Fassung: https://opsmith.app/learn/cloud-infra/landing-zone-topology  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Die Grenze, bevor du baust

### 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. |

> **Merksatz:** Namenspräfixe und Tags ordnen, sie isolieren nicht. Feine Rollen innerhalb einer Grenze können Zugriff einschränken — Kontingente, Kostenzuordnung und den Radius einer Fehlkonfiguration teilen sie trotzdem weiter.

### 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.

> **Trade-off:** Mehr Grenzen sind nicht automatisch besser. Jede zusätzliche Grenze kostet Provisionierung, Netzanbindung, Zugriffspflege und Kostenzuordnung. Ziehe eine, wenn sich mindestens eines der vier Kriterien unterscheidet — nicht auf Vorrat. Umgekehrt gilt: Grenzen sind asymmetrisch teuer. Vorher gezogen kosten sie Provisionierung, nachträglich gezogen kosten sie eine Datenmigration.

### 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 |

> **Faustregel:** Zentral gehört, was ein einzelnes Team nicht für sich allein entscheiden darf und was als Nachweis über alle Konten hinweg gelten muss. Alles andere gehört ins Team, sonst wird die Plattform zum Ticket-Engpass. Und halte den Baum flach: Je tiefer die Hierarchie, desto schwerer ist die effektiv geltende Regelmenge nachvollziehbar.

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.

> **Kein Sicherheitsnetz:** Wie schnell eine Umhängung an allen Stellen wirksam ist, hängt vom Anbieter ab und ist nicht garantiert unmittelbar. Plane deshalb keinen Schritt so, dass er auf eine Verzögerung angewiesen ist — und verlass dich umgekehrt nicht darauf, dass eine Änderung schon überall angekommen ist, bevor du sie geprüft hast.

**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.

## Quellen

- AWS: Organizing Your AWS Environment Using Multiple Accounts (Benefits of using multiple AWS accounts, Design principles) — https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html
- Google Cloud Architecture Center: Decide a resource hierarchy for your Google Cloud landing zone — https://docs.cloud.google.com/architecture/landing-zones/decide-resource-hierarchy
- Microsoft Cloud Adoption Framework: Management groups (Resource organization design area) — https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups
- AWS: Benefits of using multiple AWS accounts — Limit scope of impact from adverse events, Distribute AWS Service Quotas and API request rate limits — https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html
- Microsoft Cloud Adoption Framework: Subscriptions als Verwaltungs-, Richtlinien- und Skalierungsgrenze — https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions
- Google Cloud Resource Manager: Migrate projects — am alten Elternknoten gewährte Rollen entfallen, Organisationsrichtlinien des Ziels ersetzen die des Ursprungs — https://docs.cloud.google.com/resource-manager/docs/project-migration