sema.cloud
Project

AWS Landing Zone

Control Tower · Terraform · Account Vending

A governed AWS multi-account foundation built around Control Tower, IAM Identity Center, Terraform, policy-as-code, hub networking, and AFT-based account vending.

Outcomes

At a glance

6
top-level OUs
4
shared accounts
6-12w
ready timeline
Stack

Built with

  • AWS
  • Control Tower
  • Organizations
  • IAM Identity Center
  • Terraform
  • GitLab OIDC
  • OPA
  • Conftest
  • GuardDuty
  • Route 53
  • AFT
Detail

Case study

The problem

Control Tower can create a governed AWS foundation quickly, but the wizard is not the operating model.

A production-ready landing zone still has to answer the questions workload teams depend on: where accounts live, how access works, where logs go, what security services are delegated, how Terraform assumes roles, how policies run before apply, and how new accounts are requested without creating a one-off process every time.

What I built

An AWS landing zone foundation for ames-dev, organized around Control Tower, IAM Identity Center, Terraform, GitLab OIDC federation, policy-as-code, hub networking, and Account Factory for Terraform.

The design separates bootstrap from the repeatable platform layer. Control Tower establishes the governed control plane. Terraform then manages the platform foundation around it: organization representation, execution roles, security configuration, networking, DNS, policy checks, and account vending inputs.

Design decisions worth calling out

  • No workloads in the management account. The management account stays a control-plane boundary, not a convenience account.
  • One child OU per workload family. Workload boundaries preserve ownership, lifecycle, billing, access, and blast-radius decisions.
  • Tiered account vending. Every product gets a clean workload boundary, but not every product gets three accounts before it needs them.
  • Hub networking direction. The Networking account owns shared private DNS and the hub VPC, with Transit Gateway deferred until there is a real multi-VPC routing requirement.
  • Policy before apply. OPA / Conftest checks are part of the delivery path, not a separate audit activity.

What I would keep watching

The hard part is not launching the first version. It is keeping the platform honest as workloads arrive.

The decisions that deserve ongoing attention are account vending, IAM Identity Center access patterns, delegated security ownership, DNS boundaries, CI/CD role assumption, bootstrap exceptions, and when the networking model needs to graduate from hub direction to full transit routing.