Landing Zone Accelerator vs CDK Landing Zone: Who Owns It?

If you've read anything about AWS Landing Zone Accelerator (LZA), you already know it's built with the AWS Cloud Development Kit. So is the landing zone we build and operate for clients. Same underlying technology, two different operating models: one ships as an AWS-maintained pipeline you drive through YAML, the other lives as TypeScript in your own repository.

"Built with CDK" doesn't answer the question that actually matters here: who owns the config, who reviews a change before it deploys, and who decides when the next version lands. I build and maintain a CDK-native landing zone, so I'll walk through what LZA actually deploys, where it earns its reputation fairly, where practitioners report it breaking down, and how to decide which model fits your team.

LZA vs a CDK Landing Zone: The One-Sentence Answer

Landing Zone Accelerator and a CDK landing zone are both AWS CDK applications; the difference is that LZA's CDK source belongs to AWS and a CDK landing zone's source belongs to you.

Each row expands below. Start with what LZA actually deploys, since that's the half of this comparison most searches arrive already confused about.

What Landing Zone Accelerator Actually Deploys

LZA is an AWS Solutions Implementation: a CDK application AWS wrote, packaged, and maintains, that you install into your own account and drive through configuration rather than code. Two things get confused with it. "AWS Landing Zone" was a separate 2018 solution that AWS now keeps in long-term support rather than developing; LZA is the CDK-based path forward. And LZA isn't a Control Tower competitor, it's built to run alongside Control Tower, which is its own comparison this article won't re-litigate.

LZA deploys as two separate CodePipeline pipelines, deliberately decoupled. The Installer pipeline pulls LZA's source from AWS's GitHub repo and deploys the Core pipeline, which does the real work: 10 named stages (Source, Build, Prepare, Accounts, Bootstrap, an optional Review, Logging, Organization, Security_Audit, and a multi-part Deploy stage covering networking, security, and customizations). Initial deployment for a minimal configuration takes about 45 minutes; ongoing workload-related deployments typically run 45-90 minutes.

You never touch that pipeline's CDK code directly. Instead you edit eight YAML files (six mandatory, two optional), stored in a config repo (CodeCommit, S3, or a connected third-party repo):

LZA supports JSON Schema validation and IDE autocomplete for these files, which catches structural errors before a commit, not after a pipeline run. That's a real, useful safety net. It just isn't the same as writing and testing the underlying logic yourself.

What Landing Zone Accelerator Gets Right

The compliance coverage is the strongest argument for LZA. Its current Universal Configuration maps controls to NIST 800-53 Rev5, HIPAA, SOC 2, CMMC Level 2, ISO/IEC 27001, NIST CSF 2.0, CIS Critical Controls v8, and Germany's C5:2020, alongside dedicated reference configs for DISA SCCA, Spain's ENS, UK NCSC guidance, and healthcare. Assembling that mapping by hand, control by control, would take a platform team months. AWS is explicit that this doesn't finish the job for you: "This solution will not, by itself, make you compliant. It provides the foundational infrastructure from which additional complementary solutions can be integrated." Treat LZA as a documented starting point, not a compliance certificate.

Layered on top of Control Tower, which AWS recommends as the base wherever Control Tower is available, LZA also gives you fast initial account and OU provisioning through a genuinely no-code console flow, with AWS Support behind the whole stack. In partitions where Control Tower isn't offered, LZA runs in Organizations-only mode instead.

That combination is the right answer for a specific reader: a team without in-house CDK or platform engineering expertise, working in a regulated industry or GovCloud, that needs a broad, pre-mapped compliance baseline running now and is willing to operate inside AWS's schema and release cadence to get it. If that's your team, the friction described next may still be worth it for what LZA hands you on day one.

Where the Config You "Own" Stops Being Yours

AWS's own FAQ language describes LZA as giving you "full access to the infrastructure as code (IaC) solution." Practitioners who've actually run it describe something narrower. In a January 2026 r/aws thread comparing LZA to CfCT and AFT, one commenter put it bluntly: "I know that you are supposed to be able to do some customisation via the config files, but per the diagram it seems [to] indicate that these are stored in AWS's git. Not yours." Another, in the same thread: "It does nothing special, and it is an opinionated wrapper that doesn't like you messing around with what it does even the slightest (or you get the 'reset landing zone' error message on your Friday afternoon)."

