DTAG Group-Wide AWS Landing Zone

T-Systems2022–2024

Team: 14 peopleCloud Architect

AWS Control TowerAWS OrganizationsAWS IAM Identity CenterAWS ConfigAWS CloudTrailAWS Security HubAmazon GuardDutyAWS Service CatalogAccount Factory for Terraform

Confidential

Screenshots not available — confidential project

Overview

Deutsche Telekom Group operates one of the largest AWS footprints in Europe. As part of T-Systems, I led the architecture and delivery of a group-wide AWS Landing Zone — a centralized, policy-driven multi-account platform spanning ~2,000 AWS accounts across 40 AWS Organizations. The platform established a consistent security baseline, governance model, and account vending pipeline for all DTAG business units.

The engagement ran from 2022 to 2024 and involved rearchitecting approximately 80% of the existing infrastructure to align with AWS best practices and DTAG's evolving compliance requirements.

Challenge

The primary challenge was scale and organizational complexity. With 40 separate AWS Organizations and ~2,000 accounts, there was no unified governance layer. Each business unit had evolved its own account structure, IAM patterns, and security tooling independently — resulting in inconsistent controls, duplicated effort, and significant audit overhead.

The technical challenge was compounded by the need to migrate live workloads without disrupting production systems. Existing accounts carried years of accumulated configuration drift, and any rearchitecting had to be done incrementally while maintaining business continuity.

There was no product owner friction on this engagement — stakeholders were aligned on the need for centralization from the outset, which allowed the team to move quickly on architectural decisions.

Role

As Cloud Architect, I was responsible for the end-to-end platform design and technical leadership of a 14-person engineering team. My responsibilities included:

  • Defining the target architecture for the multi-account structure using AWS Control Tower and Account Factory for Terraform (AFT)
  • Designing the IAM Identity Center integration for federated access across all 40 organizations
  • Establishing the security baseline: AWS Config rules, CloudTrail aggregation, Security Hub standards, and GuardDuty deployment
  • Leading the rearchitecting effort that touched ~80% of existing infrastructure
  • Coordinating with DTAG security, compliance, and business unit teams

Process

The delivery followed a phased approach over two years:

Phase 1 — Foundation (Q1–Q2 2022): Established the management account structure, deployed AWS Control Tower in the primary organization, and defined the account baseline via AFT. Terraform modules were written for all guardrails and SCPs.

Phase 2 — Security Baseline (Q3–Q4 2022): Rolled out AWS Config conformance packs, centralized CloudTrail to a dedicated log archive account, enabled Security Hub with CIS AWS Foundations Benchmark, and deployed GuardDuty across all member accounts.

Phase 3 — Account Migration (2023): Migrated existing accounts into the Landing Zone structure incrementally. Each migration followed a runbook: drift assessment → remediation → enrollment → validation. Approximately 80% of existing infrastructure was rearchitected during this phase.

Phase 4 — Optimization and Handover (2024): Implemented cost allocation tagging, rightsizing recommendations, and automated account vending via Service Catalog. Delivered knowledge transfer and runbooks to the DTAG internal platform team.

Decisions

AWS Control Tower over custom orchestration: Early evaluation considered building a custom account vending pipeline. We chose Control Tower + AFT because it provided a supported, auditable baseline that reduced long-term maintenance burden and aligned with AWS's recommended multi-account strategy.

Centralized vs. delegated administration: Security Hub and GuardDuty were deployed in delegated administrator mode from a dedicated security account rather than the management account. This followed the principle of least privilege and kept the management account blast radius minimal.

Terraform as the single IaC layer: Despite AWS CDK being available, the team standardized on Terraform for all Landing Zone infrastructure. This decision was driven by the existing Terraform expertise across the 14-person team and the need for consistent state management across 40 organizations.

Incremental migration over big-bang cutover: Given the scale (~2,000 accounts) and the risk of disrupting live workloads, we rejected a big-bang migration approach. The phased runbook model allowed us to validate each migration before proceeding and gave business units time to adapt.

Results

The platform delivered measurable outcomes across governance, cost, and operational efficiency:

  • ~2,000 AWS accounts brought under unified governance across 40 AWS Organizations
  • 20% reduction in AWS spend through centralized cost visibility, tagging enforcement, and rightsizing recommendations
  • ~80% of existing infrastructure rearchitected to align with the Landing Zone baseline
  • 14-person engineering team coordinated across T-Systems and DTAG stakeholders over a 2-year engagement
  • Centralized security posture with Security Hub, GuardDuty, and Config deployed across all member accounts
  • Automated account vending reduced new account provisioning time from weeks to hours

A key learning from this engagement: a technical Landing Zone migration of this scale requires a full-stack organizational reorg in parallel. Without aligning governance processes, budget ownership, and team responsibilities to the new account structure, the technical platform alone cannot deliver its intended value.

Learn more about my background, certifications, and how I work on the About page.

About me