--- title: Account Governance description: Definieren Sie Konten, Projektstruktur und Verantwortlichkeiten als organisatorische Steuerungsebene für Migration und Betrieb in STACKIT Landing Zones heute. sidebar: label: Account Governance order: 10 source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/landing-zones/account-governance/" source_file: "docs/de/migration/design-and-mobilize/landing-zones/account-governance.mdx" --- ## Zielbild Account Governance beschreibt, wie Teams, Umgebungen und Zuständigkeiten in der Cloud klar getrennt und steuerbar aufgebaut werden. Damit entsteht die organisatorische Steuerungsebene für Migrationswellen: wo Workloads betrieben werden, wem welcher Scope gehört und wie neue Projekte ohne Umgehung von Guardrails angebunden werden. ## Governance-Hierarchie ![Governance hierarchy from customer account and folders to projects, resources, and labels](../../../../migration/design-and-mobilize/landing-zones/files/stackit-governance-hierarchy.svg) ## Governance-Design und Delivery ### Kernbausteine der Governance - **Regions**: Die Regionenstrategie bestimmt Datenlokalität, Latenzprofil und Resilienzgrenzen für Workloads und Shared Services. Definieren Sie früh verbindliche Nutzungsmuster und stimmen Sie diese mit Compliance- und Kontinuitätsanforderungen ab. Dokumentation - **Customer Account**: Der Customer Account ist die oberste Governance-Grenze für Ownership, Abrechnung und Administration. Er bildet den Anker für organisationsweite Standards und Kontrollverantwortung. Dokumentation - **STACKIT Folder**: Folder strukturieren organisatorische Domänen (zum Beispiel Plattform, Shared Services, Business Units, Umgebungen) und ermöglichen Policy-Vererbung sowie klare Delegationsmodelle. Dokumentation - **STACKIT Projects**: Projects sind die Delivery-Scopes, in denen Ressourcen bereitgestellt und betrieben werden. Sie sollten über ein definiertes Onboarding-Modell an Folder angebunden werden und nicht ad hoc entstehen. Dokumentation ### Wie die Bausteine zusammenspielen - **Regionprinzipien zuerst**: Legen Sie fest, welche Regionen für welche Workload-Klassen zulässig sind. - **Customer Account als Governance-Root**: Verankern Sie globale Ownership, Policy-Absicht und finanzielle Verantwortlichkeit. - **Folder für Struktur und Delegation**: Überführen Sie das Betriebsmodell in skalierbare organisatorische Grenzen. - **Projects für Delivery**: Stellen Sie Projektscopes über einen standardisierten Lebenszyklus mit verpflichtenden, vom Folder geerbten Kontrollen bereit. ### Wichtige Entscheidungen - **Region-Governance-Modell**: Entscheiden Sie zwischen Single-Region-, Dual-Region- oder Workload-basiertem Regionenansatz inklusive Ausnahmen. - **Customer-Account-Verantwortung**: Definieren Sie, welche zentralen Teams Governance, Billing-Transparenz und Kontrollbetrieb verantworten. - **Folder-Topologie**: Legen Sie fest, wie Folder auf Domänen wie Plattform, Umgebungen und Business Units abgebildet werden. - **Project-Onboarding-Modell**: Standardisieren Sie Projekterstellung, Namenskonventionen, Tagging und Lebenszyklus-Kontrollen. - **Policies und Ausnahmen**: Definieren Sie verpflichtende Guardrails und transparente Ausnahmeprozesse. ### Typische Ergebnisse - **Governance-Blueprint**: Customer-Account-, Folder- und Project-Topologie mit Verantwortungsmatrix. - **Regionen-Nutzungsrichtlinie**: Freigegebene Regionenmuster je Workload-Typ und Risikoprofil. - **Project-Onboarding-Standard**: Wiederholbarer Prozess für die Erstellung und Anbindung gesteuerter Projekte. - **Control-Baseline**: Erzwungene Namens-, Tagging- und Policy-Kontrollen mit dokumentiertem Ausnahmefluss. ### Typische Anti-Patterns - **Keine Regionenrichtlinie**: Regionauswahl pro Team oder Projekt ohne unternehmensweite Leitplanken. - **Unstrukturierte Project-Sprawl**: Projekte entstehen ohne Folder-Strategie, klare Ownership oder Lebenszyklusstandards. - **Governance nur auf Papier**: Kontrollen sind dokumentiert, aber nicht im Projekt-Onboarding und Betrieb verankert.