---
title: "Cloud-Hierarchie: Struktur als Governance-Grundlage"
description: "Wie Hierarchy Nodes und Cloud Spaces eine skalierbare, governance-fähige Cloud-Plattform schaffen — und warum die richtige Hierarchie das Fundament für Richtlinien, Kosten und Berechtigungen ist."
sidebar:
order: 5
label: "Cloud-Hierarchie"
source_url: "https://framework.stackit.cloud/de/advisory/governance/cloud-hierarchy/"
source_file: "docs/de/advisory/governance/cloud-hierarchy.mdx"
---
## Warum Struktur vor Technologie steht
Viele Cloud-Einführungen beginnen mit der Frage: „Welche Services nutzen wir?“ Die wichtigere Frage lautet: „Wie strukturieren wir unsere Cloud-Umgebung, damit Governance skaliert?“
Eine Cloud-Hierarchie ist die Antwort auf diese Frage. Sie definiert, wie Richtlinien durchgesetzt, Kosten verteilt und Berechtigungen verwaltet werden — nicht für eine Umgebung, sondern konsistent über alle Umgebungen, unabhängig von Anbieter und Größe.
Das Kernprinzip: Governance-Anforderungen werden einmalig auf Hierarchieebene definiert und automatisch an alle untergeordneten Einheiten vererbt. Ohne diese Struktur müsste jede Sicherheitsrichtlinie, jede Kostenstellenzuordnung und jede Berechtigungsanforderung für jede Umgebung manuell konfiguriert werden — ein unlösbares Skalierungsproblem.
## Hierarchy Nodes: die logischen Gruppen
Hierarchy Nodes sind logische Gruppierungseinheiten, die Cloud Spaces strukturieren und zentral Richtlinien definieren. Fünf Standardknoten bilden das Gerüst einer durchdachten Plattformarchitektur:
Enthält alle zentral verwalteten Infrastruktur- und Plattformdienste. Hier werden globale
Anforderungen definiert: Sicherheit, Vernetzung, Protokollierung, Kostenmanagement. Streng
getrennt von Workloads — ausschließlich für plattformweite Funktionen.
Enthält alle Cloud Spaces, die Geschäftsanwendungen hosten, organisiert nach Umgebungstyp:
Produktion (höchste Anforderungen, eingeschränkter Zugriff) und Pre-Production (Entwicklung,
Test, Staging). Teams werden Spaces im Knoten Workload zugewiesen.
Eine isolierte Umgebung für Experimente, Tests und Technologiebewertungen. Die Richtlinien sind
absichtlich weniger restriktiv, damit Teams neue Technologien erforschen können, ohne
Produktionssysteme oder regulierte Umgebungen zu beeinträchtigen.
Dient der zentralen Auswertung und Validierung von Richtlinien. Compliance-Mechanismen werden
hier konsolidiert und unabhängig von produktiven Workloads betrieben — für isolierte
Richtlinienauswertung ohne operatives Risiko.
Besondere Erwähnung verdient der Knoten **Graveyard**, der jedoch in Konzepten kaum vorkommt: Es handelt sich hierbei um einen kontrollierten Abstellraum für stillgelegte Cloud Spaces. Ressourcen bleiben temporär erhalten, bevor sie endgültig entfernt werden. Dies ermöglicht eine nachvollziehbare Außerbetriebnahme und verhindert versehentliche Abhängigkeitsbrüche, die beim sofortigen Löschen unbemerkt bleiben würden.
## Cloud Spaces: die operative Einheit
Ein Cloud Space ist die kleinste administrative Einheit auf der Plattform. Er ist die Betriebsgrenze, innerhalb derer Ressourcen erstellt, Kosten erfasst und Berechtigungen zugewiesen werden.
Die technische Umsetzung ist anbieterspezifisch, die konzeptionelle Funktion bleibt jedoch identisch: Jeder Cloud Space hat genau einen verantwortlichen Eigentümer, ist genau einem Hierarchy Node zugeordnet und erbt automatisch dessen Richtlinien.
Diese Dreieinigkeit — Space als Kostenstelle, Berechtigungsgrenze und Richtlinienerbe zugleich — ist der Kern des Modells. Sie erlaubt es, auf Fragen wie „Wer hat das erstellt?“, „Welches Team wird dafür belastet?“ oder „Welche Regeln gelten hier?“ immer eine einheitliche Antwort zu erhalten.
Direkte Berechtigungszuweisungen an einzelne Identitäten sind innerhalb von Cloud Spaces nicht zulässig — sämtliche Zugriffe laufen über Gruppen. Damit ist sichergestellt, dass Onboarding und Offboarding automatisch ablaufen: Gruppe verlassen = Zugriff sofort entzogen.
## Richtlinien fließen nach unten
Das mächtigste Merkmal einer Hierarchiestruktur ist die Richtlinienvererbung. Eine auf einen Hierarchy Node angewendete Richtlinie gilt automatisch für alle darunter liegenden Cloud Spaces.
Das bedeutet: Die zentrale Anforderung, dass alle Ressourcen in bestimmten Regionen bereitgestellt werden müssen, muss nicht für jede der hundert Umgebungen einzeln konfiguriert werden. Sie wird einmalig am entsprechenden Knotenpunkt definiert — und gilt überall darunter.
Dies funktioniert hierarchisch: Je weiter oben eine Richtlinie definiert ist, desto mehr Einheiten sind davon betroffen. Dies ermöglicht eine fein abgestufte Governance: globale Anforderungen an der Spitze, umgebungsspezifische Anforderungen in Unterknoten.
## Einführung in der richtigen Reihenfolge
1. **Hierarchiestruktur entwerfen:** Welche Knotenpunkte benötigt die Organisation? Die fünf Standardknoten sind ein guter Ausgangspunkt — aber jede Organisation hat spezifische Anforderungen, die die Struktur beeinflussen. Dieser Schritt geschieht auf einem Whiteboard, nicht in der Konsole.
2. **Richtlinien pro Knoten definieren:** Welche Anforderungen gelten für welchen Knoten? Beginnen Sie mit den globalen (gilt für alle Spaces), dann den knotenspezifischen. Sicherheit, Kosten, Namenskonventionen — alles, was durchgängig gelten soll.
3. **Cloud-Space-Standard definieren:** Wie sieht ein neu erstellter Cloud Space aus? Welche Tags, welche Default-Gruppen, welcher Budget-Alarm? Ein reproduzierbarer Space-Standard verhindert, dass jede Umgebung anders konfiguriert wird.
4. **Bestehende Umgebungen klassifizieren:** Was existiert bereits? Wie fügt es sich in die neue Hierarchie ein? Diese Bestandsaufnahme ist oft mühsam, bildet aber die Grundlage für die Governance über den Bestand.
5. **Graveyard-Prozess definieren:** Wie werden Cloud Spaces stillgelegt? Wer gibt frei, wer führt durch, wie lange ist die Aufbewahrungsfrist? Ein undefinierter Prozess führt zu ungenutzten, abrechenbaren Umgebungen.
Die technische Umsetzung der Hierarchiestruktur ist anbieterspezifisch, das konzeptionelle Modell bleibt jedoch konsistent. Details zur Landing Zone als technische Umsetzung befinden sich in **[Landing Zone](/de/adoption/landing-zone/)**.