AWS Control Tower vs AWS CDK Landing Zone: Own or Delegate?

If you searched for "AWS Control Tower vs CDK Landing Zone," you're really deciding one thing: who controls your AWS foundation. Control Tower is a managed service. AWS owns the implementation, and you turn the knobs it exposes. A CDK landing zone flips that: your account structure, guardrails, and baselines are TypeScript in your own repository, and changes ship the way application code ships, through a pull request, a diff, and a pipeline.

That difference sounds philosophical until the first time you need a guardrail Control Tower doesn't offer, or you want to see what a change does before it hits every account in your organization. Then it becomes very practical.

I build and maintain a CDK-native landing zone, so I'll show you concretely what owning the code buys you, where Control Tower is still the right choice, and how to decide.

AWS Control Tower vs CDK Landing Zone: What's the Difference?

Control Tower provisions a Root, a Log Archive account, and an Audit account, applies mandatory guardrails, sets up IAM Identity Center, and gives you Account Factory for new accounts. It does all of this through CloudFormation StackSets under the hood. Before landing zone version 4.0 (November 17, 2025) the Security OU was mandatory; as of 4.0 it's optional, and the Config, CloudTrail, Security Roles, and Backup integrations can each be toggled independently. AWS still advertises its Control Catalog as 750+ managed controls mapped to over ten compliance frameworks, though after the late-2025 additions (279 Config-based controls in November, 176 Security Hub controls in December) the real total is likely past 1,000.

A CDK landing zone builds the same kind of foundation, an AWS Organization with OUs, SCPs, account baselines, and security services, but as CDK source code you own. It uses the same native AWS::Organizations::* resources and the same StackSets Control Tower uses internally. The difference isn't the primitives. It's that the code defining your organization sits in your repository, where you can read it, change it, test it, and review it.

One naming trap to avoid: AWS also ships a tool called Landing Zone Accelerator (LZA), which is built with CDK but delivered as an AWS-maintained product you drive through YAML configuration files, layered on top of Control Tower. It solves a different problem and deserves its own comparison; this article is about Control Tower versus a landing zone whose source code your team owns. If you want the wider tool survey, the breakdown of Control Tower alternatives covers LZA, CfCT, and AFT in depth.

Excalidraw diagram loading.

If the relationship between Control Tower and Organizations itself is fuzzy, read how Control Tower builds on AWS Organizations first.

What Control Tower Does Well

Let's be fair to Control Tower first, because for some teams it's exactly the right answer.

It's the fastest path to a compliant, zero-code baseline: one console flow, no infrastructure code to write, and AWS curates the control catalog for you, work that's genuinely hard to replicate with a small platform team. There's no charge for the service itself; you pay only for the AWS services it enables. And landing zone 4.0 made it meaningfully more modular, so if you last evaluated Control Tower before late 2025, check the 4.0 release notes before trusting your old impression.

Control Tower fits teams without existing SCP or OU investment, and platform teams of one or two people who want AWS to own guardrail maintenance. It's also the pragmatic answer when a compliant multi-account structure has to be running this week.

Where Control Tower Stops: Knobs, Not Code

Here's the structural limit that no version update changes: Control Tower customization means choosing between AWS-defined options. You can enable a control, disable a control, or toggle a service integration. You cannot write your own logic, and, more importantly, you cannot test or validate a change before it applies to your live organization. There's no diff, no dry run, no staging environment for your account structure. You flip the toggle and observe the result in production.

For a team that reviews every application change through a pull request, that's a strange gap: the most consequential infrastructure you run, the organization itself, is the one thing you can't put through review.

The other limits are worth checking against your own numbers:

• Scale ceilings. Control Tower supports up to 10,000 accounts, and accounts multiplied by governed Regions can't exceed 150,000. SCPs are capped at 10 per OU (raised from 5 in May 2026). Verify against Control Tower's documented limits, since older guidance still cites the lower numbers.
• One landing zone per Organization. No per-team or per-environment flexibility.
• AWS Config costs. Config bills per configuration item recorded, and AWS's own documentation warns that ephemeral workloads in Control Tower accounts can drive an unexpected increase in Config costs. The 4.0 optional Config integration mitigates this, but turning it off also disables Security Roles, Identity Center, and Backup together.
• Existing organizations aren't governed retroactively. Only OUs and accounts you explicitly register or enroll come under Control Tower's control.

Weighing these limits takes some SCP fluency; how SCPs actually work covers the evaluation logic if you need it.

What You Get When the Landing Zone Is Code

Owning the landing zone as CDK changes specific things about how your team operates. I'll walk through them using our own CDK Landing Zone as the working example.

Every change is tested before it ships

This is the single biggest difference in practice. A guardrail change in a CDK landing zone is a branch, not a toggle. cdk diff shows you exactly which resources a change touches before anything deploys. Template assertions (Template.hasResourceProperties, resourceCountIs) run in CI against the synthesized CloudFormation, so a broken SCP or a mistargeted StackSet fails the build instead of failing the organization. A teammate reviews the pull request. And if something still goes wrong, git revert is your rollback.

If a SOC 2 or ISO 27001 auditor wants a reviewable change log on your account structure, this workflow is that evidence, produced as a side effect of how you already work. Why compliance evidence timing matters covers that angle in detail.

StackSets do the heavy lifting, in parallel

CloudFormation StackSets are the most underrated deployment primitive on AWS, and they're the engine of this architecture. A single StackSet template deploys simultaneously to multiple accounts and multiple regions. Change a baseline once, and the rollout fans out across your organization in parallel instead of account by account; a baseline StackSet rollout typically completes in 5 to 10 minutes.

