Multi-Account-Strategie auf AWS: Governance richtig aufsetzen

Warum Multi-Account-Strategien jetzt entscheidend sind

Der Trend ist eindeutig: Laut AWS Enterprise Strategy betreiben 90 % der Enterprise-Kunden mit signifikanter AWS-Nutzung bereits mehr als einen Account — viele jedoch ohne kohärente Strategie. Das Ergebnis: organisch gewachsene Strukturen, unklare Kostenverantwortung und Guardrail-Lücken, die erst bei Compliance-Audits oder Sicherheitsvorfällen sichtbar werden.

Für DACH-Unternehmen verschärfen sich die Anforderungen zusätzlich: DSGVO-Datentrennung, BSI-Grundschutz-Konformität und die NIS2-Richtlinie fordern nachweisbare Isolierung sensibler Workloads. Eine Multi-Account-Architektur ist dabei kein Selbstzweck — sie ist das technische Mittel, um Governance auf Account-Ebene durchzusetzen, anstatt auf manuelle Prozesse und individuelle IAM-Policy-Pflege angewiesen zu sein.

Gleichzeitig steigt der Kostendruck: Ohne konsolidierte Abrechnung über AWS Organizations fehlen die Grundlagen für FinOps. Cost-Allocation-Tags und Service-Quotas lassen sich auf Organisationsebene zentral verwalten und durchsetzen — eine Voraussetzung für skalierbare Cloud-Governance.

Begriffsklärung: Das Vokabular der Multi-Account-Governance

Bevor die Architektur diskutiert werden kann, müssen die zentralen Begriffe klar sein:

Organizational Unit (OU)

Eine logische Gruppe von AWS-Accounts innerhalb von AWS Organizations. OUs bilden eine Baumstruktur unter dem Management Account. Service Control Policies, die einer OU zugewiesen werden, gelten für alle Accounts in dieser OU und allen untergeordneten OUs.

Service Control Policy (SCP)

Eine AWS-Organizations-Policy, die die maximal möglichen Berechtigungen für Accounts oder OUs definiert. SCPs sind keine Gewährungs-Policies — sie schränken den erlaubten Handlungsspielraum ein. IAM-Policies innerhalb eines Accounts müssen zusätzlich explizit erlauben, was die SCP zulässt. SCPs gelten nicht für den Management Account.

Guardrail

Im Kontext von AWS Control Tower: eine vorkonfigurierte Governance-Regel. Guardrails sind entweder präventiv (blockieren nicht-konforme Aktionen, implementiert als SCPs) oder detektiv (erkennen und melden nicht-konformen Zustand, implementiert als AWS Config-Regeln). Control Tower unterscheidet zwischen obligatorischen, stark empfohlenen und optionalen Guardrails.

Account Vending

Der automatisierte Prozess zur Bereitstellung neuer AWS-Accounts nach einem definierten Template. Ein Account-Vending-Mechanismus (AVM) stellt sicher, dass jeder neue Account sofort mit den richtigen Baseline-Konfigurationen, SCPs, Logging-Hooks und SSO-Zuweisungen provisioniert wird — ohne manuellen Eingriff. AWS Control Tower's Account Factory ist die native Implementierung.

Landing Zone

Eine vorkonfigurierte, sichere Multi-Account-AWS-Umgebung, die auf Best Practices basiert. Eine Landing Zone definiert Account-Struktur, Netzwerk-Design (Transit Gateway, VPC-Sharing), zentrale Logging- und Audit-Accounts sowie Guardrails. AWS Control Tower liefert eine opinionierte Landing Zone; Teams können auch eigene Implementierungen via AWS Landing Zone Accelerator aufbauen.

AWS Organizations und AWS Control Tower im Detail

AWS Organizations (AWS Dokumentation) ist die Grundlage jeder Multi-Account-Strategie. Es ermöglicht:

• Konsolidierte Abrechnung: Alle Accounts einer Organisation werden über den Management Account abgerechnet. Reserved-Instance- und Savings-Plan-Rabatte werden automatisch auf alle Accounts in der Organisation angewendet.
• Service Control Policies (SCPs): Policies, die auf OU- oder Account-Ebene angewendet werden und den Berechtigungsrahmen definieren.
• Delegierte Administration: Bestimmte AWS-Services (z. B. Security Hub, GuardDuty, AWS Config) können einem dedizierten Administrations-Account delegiert werden, ohne den Management Account für operative Aufgaben zu nutzen.
• Account Factory: Automated Account Provisioning via AWS Service Catalog oder Control Tower.