customizations-config.yaml is the closest thing to an escape hatch, and it's narrower than it sounds. AWS Public Sector states its purpose directly: "the purpose of customizing the LZA is to extend your landing zone and cloud foundations capabilities, not to deploy your actual workloads." Updating a customization also requires bumping a runOrder property to force redeployment, an implementation detail you have to know to make a change take effect at all. What it does deploy are ordinary CloudFormation stacks and StackSets whose templates you author and version yourself, so that work isn't trapped. What stays closed is the accelerator itself: AWS doesn't document a way to import LZA's own CDK constructs into your app, so you extend LZA from the outside rather than building on it.

Pipeline opacity compounds this. A separate, older r/aws thread describes what happens when something goes wrong: "The pipeline for rolling the changes out is really slow... it breaks with indecipherable warnings, that require you to go in and tear down each cfn stage in reverse order, for x accounts provisioned." That's a materially different debugging experience than a failed CI job pointing at a specific assertion.

Excalidraw diagram loading.

That friction is exactly what changes when the landing zone is code your own team writes and merges.

What Changes When the Landing Zone Is Code You Own

Three mechanics change once the landing zone is TypeScript your team merges. Our own CDK Landing Zone is the working example here.

Every change is a pull request. cdk diff shows exactly which resources a change touches before anything deploys, and CI runs template assertions (Template.hasResourceProperties, resourceCountIs) against the synthesized CloudFormation, so a broken SCP or a mistargeted StackSet fails the build instead of surfacing as a pipeline error days later. LZA's equivalent, the CDK-diff-plus-approval Review stage, exists but is opt-in and off by default; here it's how every change ships, not a stage a team has to remember to enable. That commit history doubles as change-control evidence on your account structure, which matters more than it sounds when your SOC 2 clock starts the day your controls go live.

StackSets you target yourself. Which baselines deploy, and to which OUs, accounts, and regions, is a createStackSet call in a stack file your team edits directly, not a schema field mediated by someone else's pipeline. You can set rollout concurrency and failure tolerance per StackSet, so a failure in one account doesn't have to stop a baseline rollout to the rest of the organization, the same kind of control LZA's own underlying CloudFormation StackSets integration exposes but doesn't surface in its YAML.

Service control policy (SCP) quota violations fail at cdk synth, not mid-deploy. AWS Organizations allows up to 10 SCPs per attachment point and 10,240 characters per document; exceed either and a CDK landing zone's synth step fails immediately, before a single AWS API call, with a warning once you're within two attachments or approaching the size limit. That's a sharper failure mode than a config mistake surfacing partway through a pipeline run across dozens of accounts, and it's worth knowing how SCPs actually evaluate before you start packing them.

None of this is zero-code, and it shouldn't be sold as such. It assumes CDK and TypeScript familiarity your team either already has or wants to build. For a platform team without that background, the trade favors LZA's managed schema; for a team that already reviews infrastructure changes through pull requests, this is closer to how the rest of your stack already works.

Then there's the upgrade path, which most teams evaluate once during adoption and then live with for years.

Upgrades: AWS's Release Cadence vs Your Own Schedule

LZA ships on a roughly 2-4 week cadence: v1.15.3 through v1.16.0 all landed between May and July 2026. The standard upgrade is mechanically simple: point the AWSAccelerator-InstallerStack at the new release's CloudFormation template, change its Branch Name parameter to the target release branch, and update the stack. That triggers the Installer pipeline, which invokes the Core pipeline automatically, and completes in about 10 minutes for the stack update plus 20-60 minutes for the pipeline run. But "simple" doesn't mean "risk-free."

The v1.16.0 release notes, published July 29, 2026, document exactly why. That release introduces a new module-orchestration framework that reconciles live Transit Gateway associations and propagations to match network-config.yaml exactly on first run after upgrade. Any association not declared in that file, including ones created manually, gets torn down. AWS's own release notes warn this "can remove routing between attached VPCs and shared/egress/endpoint or on-premises networks and cause a connectivity outage." The documented mitigation is either declaring everything in the config file before upgrading, or setting an environment variable that resets on every subsequent redeploy. The same release also requires an SCP update for external-pipeline deployments, since new resource names use a different prefix than existing SCP patterns expect.