Our landing zone ships nine StackSets that roll out the full account baseline: secure defaults (default VPC removal, EBS encryption, S3 Block Public Access, hardened security groups, password policy), the organization-wide CloudTrail trail with CIS alarms, centralized root access so member accounts hold no standalone root credentials, cost controls with budget and anomaly alerts, CDK bootstrap for workload accounts, service quota automation, and the unified security services (Security Hub, GuardDuty, Inspector, Macie), wired to a delegated security account so each service turns on with a single options-block flip.

The service-managed permission model is what makes account provisioning hands-off: StackSets target OUs, so every account that joins a targeted OU receives the entire baseline automatically. No enrollment step, no per-account setup. And multi-region is a configuration value, not a project: add a region to secondaryRegions and the multi-region StackSets deploy there on the next pipeline run, while the region-guardrail SCP updates its allow list to match.

Control Tower uses StackSets internally too. The difference is that here you control the templates, the targets, and the regions directly: which StackSets deploy, and to which OUs, accounts, and regions, is a createStackSet call in a stack file you can edit and review like any other code.

The baseline is also measured, not just promised: an account provisioned this way scores 100% on the CIS AWS Foundations Benchmark and 96% on AWS Foundational Security Best Practices in Security Hub, and those two benchmarks cover the infrastructure controls SOC 2, HIPAA, and PCI-DSS audits ask about. Control Tower can reach a strong score too, but you assemble it yourself from the control catalog; here the baseline that produces those scores arrives as code and deploys through the pipeline you just reviewed.

Customization has no ceiling

With Control Tower, your customization space is the list of options AWS shipped. With a CDK landing zone, it's everything CloudFormation and CDK can express. Need a stricter SCP, a different OU layout, an extra baseline for a new compliance requirement, or a company-specific control no vendor thought of? You write TypeScript and ship it through the same pipeline, the same day. Nothing about your governance waits on an AWS roadmap.

That extends to the baseline itself: retarget a StackSet to different OUs, add regions, disable a component you don't want, or compose your own constructs alongside the 24 account-baseline constructs that ship with the product. Since every component is toggleable, the AWS services generating charges in your organization are the ones you decided to run, a real contrast with the default-on Config recorder behind Control Tower's cost warnings.

The operational plumbing is already solved

The parts that make platform teams grind (deployment credentials, single sign-on, drift, upgrades) come solved:

• Pipeline security. Deployment runs through GitHub Actions with OIDC. No long-lived AWS keys exist anywhere, and every change enters through a pull request.
• Single sign-on. The deployment sets up IAM Identity Center so your team can connect an existing identity provider, whether that's Entra ID, Okta, or Google Workspace, and manage who reaches which account in one place.
• Drift detection. A daily CloudFormation drift check runs across the management and landing zone accounts and flags anything that deviates from the version-controlled baseline. It's the same drift API you already use for application stacks, not a separate landing-zone-specific mechanism to learn.
• Upgrades on your schedule. Improvements ship as package releases: bump two pinned versions, run pnpm exec projen, redeploy. You decide when, and cdk diff shows you what the upgrade changes before you apply it. Compare that with Control Tower, where AWS decides when a landing zone version update lands.

The deployment itself is a two-phase sequence: an organization stack in the management account creates the Organization, OUs, accounts, and SCPs, then a dedicated landing zone account, registered as the StackSets delegated administrator, deploys the foundation and account-provisioning stacks.

None of this is zero-code, and it shouldn't be sold as such. It assumes CDK and TypeScript familiarity your team either has or wants to build, and the initial deployment is a deliberate two-account sequence rather than a single console click. For what the end state looks like once a team pushes through that, read Accolade's landing zone case study: they went through exactly this build on their way to SOC 2.

Control Tower vs CDK Landing Zone: Side by Side

How to Decide

Run through this with your own team, not a generic maturity model:

• Platform team of one or two, no CDK experience, no governance debt? Control Tower. The curated controls are worth more to you than code ownership, and you can genuinely be running this week.
• Do you already review every production change through a PR? Then the console-toggle model will chafe quickly, because your most critical infrastructure becomes the only thing exempt from review. That's the strongest signal to own the landing zone as code.
• Is an auditor already asking for change-control evidence on your account structure? A CDK landing zone produces that evidence as a byproduct. Retrofitting it onto console operations is manual work forever.
• Already running CDK for applications? The runway to a CDK landing zone is short: same language, same diff-and-assert workflow, same pipeline patterns, now applied to the organization itself.
• Expecting multi-region or fast account growth? This is where StackSets ownership pays off most: parallel rollout, automatic baselines for new accounts, and regions added through configuration.

A few more questions come up every time this decision gets discussed.

Frequently Asked Questions

Key Takeaways

Control Tower and a CDK landing zone aren't two products fighting over the same job. One is a managed service where AWS owns the code and you operate the toggles; the other makes your organization's foundation a codebase your team tests, reviews, and rolls out on its own schedule.

Worth carrying forward: landing zone 4.0 (November 2025) made Control Tower more modular, so evaluate today's version, not an old mental model. Control Tower's hard edges are structural and knowable in advance: console-first customization, no way to validate a change before it applies, scale ceilings, and one landing zone per Organization. And StackSets are the piece most teams underestimate: owning them directly is what turns a baseline change into one reviewed commit that rolls out in parallel across every account and region you govern, landing with the CIS and Security Hub scores your auditor will ask about already in place.

If the PR-reviewed model fits how your team already works, start with how the CDK Landing Zone deploys and operates. If you want the wider survey of AWS-native options first, including LZA, CfCT, and AFT, the Control Tower alternatives breakdown covers all five.