AWS Control Tower baut auf Organizations auf und liefert eine Implementierungsschicht mit folgenden Kernkomponenten:

Ein wichtiger Punkt für bestehende AWS-Kunden: Control Tower kann auf bestehende Organizations-Strukturen aufgesetzt werden (Enrollment bestehender Accounts). Dieser Prozess erfordert jedoch sorgfältige Planung, da Account-Enrollment Guardrails aktiviert und bestehende Konfigurationen überschreiben kann (AWS Control Tower: Bestehende Accounts enrollen).

OU-Design für DACH-Enterprises

Das OU-Design ist die wichtigste architektonische Entscheidung in einer Multi-Account-Strategie. OUs sollten primär nach Governance-Anforderungen strukturiert werden — nicht nach Organisationsstrukturen oder Kostenstellen. Der Grundsatz: Accounts in derselben OU teilen dieselben SCPs und Guardrails.

AWS empfiehlt folgende Basis-OU-Struktur (AWS Whitepaper: Organizing Your AWS Environment):

Für DACH-Enterprises mit regulierten Workloads empfiehlt Storm Reply zusätzliche OUs:

• OU: Regulated — Accounts für DSGVO-sensible Verarbeitungen oder BSI-Grundschutz-relevante Systeme. Eigene SCPs, die die Nutzung auf EU-Regionen beschränken und bestimmte Datentransfer-Dienste blockieren.
• OU: Transitioning — Accounts, die gerade aus einer Legacy-Struktur in die neue OU-Architektur migriert werden. Temporäre OU mit definierten SLAs für die Migration.

Guardrails und Service Control Policies

Guardrails und SCPs sind das Herz der Governance-Architektur. Sie definieren, was in Accounts erlaubt und was verboten ist — präventiv und detektiv.

Präventive Guardrails (SCPs)

Wichtige SCPs für DACH-Enterprises umfassen:

1. Region-Einschränkung: Erlaubt nur AWS-Regionen innerhalb der EU (eu-central-1, eu-west-1, eu-north-1 etc.). Verhindert versehentliche Ressourcen-Erstellung in nicht-europäischen Regionen — wichtig für DSGVO-Konformität.
2. Root-Nutzung blockieren: Verhindert die Nutzung des Root-Users in Member-Accounts. Alle Aktionen müssen über IAM Identity Center (SSO) erfolgen.
3. CloudTrail deaktivieren blockieren: Stellt sicher, dass Audit-Logging in keinem Account deaktiviert werden kann — grundlegende Anforderung für BSI-Grundschutz und NIS2.
4. S3-Public-Access blockieren: Verhindert die Aktivierung von öffentlichem S3-Zugriff auf Organisations-Ebene.
5. Service-Einschränkungen für Sandbox-OUs: Blockiert produktionskritische Services (z. B. Route53 privates Hosted Zone Creation) in Entwicklungsumgebungen.
6. Billing-Alerts erzwingen: Jeder neue Account muss Budget-Alerts konfiguriert haben.

Detektive Guardrails (AWS Config)

Detektive Guardrails prüfen den aktuellen Zustand und melden Abweichungen. Control Tower liefert über 65 vorkonfigurierte detektive Guardrails (AWS Control Tower Controls Reference). Kritische Beispiele:

• MFA für alle IAM-Nutzer erzwungen
• Keine nicht-verschlüsselten EBS-Volumes
• VPC Flow Logs aktiviert
• Security Hub aktiv in allen Accounts
• GuardDuty aktiviert und zentralisiert

SCP-Architektur: Deny-Listen vs. Allow-Listen

Es gibt zwei grundlegende Ansätze:

• Deny-Liste: Alle Services erlaubt, spezifische Services blockiert. Flexibler, aber höheres Risiko, dass neue Services versehentlich erlaubt sind.
• Allow-Liste: Nur explizit erlaubte Services und Aktionen sind nutzbar. Rigoroser, erfordert mehr Pflege, aber deutlich sicherer für regulierte Umgebungen.

Storm Reply empfiehlt für regulierte OUs (Prod, Regulated) einen Allow-Listen-Ansatz und für Non-Prod-OUs einen Deny-Listen-Ansatz — kombiniert mit regelmäßigen SCP-Reviews als Teil der Storm Roadmap.

