# AWS Control Tower vs. Terraform: The Landing-Zone Build-vs-Buy Call
Canonical: https://kaansystems.com/library/control-tower-vs-terraform-landing-zone
Topic: Platform · Published: 2026-09-15 · Updated: 2026-09-15
Summary: The landing-zone decision is a build-vs-buy call: AWS Control Tower gives you managed guardrails and audit evidence in an afternoon, raw Terraform gives you total control and multi-cloud at the cost of owning everything. For most regulated SMBs, Control Tower or Control Tower plus AFT wins. Here is the comparison, the decision tree, and the honest verdict.
## Key takeaways
- For most regulated SMBs, AWS Control Tower is the right landing-zone call: it hands you managed guardrails, centralized logging, and audit-ready evidence in an afternoon instead of a sprint.
- Choose raw Terraform when you are multi-cloud, need full control, want Control Tower's opinionation gone, or already run a Terraform monorepo with a platform engineer to own it.
- Control Tower wins on speed and managed guardrails; Terraform wins on control and portability; Account Factory for Terraform (AFT) splits the difference with a managed baseline plus IaC-driven account vending.
- AFT is worth its extra moving parts (CodePipeline, CodeBuild, DynamoDB, Step Functions) only when managed guardrails are non-negotiable and you also refuse to vend accounts by hand, never just to feel like you are using Terraform.
- The good-enough bar is a landing zone that gives an auditor a structural answer to isolation and log-protection with reviewable change history; Control Tower clears it out of the box, Terraform clears it through git history, and the only wrong call is leaving the decision unmade.
**AWS Control Tower vs. Terraform: which should build your landing zone?** For most regulated SMBs, AWS Control Tower, because it hands you managed guardrails, centralized logging, and audit-ready evidence in an afternoon instead of a sprint. Choose raw Terraform when you are multi-cloud, need full control, or already run a Terraform monorepo with a platform engineer to own it. The honest middle option, Control Tower plus Account Factory for Terraform (AFT), gives regulated teams managed guardrails and IaC-driven account vending at the same time.
This is the decision-stage companion to the deep [multi-account AWS landing zone](/library/multi-account-aws-landing-zone) guide. That article argues the topology: which accounts, which OUs, which service control policies. This one settles the tooling question that stalls the whole project: do you buy the landing zone from AWS or build it in Terraform? Both are chapters in the broader [platform engineering foundation](/library/platform-engineering-for-regulated-startups) a regulated startup assembles.
## What is AWS Control Tower, exactly?
Control Tower is AWS's managed landing zone. You run a guided setup and it stands up AWS Organizations, a multi-account baseline, and the governance most regulated teams would otherwise assemble by hand. Specifically: preventive guardrails implemented as service control policies, detective guardrails implemented as AWS Config rules, centralized CloudTrail and Config logging shipped to a dedicated log-archive account, and Account Factory for vending new accounts against a standard blueprint.
The guardrails ship as a catalog with three postures: mandatory (always on), strongly recommended (AWS's opinion of a sane default), and elective (opt-in). That catalog is the real product. It encodes controls that map cleanly onto the "how is production isolated, how are logs protected" questions a SOC 2 or HIPAA assessor asks, and AWS maintains it as the service evolves.
The trade is opinionation. Control Tower has views on OU structure, its guardrails drift-check against their own model rather than against your infrastructure code, landing-zone version upgrades are a scheduled event you manage, and Account Factory provisions through Service Catalog, which is slow and awkward to drive from a pipeline. You customize within its rails, not around them.
## What is a Terraform landing zone?
A Terraform landing zone is the same architecture, composed by hand. You declare `aws_organizations_organization`, your OUs, your member accounts, your SCPs, your centralized logging, and your account-vending logic in plain Terraform, either hand-rolled or with community modules. Nothing is managed for you and nothing is opinionated at you.
The upside is total control and portability. The org becomes a single `terraform plan` whose changes flow through the same CI, the same review, and the same [drift detection](/library/infrastructure-drift-detection) you already run for everything else. It fits a team that thinks in IaC, and it is the only option if you are genuinely multi-cloud, because Control Tower governs AWS and nothing else. The org definition for a ten-account estate is a few hundred lines, not a mountain.
The downside is that you own all of it, forever. Every guardrail is yours to author and defend. Every detective control is a Config rule you wrote. Every landing-zone "upgrade" is whatever you decide to build next. There is no AWS-maintained baseline underneath you, which is freedom if you have a platform engineer and a liability if you do not.
## Control Tower vs. Terraform: how do they compare?
Control Tower wins on speed and managed guardrails; Terraform wins on control and portability; AFT splits the difference. The table is the decision in one view.
| Dimension | Control Tower | Terraform (roll your own) | AFT (hybrid) |
|---|---|---|---|
| Time to first landing zone | Hours. Guided setup stands up org, logging, and the guardrail baseline | Days to weeks. You write org, OUs, logging, and vending yourself | Control Tower's hours, plus AFT pipeline setup on top |
| Guardrails | Managed catalog: preventive SCPs + detective Config rules, tiered mandatory / recommended / elective | DIY. You author and own every SCP and Config rule | Control Tower's managed catalog |
| Account vending | Account Factory via Service Catalog: standard but slow and awkward to automate | Your own `aws_organizations_account` plus a module | Terraform pipelines vend and customize accounts |
| Drift detection & remediation | Checks against Control Tower's own model; "drift" is CT-defined; reset from the console | Your existing Terraform drift tooling watches the whole org as code | Terraform state for vending; CT model for the guardrails |
| Audit evidence (SOC 2 / HIPAA) | Prebuilt. Control catalog + centralized CloudTrail/Config map onto controls | You assemble it, but git history is first-class change-control evidence | Both: CT control reporting + Terraform change history |
| Customization / flexibility | Within Control Tower's guardrail model and OU opinions | Total. It is just Terraform | High. Guardrails are fixed; vending is fully yours |
| Multi-cloud | AWS only | Any provider Terraform supports | AWS only (Control Tower is AWS-native) |
| Lock-in & exit | AWS-native; decommissioning Control Tower is its own project | Portable Terraform, no proprietary layer to unwind | Tied to Control Tower plus a bespoke pipeline |
| Cost | Control Tower has no service charge; you pay for the Config, CloudTrail, and S3 it turns on | No CT premium; you pay only for what you build | CT's enabled services plus CodePipeline, CodeBuild, DynamoDB, Step Functions |
| Day-2 ops burden | Low on the baseline; landing-zone upgrades are managed events | You own everything, permanently | Highest: Control Tower upgrades and the AFT pipeline both |
## Can you get managed guardrails and Terraform vending at once?
Yes. That is exactly what Account Factory for Terraform (AFT) is for, and for regulated teams that want both, it is often the sweet spot. AFT keeps Control Tower as the governance layer, so AWS still owns the guardrail catalog and the baseline, while account vending and per-account customizations run through Terraform pipelines instead of clicking through Service Catalog. You get managed preventive and detective controls and an IaC-driven account factory that fits a GitOps workflow.
The cost is moving parts. AFT is not a library you import; it is an architecture. It brings its own repositories, a CodePipeline and CodeBuild footprint, a DynamoDB table, and Step Functions orchestration that someone has to understand when a vend fails at 5 p.m. You are now maintaining Control Tower's baseline and a bespoke pipeline on top of it. That is worth it when managed guardrails are non-negotiable (an assessor or a customer security review is driving the requirement) and you also refuse to vend accounts by hand. It is the wrong answer if you were reaching for it just to feel like you are using Terraform; at that point, either accept Control Tower as-is or roll your own cleanly.
## Which should you pick?
Pick Control Tower when platform ownership is thin and you want AWS to maintain the baseline; pick Terraform when you have a platform owner, live in IaC, or need multi-cloud; pick AFT when you need managed guardrails and IaC vending together. Walk the tree, then confirm against the criteria table.
```mermaid
flowchart TD
START["Building an
AWS landing zone"]
MULTI{"Multi-cloud, or a real
non-AWS footprint?"}
OWN{"Want AWS to own the
guardrail baseline?"}
STAFF{"Platform owner +
Terraform already in CI?"}
VEND{"Need IaC-driven
account vending?"}
TF["Roll your own
Terraform"]
CT["Control Tower"]
AFT["Control Tower + AFT"]
START --> MULTI
MULTI -->|Yes| TF
MULTI -->|No| OWN
OWN -->|"No, want full control"| STAFF
STAFF -->|Yes| TF
STAFF -->|No| CT
OWN -->|Yes| VEND
VEND -->|Yes| AFT
VEND -->|No| CT
classDef start fill:#1F4A3E,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
classDef q fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
classDef ans fill:#0a1612,stroke:#2E8B6F,stroke-width:1.5px,color:#E8F5EE;
class START start;
class MULTI,OWN,STAFF,VEND q;
class TF,CT,AFT ans;
```
| Your situation | The call |
|---|---|
| Multi-cloud, or a meaningful non-AWS footprint | Terraform (roll your own) |
| Platform engineer owns IaC, org already in a Terraform monorepo | Terraform (roll your own) |
| No one owns platform yet; you want AWS to maintain the baseline | Control Tower |
| You want Control Tower's opinions gone and total flexibility | Terraform (roll your own) |
| Managed guardrails are required, but vending must be IaC-driven | Control Tower + AFT |
| You want managed guardrails and minimal day-2 upkeep | Control Tower |
The good-enough bar: a regulated SMB has "made the right call" when its landing zone gives an auditor a structural answer to isolation and log-protection, and the change history behind it is reviewable. Both paths clear that bar. Control Tower clears it out of the box; Terraform clears it through your git history, which is arguably stronger evidence. The wrong call is the one nobody makes: staying single-account for another year because the tooling debate never resolved.
Pick Control Tower (or Control Tower + AFT) when you want managed guardrails, ready-made audit evidence, and less to maintain, which describes most regulated SMBs at 10 to 80 engineers. Pick raw Terraform when you need full control, are multi-cloud, want Control Tower's opinionation gone, or are already deep in a Terraform monorepo with platform staff to run it. Do not adopt AFT for its own sake; adopt it only when you genuinely need managed guardrails and IaC vending at once.
One caution that applies whichever you choose: the landing zone is where long-lived access tends to accumulate, so pair this decision with a plan for [killing long-lived credentials](/library/killing-long-lived-credentials) before the account count grows. Federated identity and short-lived sessions are far cheaper to establish at ten accounts than to retrofit at forty.
## The Template
Score each item honestly before you commit. If most of the left column is true, buy (Control Tower). If most of the right column is true, build (Terraform). If the guardrail rows point one way and the vending rows point the other, you are looking at AFT.
**Team and ownership**
- [ ] A named engineer owns platform (not "the whole team")
- [ ] Terraform already runs through CI with reviewed plans
- [ ] Someone can maintain a CodePipeline/CodeBuild footprint (AFT gate)
- [ ] The org would otherwise be vended by hand (points toward Account Factory or AFT)
**Scope and constraints**
- [ ] Estate is AWS-only for the foreseeable future (Control Tower is viable)
- [ ] There is a real non-AWS footprint (forces Terraform)
- [ ] Control Tower's OU opinions are acceptable, not a blocker
- [ ] Multi-cloud governance must live in one tool (forces Terraform)
**Compliance and evidence**
- [ ] SOC 2 or HIPAA scope is active or imminent
- [ ] A managed guardrail catalog would shorten audit prep (favors Control Tower)
- [ ] Git-based change history is your preferred evidence (favors Terraform)
- [ ] Centralized CloudTrail/Config to a locked log-archive account is required either way
**Operations and cost**
- [ ] You want AWS to own the baseline and its upgrades (favors Control Tower)
- [ ] You want the org to live under existing drift detection as code (favors Terraform)
- [ ] Landing-zone version upgrades as a managed event are acceptable
- [ ] You have priced the Config, CloudTrail, and S3 that any of these turns on
**Exit**
- [ ] You have considered what decommissioning Control Tower would take later
- [ ] You are comfortable with an AWS-native layer (Control Tower) vs. portable Terraform
Most SMBs find the left column mostly true and land on Control Tower, or find the guardrail rows true and the vending rows true and land on AFT. Teams with a platform owner and a Terraform habit tend to find the right column true and roll their own. All three are defensible; an unmade decision is not.
## Frequently asked questions
**Q: AWS Control Tower vs Terraform — which should you use?**
Use AWS Control Tower for most regulated SMBs, because it delivers managed guardrails, centralized logging, and audit-ready evidence in hours rather than a sprint. Use raw Terraform when you are multi-cloud, need total control, want Control Tower's opinionation gone, or already run a Terraform monorepo with a platform engineer to own it. If you need managed guardrails and IaC-driven account vending together, use Control Tower with AFT.
**Q: Is AWS Control Tower free?**
Control Tower itself has no service charge, but it is not free to run, because it enables paid services on your behalf. You pay for the AWS Config rules (detective guardrails), the CloudTrail data events, the S3 storage in the log-archive account, and any other resources the baseline turns on. For a small estate this is typically modest, but "no charge for Control Tower" is not "no bill"; price the enabled services, since Config in particular meters per account (list pricing, approximate) and scales with your account count.
**Q: Can you use Terraform with Control Tower?**
Yes, through Account Factory for Terraform (AFT), which is AWS's supported pattern for exactly this. Control Tower stays the governance and guardrail layer while account vending and per-account customizations run through Terraform pipelines. You get managed preventive and detective controls plus an IaC-driven account factory, at the cost of maintaining AFT's pipeline (CodePipeline, CodeBuild, DynamoDB, Step Functions) on top of Control Tower.
**Q: Does Control Tower give you SOC 2 evidence?**
Control Tower gives you strong raw material for SOC 2 and HIPAA evidence, not a finished audit package. Its guardrail catalog, centralized CloudTrail and Config logging, and control reporting map cleanly onto the isolation, access, and log-integrity controls assessors look for, which shortens evidence collection. You still assemble the actual evidence and demonstrate the controls operating over the audit period; Control Tower makes that assembly faster, it does not eliminate it.
**Q: What is Account Factory for Terraform (AFT)?**
AFT is a hybrid model where Control Tower provides governance and guardrails while Terraform pipelines drive account vending and customization. It is AWS's answer for teams that want Control Tower's managed baseline but refuse to provision accounts by hand through Service Catalog. AFT ships as an architecture with its own repositories and pipeline components, so it adds real day-2 maintenance; adopt it when you genuinely need managed guardrails and IaC vending at once, not just to feel like you are using Terraform.
**Q: Can you move off Control Tower to Terraform later?**
Yes, but treat it as a project, not a toggle. Because Control Tower manages the org, the guardrails, and the logging baseline, decommissioning it means taking ownership of all three in Terraform without disrupting the accounts and workloads underneath. It is doable and people do it, which is why starting with Terraform is attractive if you already have the platform muscle. If you do not, starting with Control Tower and migrating later is a reasonable sequence, just budget the eventual unwind honestly rather than assuming it is free.
Template: "Control Tower vs. Terraform decision checklist" — branded PDF at https://kaansystems.com/templates/control-tower-vs-terraform-landing-zone.pdf
Source: https://kaansystems.com/library/control-tower-vs-terraform-landing-zone · Work with Kaan Systems: https://kaansystems.com/contact