Every enterprise AWS project eventually hits the same conversation: do we use AWS Control Tower, or do we build the landing zone ourselves? Both camps have loud advocates, and both miss the point. The right answer depends on your constraints — not on ideology.
What we're actually talking about
A landing zone is the foundational layer of your AWS environment: account structure, guardrails, logging, networking baselines and identity. It's the thing that makes everything else consistent and auditable. Without it, you end up with account sprawl, inconsistent configurations and compliance gaps that show up at the worst possible moment.
AWS Control Tower is AWS's managed service for setting up and governing a multi-account environment. It automates the creation of a landing zone using opinionated defaults and provides a dashboard for ongoing governance. It deploys on top of AWS Organizations and integrates with IAM Identity Center, CloudTrail, AWS Config and Security Hub out of the box.
A "DIY" landing zone means building the same thing yourself — using Terraform, CDK or CloudFormation — without Control Tower as the orchestrator. You own the full stack.
The case for Control Tower
Control Tower is the right starting point for most teams. Here's why:
- It works out of the box. Mandatory controls, centralized logging to S3, CloudTrail enabled across all accounts, Config enabled — all of it is wired up by default. You don't need to design and validate this yourself.
- Account Factory for Terraform (AFT) extends it cleanly. If you need IaC-driven account provisioning, AFT sits on top of Control Tower and gives you a GitOps-compatible pipeline for vending accounts with customizations applied automatically.
- AWS maintains it. New services, new regions, updated controls — AWS keeps Control Tower current. If you build DIY, you own every upgrade.
- Procurement teams recognize it. In regulated and public sector environments, "we use Control Tower" is a shorthand that auditors and procurement teams understand. A DIY solution requires explanation.
If you're starting fresh and don't have exotic constraints, Control Tower is the correct choice. Most arguments against it come from architects who haven't used it in the last 18 months and are reacting to limitations that no longer exist.
When Control Tower becomes a problem
Control Tower has real limitations. They matter in specific situations:
- Existing Organizations with non-standard OU structure. Control Tower requires a specific OU hierarchy. Retrofitting it onto an existing Organization with a custom structure is painful and sometimes impossible without significant disruption.
- Regions with no Control Tower support. AWS China is the most obvious example. Control Tower doesn't operate in the China partition. If your architecture spans AWS commercial and AWS China, you need a separate approach for the China side anyway.
- Highly customized network topology. Control Tower's networking baseline is VPC-per-account. If your architecture requires a centralized Transit Gateway hub deployed before any workload accounts exist, you'll need to work around the default setup.
- Strict change control on guardrails. Control Tower's mandatory controls cannot be modified or disabled. If a mandatory control conflicts with a legitimate architectural decision in your environment, you have limited options. DIY gives you full control over every guardrail.
- Multi-partition or air-gapped requirements. GovCloud, classified environments or air-gapped deployments often require a fully custom approach. Control Tower assumptions don't hold.
The decision framework
Run through these questions in order:
Fresh start → Control Tower. Existing Organization with established account structure → evaluate carefully, DIY may be less disruptive.
Yes → Control Tower can't cover those partitions. You need a hybrid approach or full DIY depending on how central those regions are.
Strong Terraform team with CI/CD → either approach works, AFT makes Control Tower IaC-friendly. Limited IaC maturity → Control Tower reduces what you need to build and maintain.
Review the mandatory controls list before committing. If a control blocks something you know you need, document why and decide whether the workaround is acceptable.
Need to be audit-ready in 90 days → Control Tower with AFT. Have 9 months and a team that will maintain the platform long-term → DIY can be the right investment.
The hybrid approach that actually works
Most real enterprise environments land somewhere in the middle. The pattern I've used repeatedly: Control Tower for account management, guardrails and central logging — AFT for account vending — and custom Terraform modules for everything Control Tower doesn't prescribe (network baselines, security tooling, tagging, budget alerts, cross-account roles).
This gives you the operational benefit of Control Tower's managed controls without being limited to what it natively deploys. You extend it rather than replace it.
The anti-pattern to avoid: full DIY because someone decided Control Tower was "too opinionated," resulting in six months of building governance infrastructure that AWS would have given you for free, followed by a landing zone that nobody documents and nobody can maintain when the original architect leaves.
What this looks like in practice
In a recent engagement for a public sector client, we had an existing Organization with ~30 accounts and no consistent guardrails. The decision was to enroll into Control Tower progressively — registering existing accounts into the correct OU structure over four sprints — while using AFT to handle all new account vending going forward. The mandatory controls surfaced three configuration gaps that turned into remediation tasks before the next audit. That's the feature, not the bug.
For a global manufacturing client spanning AWS commercial and AWS China regions, Control Tower handled everything in the eu-central-1 and us-east-1 regions. The China side (cn-north-1, cn-northwest-1) used a parallel DIY stack with equivalent guardrail coverage, maintained separately by the same Terraform codebase but with the China-specific constraints built in. One governance model, two implementations.
The bottom line
Use Control Tower unless you have a specific technical reason not to. Document that reason. Then build on top of it with AFT and custom modules rather than fighting it or working around it.
If your environment has genuine constraints that Control Tower can't accommodate, DIY is the right call — but go in knowing that you're taking on long-term ownership of governance infrastructure that AWS would otherwise maintain for you. Budget for it accordingly.
The debate shouldn't be "Control Tower vs. DIY." It should be "what does our specific environment actually require, and what's the most maintainable way to deliver that?" Start with Control Tower and subtract from there, rather than starting from scratch and trying to rebuild what Control Tower gives you for free.