DTAG Group-Wide AWS Landing Zone

Overview

Deutsche Telekom operates an extensive AWS footprint. The central Landing Zone, operated by T-Systems International GmbH, bundles over 2,000 AWS accounts across 40 AWS Organizations. It serves every company in the Deutsche Telekom group, subsidiaries and external T-Systems customers with a shared governance layer. Even the Telekom IT division with its own Landing Zone was a customer.

Between 2022 and 2025 I owned this platform as Senior Product Owner AWS and held the System Architect role in parallel. The drivers were Telekom's cloud strategy and group-level security and data-protection requirements. The platform delivers scalable account vending, a unified compliance baseline and the tooling that lets business units and customers run their workloads under group rules.

Challenge

When I onboarded, I found a mature but heavily grown codebase. The Landing Zone predated AWS Control Tower itself and carried years of accumulated technical debt. Every business unit had ordered its own special features over time, and those had hardened into customer-specific branches of the platform.

Three pressures ran in parallel: a broad and partially contradictory customer requirements stream, ongoing demands from group IT for new compliance controls, and customers without budget for the adaptations these controls required. Compliance findings landed on the agenda early in my engagement and had to be remediated without disrupting workloads.

The organisational hurdle was enforcing group-level security rules without breaking customer workloads. A single policy change at the centre could take production down in a distant account. That demanded a mechanism that raises security and keeps migration paths open at the same time.

Role

As Senior Product Owner AWS until April 2024 and continuously as System Architect, I owned the following:

• Turning customer requests, group requirements and security findings into user stories and technical designs
• Architecture decisions for rebuilds, new modules and the Control Tower integration
• Pre-merge feature reviews and the platform documentation
• Stakeholder alignment across DTAG security, Telekom IT, the T-Systems delivery organisation and customer teams
• Technical leadership of a 14-person offshore engineering team across multiple years

Implementation sat with the team. My contribution was the architectural cut, requirements clarity and code review.

Process

After taking inventory I decided not to repair the existing solution but to rebuild it module by module. That cost short-term feature velocity, but it paid back. The new baseline went all-in on serverless, separated development and test environments strictly from production and standardised on Terraform with GitLab CI/CD.

The migration followed the dependency graph of Landing Zone features rather than a big-bang switch. Identity first, then account vending, then central logging and security aggregation. Every feature came with a runbook, drift assessment and validation.

AWS Control Tower did not exist when the Landing Zone was first built, so the platform had grown its own equivalents. We integrated Control Tower later for customers who wanted to use native features like SCPs, IAM Identity Center, organization-wide CloudTrail and GuardDuty centrally. We deliberately skipped Account Factory for Terraform because the existing pipeline solved the same problems cleanly and switching would have added no customer value.

Decisions

Re-architecting over patching. The old codebase would have consumed a larger maintenance budget than the modular rebuild cost us. We accepted the lower feature velocity in the short term because subsequent delivery more than doubled afterwards.

Serverless as the building principle. Lambda, API Gateway, Step Functions, DynamoDB and EventBridge for async workloads, ECS Fargate only for the few container-based stateless components. That removed whole classes of patching and scaling work a classic EC2 stack inflicts inside a corporate group.

Strict separation of dev, test and prod. Before the rebuild, hotfixes had reached production directly. The separation with its own pipeline track per environment reduced incident risk, raised testability significantly and simplified compliance reviews.

Our own Landing Zone stayed our own. We adopted Control Tower where it produced customer value. A full migration to Control Tower would have narrowed the group use case and devalued the existing investment.

Results

• Roughly 2,000 AWS accounts across 40 AWS Organizations operated under unified governance
• 37% reduction in Landing Zone operating cost with availability and resilience unchanged
• 90% of the codebase re-architected
• Feature delivery cycle shortened from 6 to 10 weeks down to 1 to 2 weeks
• Account provisioning accelerated from up to three business days to 15 minutes, fully automated
• Over 60 high and critical findings remediated without disrupting workloads
• Security-by-design culture embedded in the 14-person engineering team
• Customer references visible on the AWS Partner profile of T-Systems

The core lesson: technical debt in a platform layer compounds nowhere as expensively as inside a corporate group with hundreds of internal stakeholders. Paying it down early buys the compliance velocity you will need later.