Comparison
AWS Control Tower vs a custom landing zone
For most AWS-only organizations, Control Tower is the right default: the service carries no additional charge, AWS maintains the engine, and landing zone 4.0 made its integrations optional. Landing Zone Accelerator adds a broad, compliance-aligned baseline but runs as an AWS-written CDK pipeline you deploy, debug and upgrade; a custom Terraform or OpenTofu baseline fits when your clouds or structure match neither, and you are ready to own every line. All three can let your team vend an account from a repo — the real difference is whose code you read when it breaks.
There are three serious ways to build an AWS multi-account landing zone in late 2026. Their pitches make them sound interchangeable. They aren’t: they differ in who writes the code that turns your intent into accounts, and who has to upgrade it.
| AWS Control Tower | Landing Zone Accelerator (LZA) | Custom Terraform / OpenTofu | |
|---|---|---|---|
| What it is | A managed AWS service | An open-source AWS solution you deploy and run | Your modules on the AWS Organizations APIs |
| Your intent lives in | Landing-zone settings, controls and baselines, set through its API or Terraform | YAML configuration files in Git or S3 | Your repository |
| The engine | AWS-managed; AFT adds a pipeline account you run | AWS’s CDK app, in your CodePipeline | Your modules, your CI |
| “Drift” means | A Control Tower resource changed outside Control Tower | Live state differs from the YAML; the next pipeline run decides | Whatever a scheduled plan shows |
| Upgrades | A new landing-zone version, then member accounts | A new release branch, then a full pipeline run | No vendor cadence, and no vendor improvements |
| Pricing model | No charge for the service; you pay for what it configures | You pay for the AWS services it runs and deploys | You pay for what you deploy, plus the engineering |
Every option can pass the account-51 test
In A landing zone you can’t apply yourself is just someone else’s repo, the acceptance test was simple: can an engineer who wasn’t in the build vend a fully governed account from the repo? Done properly, all three pass: an AFT account request, a new entry in LZA’s accounts-config.yaml or a call to your own vending module.
So add a second question: when the vend fails, or a guardrail must change, whose code do you read? The answer sets your drift model and your upgrade bill.
When Control Tower is the right answer
If you run on AWS alone and your structure is conventional, start here. The service itself carries no additional charge; you pay for what it configures, such as AWS Config and CloudTrail. Landing zone 4.0, released in November 2025, made the Config, CloudTrail, Security Roles and Backup integrations optional, stopped requiring a Security OU, and allows a minimal, controls-only setup. Since October 2025, opt-in auto-enrollment applies an OU’s baselines and controls to any account moved into it, whatever tool created the account.
You don’t give up code either. The Terraform AWS provider manages the landing zone, its controls and its baselines as resources. Beyond the console’s Account Factory, which runs on Service Catalog, Account Factory for Terraform (AFT) turns account requests into a GitOps flow on Terraform Community Edition, HCP Terraform or Terraform Enterprise; OpenTofu isn’t on AWS’s list. In 2026 it gained plan-only runs and can re-apply customizations when an account changes OU. Its default deployment includes a NAT gateway and PrivateLink endpoints, which you pay for.
What you trade is authorship. You own the resources Control Tower creates; AWS owns the logic that creates and reconciles them. Drift is defined on AWS’s terms: edit a managed SCP, or move an account between OUs without auto-enrollment, and you fix it Control Tower’s way. Upgrades arrive as landing-zone versions you apply, then roll to member accounts, usually by re-registering OUs. Versions change behavior, too: in 4.0, drift notifications moved from SNS to EventBridge, and disabling centralized logging now deletes the logging account’s resources instead of just switching the trail off. Read the 4.0 key changes before you press Update, and pick your home Region with care: AWS says it can’t be changed after setup.
When Landing Zone Accelerator fits
LZA is built for regulated environments that want a broad, compliance-aligned baseline on day one. AWS describes it as a low-code solution spanning more than 35 services, deployable in every Region, including AWS GovCloud (US). It can create and manage Control Tower for you, or run on AWS Organizations alone.
The catch is the engine. LZA is a large CDK application that AWS writes and you run: an installer pipeline and a core pipeline that synthesize and deploy CloudFormation across your accounts. Your YAML is yours, but when a stage fails, you debug generated templates from code you didn’t write. Upgrades can change meaning, not just add features. Release 1.16.0 (July 2026) began reconciling Transit Gateway route-table associations and propagations to match network-config.yaml exactly, removing any created by hand, and its own release notes send upgraders to 1.16.1 instead. The footprint isn’t small either: AWS’s cost estimate for the sample configuration, idle and with no workloads, is about US$430 a month, mostly CloudTrail and VPC networking.
When a custom baseline earns its cost
Write your own when the managed options fight you: several clouds that need one approach, an organization structure or control set that doesn’t fit, or a platform team that already reviews every change as a Terraform plan. The building blocks are first-class: AWS Organizations service control policies, resource control policies and declarative policies for services such as EC2, S3 and Security Hub, all in the same Terraform provider.
The price is that everything Control Tower would set up becomes your backlog: the organization trail, Config recording, IAM Identity Center wiring, the log archive and audit roles, account vending and drift detection. Nobody ships you upgrades, so nobody breaks you with one, but nobody adds the next useful control for you either.
A middle path we like: own the structure, vending and network in Terraform, and enable Control Tower’s managed controls, in controls-only mode, on the OUs your module fills.
How to choose
- AWS only, conventional structure, small platform team: Control Tower, configured as code through the provider or AFT.
- Regulated workloads, GovCloud, or a compliance baseline you must show quickly: LZA, usually on top of Control Tower — if your team will run CodePipeline and read CDK.
- Several clouds, an existing Terraform platform, or a structure Control Tower can’t express: a custom baseline, optionally paired with Control Tower controls-only.
- Whatever you pick: record the decision in an ADR that names who owns upgrades.
A Cloud Foundation Build starts with this decision, written down, and delivers the answer as Terraform in your repository — Control Tower driven through its API, or an Organizations baseline we write. Either way it ends the same: your team vends the next account without us.