Most teams pick their multi-account governance model the wrong way. They evaluate AWS Control Tower against a custom landing zone based on setup speed, then discover the real trade-offs six months later when they are trying to enforce a compliance requirement that neither model handles cleanly out of the box.
The decision is not "fast vs. flexible." It is about where your governance ceiling sits relative to where your organization will be in 18 months. Getting this wrong means rebuilding your account structure mid-growth, which costs more in engineering time than getting it right the first time.
What AWS Control Tower Actually Gives You
Control Tower is a managed governance layer built on top of AWS Organizations. When you enable it, you get four things immediately: a pre-configured OU hierarchy, a management account with consolidated billing, a log archive account for centralized CloudTrail and Config storage, and an audit account for security tooling.
The guardrails come in two types. Preventive guardrails are Service Control Policies that block specific actions across enrolled accounts, for example, preventing users from disabling CloudTrail or creating resources outside approved regions. Detective guardrails are AWS Config rules that flag policy violations after they occur but do not block the action.
Account Factory handles provisioning: fill out a Service Catalog form and Control Tower creates the account, enrolls it into the right OU, applies guardrails, and sets up the landing zone baseline. For teams starting from zero, this is genuinely fast. A basic environment is running in 2-4 hours.
The compliance integration is real. Control Tower's Security Hub integration covers roughly 80% of CIS Level 1 controls. For teams targeting SOC 2 Type II or ISO 27001, that baseline matters. The remaining 20% requires custom detective controls regardless of which landing zone approach you choose.
Where Control Tower Breaks Down at Scale
The limitations are specific and predictable. They show up at identifiable thresholds, not gradually.
| Limitation | When It Becomes Blocking | Workaround Cost |
|---|---|---|
| Account Factory provisioning takes 15-30 minutes per account | Teams requesting 5+ accounts per week hit queue friction | Custom vending pipeline alongside Control Tower |
| CfCT supports only CloudFormation and Service Catalog | Any Terraform-native team at account creation time | Parallel Terraform provisioning layer, manual enrollment |
| Managed guardrails cover ~25 services | Adding guardrails for new or niche services requires custom SCPs | Custom SCP management outside Control Tower guardrail framework |
| OU hierarchy is enforced by Control Tower; restructuring requires re-enrollment | Any org redesign after initial setup | Multi-week re-enrollment effort, risk of guardrail gaps during migration |
| Control Tower does not manage IAM Identity Center cross-account permission sets automatically | Teams with complex role-per-team-per-account models at 50+ accounts | Custom permission set automation via IAM Identity Center APIs |
| CloudTrail and Config logging adds real cost | Estates over 500 accounts with high API activity see several hundred dollars monthly from mandatory logging | No workaround: this is the cost of the managed compliance layer |
The Terraform problem deserves specific attention. Control Tower Customizations (CfCT) is the official extension mechanism. It watches a git repository for CloudFormation templates and Service Catalog products, then deploys them when accounts are created or updated. If your team writes infrastructure in Terraform, you face a choice: maintain CloudFormation wrappers around your Terraform modules, or run a separate Terraform pipeline that the Control Tower framework does not manage. Most teams end up with both, which means two provisioning surfaces to maintain.
The account vending latency compounds at scale. At 15-30 minutes per account, a team spinning up 20 new sandbox accounts for a feature sprint waits up to 10 hours. Teams that hit this limit start consolidating workloads into shared accounts to avoid the wait, which breaks the isolation guarantees the landing zone was built to provide.
What a Custom Landing Zone Actually Costs to Build and Run
Custom landing zones have no licensing fee. They have a build cost and a maintenance cost, and teams consistently underestimate the second one.
A 3-person platform team building from scratch: 6-12 weeks to deliver a production-ready custom landing zone. That includes account bootstrapping automation, an SCP management pipeline, Config aggregation, Security Hub integration, and a Terraform module library for account-level baseline resources. Roughly 40% of that initial build time goes to account bootstrapping alone: the IAM roles, state backends, remote provider configs, and cross-account trust relationships that Control Tower handles automatically.
The ongoing cost is the part that surprises teams. Extending the landing zone to a new AWS service requires updating the SCP library. A new compliance requirement means adding Config rules and remediation automation. A new region requires validating that every baseline module works correctly there. This work runs at 20-30% of one engineer's time, every quarter, indefinitely. Teams that staff for the build but not the maintenance find their landing zone drifting from requirements within 12 months.
For multi-account cost governance, custom landing zones give you full control over how consolidated billing and cost allocation tags are structured, which matters when you need team-level chargeback across 50+ accounts.
The Decision Framework: Four Variables That Determine the Right Model
Four variables drive the choice. Answer these in order.
The account growth trajectory matters more than current count. A team at 30 accounts growing by 10 per month hits 150 accounts in 12 months. At that scale, Control Tower's Account Factory latency becomes a daily friction point if your developers request accounts frequently.
Control Tower works well when: team size is under 3 engineers, you are starting from zero with fewer than 50 accounts, and CloudFormation is acceptable as a provisioning layer. It breaks when your Terraform modules cannot be wrapped in CloudFormation without a full re-engineering effort.
Custom landing zones work well when: you have 3+ platform engineers with bandwidth for ongoing maintenance, your account count will exceed 100, and you need sub-2-minute account provisioning. They break when the team underestimates quarterly maintenance, or when a compliance audit requires proving guardrail coverage across a sprawling SCP library that no one has documented.
Tag governance is a decision point that affects both models equally. Custom landing zones let you enforce tag policies at account creation in Terraform. Control Tower requires Service Catalog parameters or post-creation Config rule remediation. Either way, tagging strategy must be designed before account provisioning, not after.
The Hybrid Model: Control Tower Guardrails with Custom Account Vending
Most large AWS environments running today are neither pure Control Tower nor pure custom. They are hybrid: Control Tower manages the compliance baseline, and custom automation handles the provisioning experience.
The pattern works like this. Control Tower stays enrolled and manages the preventive and detective guardrails. Its log archive and audit accounts stay intact. Security Hub integration runs through the managed framework. The part that changes is account creation: instead of Account Factory's Service Catalog form, a custom pipeline triggers account creation through the AWS Organizations API, then calls Control Tower's enrollment API to bring the new account into the managed framework.
This hybrid approach cuts account provisioning from 15-30 minutes to under 2 minutes because the Terraform baseline runs in parallel with Control Tower enrollment rather than waiting for Service Catalog to complete. The team controls the provisioning logic. Control Tower controls the compliance posture.
The failure condition for hybrid: the custom pipeline must call Control Tower enrollment correctly or accounts end up provisioned but not enrolled, which means no managed guardrails. Drift detection is required. Any account in your Organizations inventory that is not enrolled in Control Tower is a governance gap. Build an automated check that runs daily and alerts on unenrolled accounts.
RBAC for your governance platform applies to both models: the IAM roles that the vending pipeline uses to create accounts and apply baselines need tightly scoped permissions, not AdministratorAccess. We have seen landing zones where the account vending role had organization-wide admin rights. That is a single credential compromise away from full estate access.
Which Model Scales
Neither model scales automatically. Control Tower scales within AWS's managed guardrail coverage and your tolerance for CloudFormation-based provisioning. Custom landing zones scale with your team's willingness to maintain them.
For teams starting with fewer than 50 accounts and a small platform team: Control Tower. The 80% compliance coverage and zero-maintenance guardrails are worth the customization constraints. Add custom automation only where Control Tower's limits are concretely blocking you.
For teams at 100+ accounts, growing fast, with Terraform as the primary toolchain: hybrid or custom. The account vending bottleneck and Terraform integration friction compound over time. Build the custom pipeline early, before the pain forces you to rebuild it under pressure.
The 20% of compliance requirements that neither model covers is the constant. Whether you chose Control Tower or custom landing zones, you will write custom Config rules, custom SCPs, and custom remediation automation for your specific requirements. Plan for that work from the start rather than treating it as an exception.
