DTAG Group-Wide AWS Landing Zone

Überblick

Die Deutsche Telekom Group betreibt einen der größten AWS-Footprints in Europa. Als Teil von T-Systems habe ich die Architektur und Umsetzung einer konzernweiten AWS Landing Zone verantwortet — eine zentrale, richtliniengesteuerte Multi-Account-Plattform mit ~2.000 AWS-Accounts in 40 AWS Organizations. Die Plattform etablierte eine einheitliche Security-Baseline, ein Governance-Modell und eine automatisierte Account-Vending-Pipeline für alle DTAG-Geschäftsbereiche.

Das Engagement lief von 2022 bis 2024 und umfasste die Neuarchitektur von rund 80 % der bestehenden Infrastruktur, um sie an AWS Best Practices und die sich weiterentwickelnden Compliance-Anforderungen der DTAG anzupassen.

Herausforderung

Die zentrale Herausforderung war die Kombination aus Skalierung und organisatorischer Komplexität. Mit 40 separaten AWS Organizations und ~2.000 Accounts gab es keine einheitliche Governance-Schicht. Jeder Geschäftsbereich hatte seine eigene Account-Struktur, IAM-Muster und Security-Tooling unabhängig voneinander entwickelt — mit inkonsistenten Controls, doppeltem Aufwand und erheblichem Audit-Overhead als Folge.

Die technische Herausforderung wurde durch die Notwendigkeit verstärkt, laufende Workloads zu migrieren, ohne Produktionssysteme zu unterbrechen. Bestehende Accounts trugen jahrelangen Konfigurationsdrift, und jede Neuarchitektur musste inkrementell erfolgen, während der Geschäftsbetrieb aufrechterhalten wurde.

Auf diesem Engagement gab es keine Product-Owner-Reibung — die Stakeholder waren von Anfang an auf die Notwendigkeit der Zentralisierung ausgerichtet, was dem Team ermöglichte, Architekturentscheidungen schnell voranzutreiben.

Rolle

Als Cloud Architect war ich für das End-to-End-Plattformdesign und die technische Führung eines 14-köpfigen Engineering-Teams verantwortlich. Meine Aufgaben umfassten:

• Definition der Zielarchitektur für die Multi-Account-Struktur mit AWS Control Tower und Account Factory for Terraform (AFT)
• Design der IAM Identity Center-Integration für föderalen Zugriff über alle 40 Organizations
• Etablierung der Security-Baseline: AWS Config Rules, CloudTrail-Aggregation, Security Hub Standards und GuardDuty-Deployment
• Leitung der Neuarchitektur, die ~80 % der bestehenden Infrastruktur betraf
• Koordination mit DTAG-Security-, Compliance- und Geschäftsbereichsteams

Vorgehen

Die Umsetzung folgte einem phasenbasierten Ansatz über zwei Jahre:

Phase 1 — Foundation (Q1–Q2 2022): Aufbau der Management-Account-Struktur, Deployment von AWS Control Tower in der primären Organization und Definition der Account-Baseline via AFT. Terraform-Module wurden für alle Guardrails und SCPs entwickelt.

Phase 2 — Security-Baseline (Q3–Q4 2022): Rollout von AWS Config Conformance Packs, Zentralisierung von CloudTrail in einem dedizierten Log-Archive-Account, Aktivierung von Security Hub mit CIS AWS Foundations Benchmark und Deployment von GuardDuty in allen Member-Accounts.

Phase 3 — Account-Migration (2023): Inkrementelle Migration bestehender Accounts in die Landing-Zone-Struktur. Jede Migration folgte einem Runbook: Drift-Assessment → Remediation → Enrollment → Validierung. Rund 80 % der bestehenden Infrastruktur wurde in dieser Phase neu architekturiert.

Phase 4 — Optimierung und Übergabe (2024): Implementierung von Cost-Allocation-Tagging, Rightsizing-Empfehlungen und automatisiertem Account-Vending via Service Catalog. Wissenstransfer und Runbooks wurden an das interne DTAG-Plattformteam übergeben.

Entscheidungen

AWS Control Tower statt Custom-Orchestrierung: Eine frühe Evaluation hatte den Aufbau einer eigenen Account-Vending-Pipeline in Betracht gezogen. Wir entschieden uns für Control Tower + AFT, da es eine unterstützte, auditierbare Baseline bot, die den langfristigen Wartungsaufwand reduzierte und mit der empfohlenen Multi-Account-Strategie von AWS übereinstimmte.

Zentralisierte vs. delegierte Administration: Security Hub und GuardDuty wurden im Delegated-Administrator-Modus von einem dedizierten Security-Account aus betrieben — nicht vom Management-Account. Dies folgte dem Prinzip der minimalen Rechte und hielt den Blast-Radius des Management-Accounts gering.

Terraform als einzige IaC-Schicht: Obwohl AWS CDK verfügbar war, standardisierte das Team auf Terraform für die gesamte Landing-Zone-Infrastruktur. Diese Entscheidung wurde durch das vorhandene Terraform-Know-how im 14-köpfigen Team und die Notwendigkeit eines konsistenten State-Managements über 40 Organizations getrieben.

Inkrementelle Migration statt Big-Bang-Cutover: Angesichts der Skalierung (~2.000 Accounts) und des Risikos, laufende Workloads zu unterbrechen, wurde ein Big-Bang-Migrationsansatz abgelehnt. Das phasenbasierte Runbook-Modell ermöglichte die Validierung jeder Migration vor dem nächsten Schritt und gab den Geschäftsbereichen Zeit zur Anpassung.

Ergebnisse

Die Plattform lieferte messbare Ergebnisse in den Bereichen Governance, Kosten und Betriebseffizienz:

• ~2.000 AWS-Accounts unter einheitlicher Governance in 40 AWS Organizations zusammengeführt
• 20 % Reduktion der AWS-Kosten durch zentrale Kostentransparenz, Tagging-Enforcement und Rightsizing-Empfehlungen
• ~80 % der bestehenden Infrastruktur neu architekturiert und an die Landing-Zone-Baseline angepasst
• 14-köpfiges Engineering-Team über T-Systems und DTAG-Stakeholder hinweg über 2 Jahre koordiniert
• Zentralisierte Security-Posture mit Security Hub, GuardDuty und Config in allen Member-Accounts
• Automatisiertes Account-Vending reduzierte die Bereitstellungszeit neuer Accounts von Wochen auf Stunden

Eine zentrale Erkenntnis aus diesem Engagement: Eine technische Landing-Zone-Migration in dieser Größenordnung erfordert parallel eine vollständige organisatorische Neuausrichtung. Ohne die Angleichung von Governance-Prozessen, Budget-Ownership und Teamverantwortlichkeiten an die neue Account-Struktur kann die technische Plattform allein ihren beabsichtigten Mehrwert nicht entfalten.