DTAG Group-Wide AWS Landing Zone

Überblick

Die Deutsche Telekom betreibt einen umfangreichen AWS-Footprint. Die zentrale Landing Zone unter der T-Systems International GmbH bündelt über 2.000 AWS-Accounts in 40 AWS Organizations und versorgt damit alle Gesellschaften im Konzern, Tochterfirmen und externe T-Systems-Kunden mit einer gemeinsamen Governance-Schicht. Auch die Telekom IT mit ihrer eigenen Landing Zone war Kunde.

Zwischen 2022 und 2025 habe ich diese Plattform als Senior Product Owner AWS verantwortet und parallel die Rolle des System-Architekten ausgefüllt. Treiber waren die Cloud-Strategie der Telekom und die Konzern-Sicherheits- und Datenschutzanforderungen. Die Plattform liefert skalierbares Account-Vending, eine einheitliche Compliance-Baseline und die Werkzeuge, mit denen Geschäftsbereiche und Kunden ihre Workloads unter Konzernvorgaben betreiben.

Herausforderung

Beim Onboarding fand ich eine reife, aber stark gewachsene Codebasis vor. Die Landing Zone war älter als AWS Control Tower selbst und enthielt jahrelang akkumulierten Technical Debt. Jeder Geschäftsbereich hatte über die Zeit eigene Sonderlösungen bestellt, die als kundenspezifische Features hängen geblieben waren.

Drei Themen liefen parallel: ein breites Anforderungsspektrum mit teils widersprüchlichen Kundenwünschen, der Druck der Konzern-IT auf weitere Compliance-Maßnahmen und Kunden ohne Budget für die nötigen Anpassungen. Compliance-Findings standen früh im Engagement auf der Tagesordnung und mussten ohne Workload-Unterbrechung remediiert werden.

Die organisatorische Hürde lag darin, Konzern-Sicherheitsregeln durchzusetzen, ohne Kunden-Workloads zu brechen. Eine Policy-Änderung an zentraler Stelle konnte in einem fernen Account Produktion lahmlegen. Das verlangte einen Mechanismus, der Sicherheit erhöht und gleichzeitig Migrationspfade offenhält.

Rolle

Als Senior Product Owner AWS bis April 2024 und durchgehend als System-Architekt habe ich folgende Verantwortungen geführt:

• Aus Kundenanfragen, Konzernanforderungen und Security-Findings User Stories und technische Designs abgeleitet
• Architekturentscheidungen für Re-Builds, neue Module und Control-Tower-Integration getroffen
• Feature-Reviews vor Merge durchgeführt und die Plattform-Dokumentation geschrieben
• Mit DTAG-Security, Telekom IT, T-Systems-Lieferorganisation und Kunden-Stakeholdern abgestimmt
• Ein 14-köpfiges Offshore-Engineering-Team über mehrere Jahre fachlich geführt

Die eigentliche Implementierung lag beim Team. Mein Beitrag war der Architektur-Schnitt, die Anforderungsklarheit und das Code-Review.

Vorgehen

Nach einer Inventur entschied ich, die bestehende Lösung nicht zu reparieren, sondern Modul für Modul neu aufzusetzen. Das kostete kurzfristig Feature-Velocity, war aber nachhaltig. Die neue Baseline ging all-in auf Serverless, trennte Entwicklungs- und Testumgebungen strikt von der Produktion und stellte auf Terraform plus GitLab-CI/CD um.

Die Migration folgte den Abhängigkeiten der Landing-Zone-Features statt einer Big-Bang-Logik. Identity zuerst, danach Account-Vending, dann zentrale Logging- und Security-Aggregation. Jedes Feature kam mit Runbook, Drift-Assessment und Validierung.

AWS Control Tower war zum Start der Landing Zone noch nicht verfügbar, deshalb hatte die Plattform die entsprechenden Mechanismen selbst gebaut. Wir integrierten Control Tower nachträglich für Kunden, die native Features wie SCPs, IAM Identity Center, Org CloudTrail und GuardDuty zentral nutzen wollten. Account Factory for Terraform kam bewusst nicht zum Einsatz, weil die bestehende Pipeline die gleichen Aufgaben sauber löste und der Wechsel kein Kundennutzen gewesen wäre.

Entscheidungen

Re-Architecting statt Patchen. Die alte Codebasis hätte ein größeres Wartungsbudget gefressen, als der modulweise Neuaufbau gekostet hat. Wir nahmen die geringere Feature-Velocity bewusst in Kauf, weil die Folgeentwicklung sich danach mehr als verdoppelte.

Serverless als Bauprinzip. Lambda, API Gateway, Step Functions, DynamoDB und EventBridge für asynchrone Lasten, ECS Fargate nur für die wenigen container-basierten stateless Komponenten. Damit fielen ganze Klassen von Patch- und Skalierungsaufgaben weg, die ein klassischer EC2-Stack im Konzernumfeld verursacht.

Strikte Trennung von Dev, Test und Prod. Vorher hatten Hotfixes direkt Produktion berührt. Die Trennung mit eigener Pipeline-Strecke je Umgebung reduzierte Incident-Risiken, hob die Testbarkeit deutlich an und machte Compliance-Reviews einfacher.

Eigene Landing Zone bleibt eigen. Control Tower wurde dort integriert, wo es Kundennutzen brachte. Eine vollständige Migration auf Control Tower hätte den Konzern-Use-Case eingeengt und die bestehende Investition entwertet.

Ergebnisse

• Rund 2.000 AWS-Accounts in 40 AWS Organizations unter einheitlicher Governance betrieben
• 37 % Reduktion der Landing-Zone-Eigenkosten bei gleichbleibender Verfügbarkeit und Resilienz
• 90 % der Codebasis re-architected
• Feature-Lieferzyklus von 6 bis 10 Wochen auf 1 bis 2 Wochen verkürzt
• Account-Provisionierung von bis zu drei Werktagen auf 15 Minuten beschleunigt, vollständig automatisiert
• Über 60 High- und Critical-Findings remediiert ohne Workload-Unterbrechung
• Security by Design dauerhaft im 14-köpfigen Team verankert
• Kundenreferenzen sichtbar im AWS-Partner-Profile der T-Systems

Die Kernlektion: Technical Debt in der Plattformschicht zahlt sich nirgends so spät und so teuer aus wie in einem Konzern mit hunderten interner Stakeholder. Wer früh saniert, kauft sich die Compliance-Geschwindigkeit, die er später braucht.