Account-Vending automatisieren

Manuell provisionierte Accounts sind ein Anti-Pattern: Sie sind fehleranfällig, inkonsistent und skalieren nicht. Ein automatisierter Account-Vending-Mechanismus (AVM) stellt sicher, dass jeder neue Account sofort compliant und betriebsbereit ist.

AWS Control Tower Account Factory

Control Tower's Account Factory (AWS Dokumentation) bietet:

1. Account-Provisionierung über AWS Service Catalog — Self-Service für autorisierte Nutzer
2. Automatische Zuweisung zur richtigen OU
3. Baseline-Guardrails sofort aktiv nach Account-Erstellung
4. IAM Identity Center Zuweisung für sofortigen SSO-Zugriff
5. Standardisiertes VPC-Setup optional (Account Factory Customization)

Account Factory for Terraform (AFT)

Für Teams, die Infrastructure-as-Code bevorzugen, ist Account Factory for Terraform (AFT) die empfohlene Lösung. AFT ermöglicht Account-Provisioning via Terraform-Pipelines — inklusive Account-spezifischer Customizations, globaler Customizations für alle Accounts und Account-spezifischer Provisioning-Schritte. Dies integriert sich nahtlos in bestehende GitOps-Workflows.

Pflichtbestandteile jedes neuen Accounts

Unabhängig vom gewählten AVM sollte jeder neue Account automatisch folgende Baseline erhalten:

• CloudTrail aktiviert und Logs in den zentralen Log-Archive-Account geschrieben
• AWS Config aktiviert und Aggregator konfiguriert
• Security Hub enrollt (delegierter Admin)
• GuardDuty enrollt (delegierter Admin)
• Budget-Alert auf dem definierten Schwellenwert
• IAM Password Policy gemäß Unternehmensstandard
• Root MFA erzwungen (via SCP)
• Standardisierte Tags (CostCenter, Environment, Owner, Project)

Storm Reply Perspektive: Multi-Account als Bestandteil der Storm Roadmap

Eine Multi-Account-Strategie ist keine einmalige Implementierung — sie ist ein kontinuierliches Governance-Programm. Bei Storm Reply ist das Multi-Account-Design deshalb fester Bestandteil der Storm Roadmap: ein strukturierter Plan, der technische Schulden systematisch adressiert und die Account-Governance mit der Unternehmens-Wachstumsstrategie synchronisiert.

Der typische Storm-Roadmap-Einstieg für Multi-Account-Governance umfasst:

1. Assessment (Woche 1–2): Inventur der bestehenden Account-Struktur, IAM-Policies, Tagging-Zustands und Compliance-Lücken. Einordnung nach OU-Kategorien.
2. OU-Design-Workshop (Woche 2–3): Gemeinsame Definition der OU-Hierarchie, SCP-Strategie und Guardrail-Auswahl. Abstimmung mit Security, Compliance und FinOps.
3. Pilot-Rollout (Woche 4–6): Control-Tower-Setup oder Organizations-Härtung auf einem nicht-produktiven Account-Segment. Validierung der Guardrails und Account-Factory-Templates.
4. Schrittweises Enrollment (Monat 2–4): Einbindung bestehender Accounts in die neue Struktur — priorisiert nach Risikoklasse. Sandbox und Non-Prod zuerst, dann Prod.
5. Kontinuierliches Governance-Review: Quarterly SCP-Reviews, Guardrail-Updates bei neuen AWS-Services und Compliance-Anforderungen. Integration in das FinOps-Programm.

Storm Reply ist AWS Premier Consulting Partner DACH mit AWS Migration Competency und Cloud Operations Competency — und bringt über 15 Jahre AWS-Erfahrung in Multi-Account-Architekturen für DACH-Enterprises mit.

Regulatorische Aspekte: DSGVO, BSI Grundschutz und NIS2

Für DACH-Enterprises ist eine Multi-Account-Strategie nicht nur eine technische Best Practice — sie ist oft eine regulatorische Notwendigkeit.

DSGVO und Datentrennung

Die DSGVO schreibt keine spezifische technische Architektur vor, aber der Grundsatz der Datensicherheit (Art. 32 DSGVO) und das Privacy-by-Design-Prinzip (Art. 25 DSGVO) fordern angemessene technische Maßnahmen. Account-Isolation stellt sicher, dass personenbezogene Daten aus einem System nicht versehentlich mit anderen Systemen interagieren können. SCPs, die die Datenverarbeitung auf EU-Regionen beschränken, sind ein direktes technisches Mittel zur DSGVO-Compliance.

