Oliver Bühler

AWS Landing Zone: Multi-Account-Strategie für Enterprise-Umgebungen

3 Min. Lesezeit
#aws#landing-zone#control-tower#organizations

Warum eine Multi-Account-Strategie unverzichtbar ist

Eine einzelne AWS-Umgebung für alle Workloads zu nutzen ist verlockend einfach — bis die ersten Compliance-Anforderungen kommen, ein Team versehentlich Produktionsdaten überschreibt oder die Kostenabrechnung zur Detektivarbeit wird. Eine durchdachte Multi-Account-Strategie löst diese Probleme strukturell, bevor sie entstehen.

In meiner Arbeit bei T-Systems habe ich eine Landing Zone für rund 2.000 AWS-Accounts über 40 AWS Organizations hinweg aufgebaut und betrieben. Die Erkenntnisse aus diesem Projekt fließen direkt in diesen Artikel ein.

Die Grundbausteine: Control Tower und Organizations

AWS Control Tower ist der verwaltete Service für Landing Zones. Er orchestriert AWS Organizations, AWS SSO (IAM Identity Center), AWS Config, CloudTrail und Service Control Policies (SCPs) in einem kohärenten Framework.

AWS Organizations bildet die hierarchische Struktur: Management Account → Organizational Units (OUs) → Member Accounts. Die OU-Struktur sollte die Sicherheits- und Compliance-Grenzen des Unternehmens widerspiegeln, nicht die Teamstruktur.

Control Tower setzt darauf auf und liefert:

  • Vorkonfigurierte Guardrails (preventive und detective Controls)
  • Account Factory für standardisierte Account-Provisionierung
  • Dashboard für Compliance-Übersicht

OU-Design: Die wichtigste Entscheidung

Die OU-Struktur ist schwer zu ändern, sobald Accounts darin leben. Typische Struktur:

Root
├── Security (Log Archive, Audit)
├── Infrastructure (Shared Services, Network)
├── Workloads
│   ├── Production
│   ├── Non-Production
│   └── Sandbox
└── Suspended

Wichtig: Sandbox-Accounts für Entwickler sind kein Luxus — sie verhindern, dass Experimente in Produktionsumgebungen landen.

Service Control Policies: Leitplanken, keine Käfige

SCPs sind das mächtigste Werkzeug in AWS Organizations. Sie definieren die maximalen Berechtigungen für alle Accounts in einer OU — unabhängig davon, was IAM-Policies erlauben.

Typische SCPs für eine Enterprise Landing Zone:

  • Region-Einschränkung auf EU-Regionen (DSGVO-Compliance)
  • Verbot von Root-Account-Aktivitäten
  • Schutz von Security-Baseline-Ressourcen vor Löschung
  • Einschränkung bestimmter Services in Sandbox-Accounts

Account Factory: Standardisierung von Anfang an

Jeder neue Account sollte über die Account Factory provisioniert werden — nie manuell. Das stellt sicher, dass Baseline-Konfigurationen (CloudTrail, Config, Security Hub, GuardDuty) von Anfang an aktiv sind.

Mit Account Factory for Terraform (AFT) lässt sich dieser Prozess vollständig automatisieren und versionieren.

Häufig gestellte Fragen

Fazit

Eine Landing Zone ist kein einmaliges Projekt, sondern ein lebendiges System. Die Investition in eine solide Grundstruktur zahlt sich aus — in Form von schnellerer Account-Provisionierung, besserer Compliance-Übersicht und weniger Sicherheitsvorfällen.

Dieser Artikel basiert auf praktischer Erfahrung aus dem Aufbau einer Enterprise Landing Zone bei T-Systems. Details wurden aus Vertraulichkeitsgründen angepasst.