A CDK landing zone's upgrade path is a version bump, not a pipeline event: bump the two pinned package versions in .projenrc.ts, run pnpm exec projen to regenerate project files, review the git diff, then deploy. Nothing reconciles live infrastructure against a config file behind your back. You choose when the upgrade runs, and cdk diff shows you what it changes before it touches anything.

The two models also bill differently, and on one side the number is public.

What Each Option Actually Costs to Run

AWS publishes its own sample-configuration estimate for LZA: $430.22 per month, for a non-critical sandbox with Control Tower enabled and no workload activity, in US East (N. Virginia). The two largest line items are VPC ($175.35, driven by Transit Gateway attachments and VPC endpoints) and CloudTrail ($99.00). The rest spreads across KMS, Config, Security Hub, GuardDuty, and smaller services.

That's what this sample configuration costs before a single workload runs, not a floor every deployment pays: skip the Transit Gateway attachments and VPC endpoints and the figure drops substantially. From there it scales with governed accounts and regions, more CloudTrail events, more Config items, more Transit Gateway attachments. AWS is explicit that "there are no additional charges or upfront commitments... you pay only for AWS services turned on." Real-world reports from a January 2026 r/aws thread show that baseline can move fast: one commenter reported it's "very easy to enable a service which suddenly costs your org an extra $400 a month," and another described "a bug where one lambda function invocated too many times resulting [in a] 2k USD bill for one lambda alone."

There's no published sample-config figure for a CDK landing zone, so here's the real one instead: what the landing zone I run actually bills on a live AWS organization with 9 member accounts, measured from usage rather than estimated from a template.

Two caveats before anyone puts $175.37 next to $430.22. These aren't the same scope: AWS's sample config deploys a Transit Gateway networking layer with VPC endpoints, which is $175.35 of its total on its own, and this organization doesn't run one. And these are steady-state prices, after any introductory free tier has expired.

The more useful read is the second half of the table. Inspector code scanning alone accounts for about $74 of that $112.80; standard Lambda scanning plus ECR is roughly $38.40, which puts the whole landing zone at $100.97/month with code scanning off. Every line in that optional block is a switch: Inspector bills by coverage hours, GuardDuty's protection plans toggle individually, Macie's per-bucket charge prorates daily. Turn one off and the accrual stops that day, not at the next release.

That's the structural point underneath both tables. You pay only for the AWS services you decide to enable, and because every change is a pull request, cdk diff shows you exactly which resources a change adds before it merges, not after next month's bill arrives.

Put the ownership, upgrade, and cost pictures together, and the decision comes down to a short list of questions about your own team.

Choosing Between LZA and a CDK Landing Zone

Both sit on top of the same underlying primitives, and both are frequently paired with AWS Control Tower, which provides the console-managed guardrail layer either one can extend; that comparison is covered separately. If your organization is Terraform-first rather than CDK-first, Customizations for Control Tower (CfCT) and the Account Factory for Terraform (AFT) are AWS's native paths for that stack; both, along with LZA, get the fuller treatment in the wider survey of Control Tower alternatives.

Frequently Asked Questions

Key Takeaways

Both LZA and a CDK landing zone are CDK underneath, so "built with CDK" was never the real question. The one that matters is who owns the config, who reviews a change, and who decides when the next version lands. LZA's genuine strength is a broad, pre-mapped compliance baseline for teams without in-house platform expertise, delivered through a schema AWS maintains. A CDK landing zone's genuine strength is a foundation your team can test, diff, and review the same way it already reviews application code, with no schema ceiling to hit.

Upgrades and cost are where this stops being philosophical: LZA's release cadence can require pre-upgrade config changes with a documented outage risk if skipped, and its pipeline-first workflow means cost-relevant changes often surface on next month's bill rather than in a diff. If your team already runs a PR-review culture, that gap is the strongest signal to look at owning the landing zone directly. If you want the fuller five-tool survey first, including CfCT and AFT, the Control Tower alternatives breakdown covers all of them, and if you're weighing what a completed, audit-ready build looks like end to end, Accolade's landing zone case study walks through one.