BSI IT-Grundschutz

Der BSI IT-Grundschutz (Bausteine OPS.1.2.6 für Cloud-Nutzung und CON.1 für Kryptokonzept) empfiehlt klare Mandantentrennung und nachvollziehbares Logging. Eine Multi-Account-Architektur mit zentralem Log-Archive-Account und unveränderlichem Audit-Trail erfüllt diese Anforderungen strukturell. Control Tower's obligatorische Guardrails — insbesondere das Blockieren der CloudTrail-Deaktivierung — sind direkt auf BSI-Anforderungen abbildbar.

NIS2-Richtlinie

Die NIS2-Richtlinie (EU 2022/2555), in Deutschland durch das NIS2UmsuCG umgesetzt, fordert von kritischen und wichtigen Einrichtungen Maßnahmen zur Netzwerk- und Informationssicherheit — darunter Zugangskontrollen, Incident-Response und Monitoring. Eine Multi-Account-Strategie mit segregierten Netzwerken, zentralem Security Hub und GuardDuty bildet die technische Grundlage für NIS2-konforme Cloud-Operationen. Besonders relevant: die Account-Isolation verhindert laterale Bewegungen bei einem Sicherheitsvorfall und begrenzt den Blast-Radius.

Vorteile und Herausforderungen im Überblick

Häufig gestellte Fragen (FAQ)

Wie viele AWS-Accounts braucht ein mittelständisches Unternehmen?

Ein typisches DACH-Mittelstandsunternehmen startet mit 6–12 Accounts: Management-Account, Log-Archive, Audit, Shared-Services, sowie je einem Workload-Account pro Umgebung (Dev/Test/Prod) für die ersten 2–3 Applikationen. Mit wachsender Cloud-Reife und weiteren Workloads skaliert die Account-Anzahl auf 20–50+. Die richtige Granularität hängt vom Blast-Radius, von Compliance-Anforderungen und von Team-Ownership ab.

Was ist der Unterschied zwischen AWS Organizations und AWS Control Tower?

AWS Organizations ist die Grundlage: Sie verwaltet die Account-Hierarchie (Management Account, OUs, Member Accounts) und ermöglicht konsolidierte Abrechnung sowie Service Control Policies. AWS Control Tower baut darauf auf und liefert eine opinionierte Landing-Zone-Implementierung — inklusive vorkonfigurierter Guardrails, Account Factory und einem Dashboard zur Compliance-Übersicht. Organizations ist die Pflicht, Control Tower ist die empfohlene Umsetzungsschicht.

Können SCPs bestehende IAM-Policies aufheben?

Nein. Service Control Policies definieren die maximale Berechtigungsgrenze (Permission Boundary) für Accounts und OUs. Eine SCP kann keine Berechtigungen gewähren — sie kann nur den Umfang einschränken, der durch IAM-Policies innerhalb des Accounts erlaubt wird. Wenn eine IAM-Policy eine Aktion erlaubt, die SCP aber dieselbe Aktion blockiert, wird die Aktion verweigert. SCPs gelten nicht für den Management-Account.

Wie lange dauert die Einrichtung einer AWS Landing Zone mit Control Tower?

Eine initiale Control-Tower-Landing-Zone für ein Greenfield-Szenario kann in 1–2 Tagen technisch aufgesetzt werden. Für Enterprises mit bestehenden Accounts, eigenen Tagging-Richtlinien, SSO-Integration und regulatorischen Anforderungen (DSGVO, BSI, NIS2) sind 4–8 Wochen für Design, Rollout und Validierung realistisch. Storm Reply empfiehlt, zunächst einen OU-Design-Workshop durchzuführen, bevor Control Tower provisioniert wird.

Quellen und weiterführende Ressourcen

• AWS Organizations: Einführung und Konzepte (AWS Dokumentation)
• AWS Control Tower: Was ist Control Tower? (AWS Dokumentation)
• AWS Whitepaper: Organizing Your AWS Environment Using Multiple Accounts
• AWS Control Tower: Controls Reference (Guardrails)
• AWS Control Tower: Account Factory for Terraform (AFT)
• BSI IT-Grundschutz (Bundesamt für Sicherheit in der Informationstechnik)
• NIS2-Richtlinie (EU 2022/2555) im EU-Amtsblatt