Terraforming a Multi-Account AWS Landing Zone

Why Multi-Account Matters

A single AWS account becomes a liability at scale. Shared IAM boundaries, interleaved billing, and overlapping resource limits create operational risk that grows with every team and workload added to the environment. A multi-account strategy addresses these concerns through blast radius reduction, precise cost attribution, and compliance isolation. When a development experiment goes wrong, it cannot affect production. When audit season arrives, each account maps cleanly to a regulatory scope.

The approach detailed here uses AWS Control Tower as the foundation, with Terraform managing the infrastructure layer that Control Tower does not cover. The result is a landing zone that can vend new accounts in minutes, complete with networking, security baselines, and cost guardrails, all defined in version-controlled modules.

Landing Zone Architecture

Control Tower provides the baseline: a management account, a log archive account, an audit account, and the Organization Units (OUs) that group workload accounts by lifecycle stage and compliance requirements. Service Control Policies (SCPs) enforce guardrails at the OU level, preventing actions like disabling CloudTrail or creating resources in unapproved regions. Terraform modules extend this baseline with custom SCPs, account vending automation, and shared-service provisioning that Control Tower does not natively support.

Networking with Transit Gateway

A centralised VPC sharing model uses AWS Transit Gateway as the backbone for cross-account connectivity. The hub-and-spoke topology routes traffic through a shared-services VPC that hosts DNS resolution via Route 53 Resolver endpoints, centralised NAT gateways, and an inspection VPC running AWS Network Firewall. Spoke VPCs in workload accounts attach to the Transit Gateway with route table associations that enforce segmentation: production workloads cannot route to development accounts, and internet egress flows through the inspection VPC for deep packet analysis.

Policy as Code

Every Terraform plan runs through tfsec and Checkov as part of the GitHub Actions workflow. Pre-commit hooks catch common misconfigurations before code reaches a pull request, while PR checks run the full policy suite against the planned infrastructure changes. Open Policy Agent (OPA) evaluates custom rules that encode organisation-specific requirements, such as mandatory encryption settings, approved instance families, and tagging standards. Pull requests that fail any policy gate cannot be merged, creating an automated guardrail that scales across all teams without manual review bottlenecks.

Self-Service Provisioning

The landing zone now supports over 30 accounts across four OUs, with new accounts provisioned through a self-service workflow that takes less than 15 minutes from request to fully configured environment. Every account inherits networking, security baselines, and cost controls automatically, allowing application teams to focus on building features rather than configuring infrastructure foundations.