AWS Control Tower Alternatives: CDK Landing Zone, LZA, CfCT, AFT & OrgFormation Compared

If you're evaluating AWS Control Tower alternatives, you've probably already felt the frustration. The HackerNews verdict ("friends don't let friends use Control Tower") has over 900 upvotes for a reason.

I've built production CDK landing zones for enterprise clients at Towards the Cloud and hit the same walls: guardrails you can't customize through code, account vending that requires human approval, and a console that fights you every time you want to treat infrastructure as software.

Most "alternatives" roundups cover only three tools, miss CfCT and AFT entirely, and conflate AWS-native governance tools with cross-cloud CSPM products like Wiz and Prisma Cloud. This guide covers all five: CDK Landing Zone (my top recommendation), LZA, CfCT, AFT, and OrgFormation, with code examples, real operational constraints, and a decision framework.

Excalidraw diagram loading.

If you're unfamiliar with the foundation, start with what an AWS Landing Zone is or review AWS Control Tower vs AWS Organizations for context on how they relate.

Why Teams Leave AWS Control Tower

The limitations that actually cause teams to look elsewhere are concrete, not vague.

The ClickOps Management Problem

Making changes to your landing zone structure means clicking through the Control Tower console, not committing a pull request. SCPs are configured via the guardrail UI, not code. Account Factory runs through Service Catalog forms, not Terraform modules. The result is a ClickOps vs IaC problem: your workload infrastructure is version-controlled in CI/CD, but the foundation it runs on is managed by point-and-click.

SCP Slot Exhaustion and the Guardrail Drift Problem

In May 2026, AWS doubled the Service Control Policy quota: Organizations now allows 10 SCPs per node and 10,240 characters per SCP. But Control Tower's landing zone still enforces a cap of 5 SCPs per OU. Layer Control Tower guardrails on top of custom compliance SCPs (blocking regions, restricting S3 public access, enforcing MFA) and you hit that ceiling fast.

Guardrail drift is a separate issue. August 2025 resolved two cases: SCPs applied to managed OUs or member accounts via Organizations no longer trigger drift. But modifications made outside the Control Tower console in other ways still cause drift, and reconciling it requires going back through the console rather than running cdk deploy.

Account Vending Latency via Service Catalog

Control Tower's Account Factory uses Service Catalog, which is unavailable in four newer regions (Calgary, Malaysia, Thailand, Mexico Central) and introduces approval steps that can't be bypassed without custom automation. For teams running a multi-account strategy at scale, every manual touchpoint is a bottleneck.

What Control Tower Still Does Well

Control Tower v4.0 (November 2025) made real improvements: Config, CloudTrail, and Backup integrations are now optional, the Security OU is no longer required, and a "Controls-Only" experience lets you adopt managed controls without a full landing zone baseline. Control Tower now manages 750+ controls in Control Catalog with mappings to 10 compliance frameworks including FedRAMP, NIST-CSF, PCI-DSS, and SOC 2. For teams that want a managed service with built-in compliance coverage and don't need deep IaC customization, v4.0 is a meaningfully better product than it was 18 months ago.

Two Categories of "Alternatives": Only One Applies Here

Software review sites list Wiz, Prisma Cloud, and Microsoft Defender for Cloud as Control Tower alternatives. They're not. They're Cloud Security Posture Management (CSPM) tools that govern security posture across multiple cloud providers. They don't replace Control Tower's account vending, OU governance, or SCP enforcement.

The five tools in this post are all AWS-native, operating within AWS Organizations to manage accounts, OUs, SCPs, and baseline resources. A CDK Landing Zone or LZA deployment can have Wiz layered on top. They solve different problems and aren't mutually exclusive.

All Five AWS-Native Alternatives at a Glance

Here's the full comparison across all five tools. The rows that matter most for your first decision are Control Tower Dependency and IaC Framework. Those two rows will eliminate at least two options immediately.

Side-by-Side Comparison Matrix

How to Read This Table

Control Tower Dependency is the first filter. Want to escape Control Tower entirely? Cross AFT and CfCT off immediately: both require an existing landing zone. CDK Landing Zone and OrgFormation are fully CT-independent. LZA runs standalone only for GovCloud, Secret Region, or Top Secret Region.

Diff/preview support separates tools that show what will change from those that execute blind. CDK Landing Zone gives you cdk diff. AFT gives you terraform plan. OrgFormation, CfCT, and LZA commit without a preview. For SCP and OU changes, that's a meaningful operational risk.

Compliance frameworks built-in determines whether you need NIST, HIPAA, or SCCA coverage out of the box (LZA only) or build your own governance controls (everyone else). A federal compliance deadline may make this row the deciding factor.

Alternative 1: CDK Landing Zone (Custom IaC Pattern, Recommended)

CDK Landing Zone is not an AWS product, a managed service, or a framework with a version number. It's an architectural pattern: use native AWS CDK to manage Organizations resources, then use CloudFormation StackSets for cross-account deployments. You own everything. No upstream release schedule controls your ability to make changes. This is also distinct from the original "AWS Landing Zone Solution" from 2018 (deprecated) and from LZA (its 2022 successor). It's the same pattern I use at Towards the Cloud for production enterprise deployments.

What CDK Landing Zone Actually Is (and Is Not)

Two components. First, CDK manages AWS Organizations resources directly (OUs, accounts, and Service Control Policies) using programming languages instead of console clicks or YAML. Second, CloudFormation StackSets deploy baseline resources across all accounts in those OUs automatically. When an account joins an OU, StackSets fire. When you need new behavior, you write code and run cdk deploy.

Native CDK for Organizations Management

import * as cdk from 'aws-cdk-lib';
import * as organizations from 'aws-cdk-lib/aws-organizations';

// Create organizational units
const productionOu = new organizations.CfnOrganizationalUnit(this, 'ProductionOU', {
  name: 'Production',
  parentId: root.id,
});

const developmentOu = new organizations.CfnOrganizationalUnit(this, 'DevelopmentOU', {
  name: 'Development',
  parentId: root.id,
});

// Create accounts in specific OUs
new organizations.CfnAccount(this, 'ProductionAccount', {
  accountName: 'prod-workload-01',
  email: 'prod-workload-01@example.com',
  parentId: productionOu.attrId,
});

Version-controlled, code-reviewed, testable. Need 50 accounts following a naming convention? Write a loop. With LZA, copy-paste 50 YAML entries. You can implement production-ready SCP examples using the same CDK patterns.

CloudFormation StackSets: Automatic Account Provisioning

import * as stacksets from 'aws-cdk-lib/aws-cloudformation';

new stacksets.CfnStackSet(this, 'BaselineStackSet', {
  stackSetName: 'account-baseline',
  permissionModel: 'SERVICE_MANAGED',
  capabilities: ['CAPABILITY_NAMED_IAM'],
  autoDeployment: {
    enabled: true,
    retainStacksOnAccountRemoval: false,
  },
  stackInstancesGroup: [{
    deploymentTargets: {
      organizationalUnitIds: [productionOu.attrId, developmentOu.attrId],
    },
    regions: ['us-east-1', 'eu-west-1'],
  }],
  templateBody: baselineTemplate.templateJson,
});

Add an account to an OU, it gets the baseline automatically. Move an account between OUs, StackSets update accordingly. When a deployment fails, check CloudFormation stack events (standard troubleshooting):

# View StackSet operation status
aws cloudformation describe-stack-set-operation \
  --stack-set-name account-baseline \
  --operation-id abc123

# View failed stack instance details
aws cloudformation describe-stack-instance \
  --stack-set-name account-baseline \
  --stack-instance-account 123456789012 \
  --stack-instance-region us-east-1

Deployment Speed: 5-10 Minutes vs. 45+ Minutes

StackSets deploy baseline resources in 5-10 minutes. LZA's pipeline runs 45+ minutes through 11+ stages, a difference that compounds during incident response and governance iteration. Dynamic account creation in CDK, which LZA's YAML can't do natively:

// Dynamic account creation based on environment config
environments.forEach(env => {
  new organizations.CfnAccount(this, `${env.name}Account`, {
    accountName: env.accountName,
    email: env.email,
    parentId: env.ouId,
  });
});

Production-Ready StackSet Catalog

A full CDK Landing Zone ships 12 StackSets across three areas: Security and Compliance (AWS Config, CloudTrail, GuardDuty, Security Hub, Log Archive, Secure Defaults for default VPC deletion + EBS encryption + S3 Block Public Access + password policies, and Central Alerts for SNS notifications); Account Provisioning and Management (CDK Bootstrap, Provision Management for one-time management-account setup and drift detection, and TTC Access for third-party IAM role); Operations and Cost (Cost Control with budgets and anomaly detection, Service Quotas automation). Each deploys automatically when accounts join OUs.

Beyond StackSets: SCPs, OIDC, and Lifecycle Automation

A production CDK Landing Zone splits into three deployable stacks: an OrganizationStack that creates OUs, accounts, and SCPs (and publishes their IDs to SSM Parameter Store for downstream consumption); a LandingZoneFoundationStack that provisions StackSet roles, the centralized log archive bucket, central alert SNS topics, and one-time management-account configuration; and a LandingZoneAccountProvisioningStack that fans out repeatable security, compliance, and operations resources across member accounts.

On top of the 12 StackSets, four capabilities round out the foundation:

Baseline SCPs shipped as code. Four governance policies deploy with the organization: CriticalSecurityGuardrails at the root (deny LeaveOrganization, deny iam:CreateUser/CreateAccessKey, deny disabling EBS encryption by default, protect the password policy from non-deployment roles), DenyAllOutsidePrimaryAndSecondaryRegions for regional sovereignty with explicit exemptions for global services and StackSet roles, ProtectSecurityServices to stop member accounts from disabling GuardDuty/Config/CloudTrail/Security Hub, and LockdownSuspendedAccounts as the kill switch for any account moved to the Suspended OU.

GitHub Actions OIDC for keyless CI/CD. The OrganizationStack provisions the GitHub Actions OIDC identity provider and a scoped deployment role, so the CDK pipeline assumes a role via OIDC instead of using long-lived access keys.

Account lifecycle automation. EventBridge-triggered Lambdas delete the default VPC, set alternate security/billing/operations contacts, and unsubscribe the root email from AWS marketing on new account creation. When an account moves to the Suspended OU, another Lambda calls the AWS account-close API. A daily EventBridge rule runs StackSet drift detection across the organization.

Both StackSet permission models used correctly. Service-managed StackSets target OUs for member-account rollouts. Self-managed StackSets cover the management account (which service-managed StackSets cannot reach). Role bootstrapping and ordering are handled by the framework, not by hand.

Security Hub deploys with a centralized organization-wide configuration policy that enables AWS Foundational Security Best Practices v1.0.0 and the CIS AWS Foundations Benchmark v1.2.0 ruleset, with a small set of low-signal controls explicitly disabled (CloudTrail.2, IAM.6, IAM.18, Macie.1, and four GuardDuty controls) to keep the findings queue actionable rather than noisy.

The Build Cost: What You Give Up for Full Control

CDK Landing Zone trades initial effort for long-term flexibility. There's no "deploy Control Tower alternative" button. For teams that need a compliance-ready foundation by next quarter, LZA or CfCT may be more practical. For teams that want the benefits without the build time, check the public roadmap or explore our CDK Landing Zone service.

When CDK Landing Zone Is the Right Choice

CDK Landing Zone fits when your team has strong AWS expertise, prefers programming languages over YAML, and prioritizes long-term flexibility. The Towards the Cloud implementation arrives compliance-complete out of the box: 100% on the CIS AWS Foundations Benchmark, 96% on AWS Foundational Security Best Practices via Security Hub, plus GuardDuty, CloudTrail, AWS Config, centralized logging, and encrypted SNS, all deploying automatically through 12 StackSets. It's a natural fit for teams building toward SOC 2 compliance because every control maps to an auditable CDK construct.

The two scenarios where it's not the right choice: you need GovCloud, Secret, or Top Secret Region deployment (LZA standalone is the only option there), or you're already on Control Tower and just need a lightweight customization layer rather than a full IaC foundation.

Alternative 2: AWS Landing Zone Accelerator (LZA)

Landing Zone Accelerator (LZA) is AWS's open-source CDK-based solution for highly regulated workloads. AWS's official position: "We recommend that you deploy AWS Control Tower as your foundational landing zone, and then enhance your landing zone capabilities with LZA, as needed." LZA is the enhancement path for commercial environments, not the replacement path. For GovCloud, Secret Region, and Top Secret Region where Control Tower is unavailable, LZA operates in Organizations-standalone mode.

Framework-Heavy Despite CDK Foundation

LZA uses CDK internally but surfaces a configuration-driven interface. You maintain YAML files, and when they change, you release the CodePipeline, which runs through 11+ stages. The trade-off: broad coverage across 35+ AWS services without writing custom CDK, but you're a configuration consumer, not a code owner.

The Seven Configuration Files

LZA splits configuration across: accounts-config.yaml, global-config.yaml, iam-config.yaml, network-config.yaml, organization-config.yaml, security-config.yaml, and customizations-config.yaml. Here's what OU and account configuration looks like in practice:

organization-config.yaml:

organizationalUnits:
  - name: Security
    ignore: false
  - name: Infrastructure
    ignore: false
  - name: Workloads
    ignore: false
    organizationalUnits:
      - name: Production
      - name: Development

serviceControlPolicies:
  - name: DenyS3PublicAccess
    description: Prevents making S3 buckets public
    policy: path/to/scp-deny-s3-public.json
    type: customerManaged
    deploymentTargets:
      organizationalUnits:
        - Workloads/Production

accounts-config.yaml:

workloadAccounts:
  - name: prod-workload-01
    description: Production workload account
    email: prod-workload-01@example.com
    organizationalUnit: Workloads/Production

  - name: dev-workload-01
    description: Development workload account
    email: dev-workload-01@example.com
    organizationalUnit: Workloads/Development

Need to create 50 accounts following a naming pattern? Define each one as a YAML block. LZA doesn't support dynamic iteration.

LZA Standalone vs. LZA on Control Tower

For commercial environments, LZA is the enhancement layer, not a standalone replacement. The standalone mode exists specifically for GovCloud, Secret Region, and Top Secret Region where Control Tower is unavailable.

Real-World Operational Costs: Pipeline Duration and Baseline Spend

A non-production sandbox running the LZA sample configuration with Control Tower in us-east-1 costs approximately $430/month with no workload activity:

For small teams evaluating LZA, that sandbox cost is worth understanding before committing to the architecture.

LZA MCP Server: AI-Assisted Configuration (March 2026)

AWS launched an open-source LZA MCP Server in March 2026 with 20 specialized tools covering document search, configuration management, pipeline monitoring, and failure diagnostics. It's compatible with Kiro, Amazon Q Developer, and Claude Code. For teams already running LZA, this is a meaningful improvement to the configuration authoring experience.

Locked Out of CDK Constructs: The Fork Dilemma

LZA's CDK constructs are not yours to modify. When something doesn't behave the way you need, you either file a GitHub issue and wait, or fork the repository and maintain your own version of upstream changes. Teams hit config schema constraints or need behavior that doesn't exist yet. Instead of writing code, they wait.

Built-In Compliance Frameworks: NIST, HIPAA, PCI-DSS, CMMC, and DoD/SCCA

LZA's pre-built compliance coverage is where it genuinely differentiates: NIST 800-53, HIPAA, PCI-DSS, CMMC, DISA SCCA, DoD CC SRG for IL4 and IL5 workloads, and FedRAMP. It also automates delegated administrator setup for Security Hub, GuardDuty, Macie, Config, and Inspector. For federal agencies or healthcare organizations with an ATO deadline, LZA compresses months of custom implementation work.

When LZA Earns Its Complexity

LZA is the right choice when you need pre-built compliance frameworks for federal, healthcare, or financial services workloads with a deadline, or for GovCloud, Secret Region, and Top Secret Region deployments. Small teams without a federal compliance requirement will find the $430/month sandbox cost and 7-YAML configuration surface area are overhead that CDK Landing Zone avoids.

Alternative 3: Customizations for AWS Control Tower (CfCT)

CfCT is a free, open-source AWS Solutions package that extends a Control Tower landing zone with CloudFormation templates and SCPs, delivered through a CodePipeline that triggers automatically when Control Tower creates new accounts. Lighter than LZA by design: no networking, no security service toggles, no pre-built compliance frameworks. AWS documents CfCT as one of three co-equal active customization paths alongside AFT and LZA.

What CfCT Does: SCPs and StackSets via CodePipeline

When Account Factory creates a new account, Control Tower emits a lifecycle event. CfCT's EventBridge rule catches it, triggers a CodePipeline, and deploys your custom CloudFormation templates and SCPs to the new account and its OU:

region: us-east-1
version: 2021-03-15

resources:
  - name: baseline-iam-roles
    resource_file: templates/baseline-iam-roles.template
    deploy_method: stack_set
    deployment_targets:
      organizational_units:
        - Workloads/Production
        - Workloads/Development

  - name: deny-root-access-scp
    resource_file: policies/deny-root-access.json
    deploy_method: scp
    deployment_targets:
      organizational_units:
        - Workloads

Cost is approximately $3/month for 100 small pipeline builds, the lowest cost among all five options.

What CfCT Cannot Do (No Account Creation, No OU Management, No Security Service Toggles)

CfCT is a customization layer on top of Control Tower, not a replacement. Account creation still runs through Control Tower's Account Factory. OU structure is still managed through the Control Tower console. Security service enablement (GuardDuty, Security Hub, Macie) is not orchestrated by CfCT. Target OUs must also have AWSControlTowerBaseline enabled. CfCT cannot target OUs that aren't fully enrolled in Control Tower.

CfCT gained GitHub as a VCS source in December 2024 (previously CodeCommit or S3 only), and added Resource Control Policy (RCP) support in December 2024.

CfCT vs LZA: The Capability Gap in Plain Terms

Think of CfCT as the stepping stone and LZA as the full escalation path. CfCT deploys SCPs and CloudFormation, the governance basics. LZA adds VPC and Transit Gateway networking, orchestration of 35+ security services, and pre-configured compliance frameworks. If you need baseline SCPs applied consistently to every new account, CfCT is right. If you need SCCA compliance and hub-and-spoke networking with Network Firewall, LZA is where you need to be. CfCT is also the right stepping stone before LZA: start lightweight, then evaluate whether LZA's additional capabilities justify its cost as your requirements grow.

When CfCT Is the Right Starting Point

CfCT makes sense when you're already on Control Tower and want a lightweight, low-cost customization layer. It's a good fit for small platform engineering teams (1-2 people) who need consistent baseline configuration on new accounts but don't have a federal compliance deadline driving them toward LZA. CfCT is built for teams that are staying on Control Tower and want lightweight customization. AFT is for Terraform shops with the same starting point.

Alternative 4: Account Factory for Terraform (AFT)

Account Factory for Terraform (AFT) is an AWS-published Terraform module (github.com/aws-ia/terraform-aws-control_tower_account_factory, v1.15.0, July 2025, min Terraform 1.6.1) that brings GitOps-style account provisioning to a Control Tower landing zone.

AFT's GitOps Terraform Pipeline Model

Commit a Terraform account request file and the pipeline queues it in FIFO order at a default concurrency of 5:

module "account-request" {
  source = "./modules/account-request"

  control_tower_parameters = {
    AccountEmail              = "prod-workload-01@example.com"
    AccountName               = "prod-workload-01"
    ManagedOrganizationalUnit = "Workloads/Production"
    SSOUserEmail              = "admin@example.com"
    SSOUserFirstName          = "Platform"
    SSOUserLastName           = "Admin"
  }

  account_tags = {
    Environment = "production"
    Owner       = "platform-team"
  }
}

Commit to aft-account-request. The ct-aft-account-request CodePipeline triggers, provisions through Control Tower Account Factory, runs global then account-specific customizations, and assigns IAM Identity Center permission sets via Step Functions.

The Control Tower Hard Dependency: AFT Is Not a Replacement

AFT requires an existing Control Tower landing zone and uses Control Tower Account Factory for account enrollment. There is no exit ramp here. CDK Landing Zone and OrgFormation are the CT-independent options.

CodeCommit Deprecation: What New AFT Customers Must Know

AWS CodeCommit no longer accepts new repositories. New AFT customers must use GitHub, BitBucket, or GitLab via AWS CodeConnections, and they cannot deploy in the 13 regions where CodeConnections is unavailable, including Hong Kong, Cape Town, Bahrain, Jakarta, Hyderabad, Osaka, Israel, and UAE.

Regional Availability Gaps (13 Regions Blocked)

AFT is unavailable in 7 newer opt-in regions due to missing dependencies: Europe (Zurich), Europe (Spain), Canada West (Calgary), AP (Melbourne), AP (Malaysia), AP (Thailand), and Mexico (Central). If your primary region is on either list, AFT is off the table.

The Deprovisioning Gap

AFT provisions accounts and runs customizations at vending time, but has no native deprovisioning workflow. Closing an account requires either custom Lambda automation or the CDK Landing Zone lifecycle management approach. For organizations with high account churn (sandboxes, ephemeral environments), this gap becomes a real operational burden.

When AFT Is the Right Choice for Terraform Teams

AFT fits one profile: Terraform-native, already on Control Tower, wanting GitOps-style account provisioning. The terraform plan preview is a meaningful safety net over CfCT's execute-and-discover model. Rule it out if you want to leave Control Tower, if you're starting fresh, or if you're in a blocked region.

Alternative 5: OrgFormation

OrgFormation is a community-built infrastructure as code tool for managing AWS Organizations using CloudFormation templates and a custom CLI. No Control Tower dependency, no pipeline infrastructure required: just CloudFormation templates and the org-formation CLI. For teams standardized on CloudFormation who want to manage their Organizations structure as code without adopting CDK or standing up pipeline infrastructure, OrgFormation is the most direct path.

CloudFormation-Based with Custom CLI Framework

Organization:
  Root:
    Type: OC::ORG::MasterAccount
    Properties:
      AccountName: My Organization Root
      AccountId: '123456789012'
      RootEmail: root@example.com

  ProductionOU:
    Type: OC::ORG::OrganizationalUnit
    Properties:
      OrganizationalUnitName: Production
      Accounts:
        - !Ref ProductionAccount

  ProductionAccount:
    Type: OC::ORG::Account
    Properties:
      AccountName: Production Account
      RootEmail: production@example.com

All operations run through the custom CLI:

# Apply organization structure changes
org-formation update organization.yml

# Run cross-account tasks
org-formation perform-tasks tasks.yml

# Update cross-account stacks
org-formation update-stacks template.yml

This works. But you're learning and maintaining OrgFormation-specific workflows rather than standard AWS CLI commands. Compare that to cdk deploy.

The Missing Diff: Why "Hope for the Best" Is a Real Ops Risk

OrgFormation has no built-in preview of changes before execution. Unlike cdk diff (CDK Landing Zone) or terraform plan (AFT), you commit to the CLI and discover the impact from the result. For Organizations changes like OU moves, SCP attachments, and account assignments, that's a meaningful risk. A misconfigured SCP attached to a production OU takes effect immediately. Teams that have run into this describe it as "hope for the best" operations for anything touching production governance.

What OrgFormation Does Well

OrgFormation delivers real value for its target use case: Organizations management as code with version control and declarative syntax, cross-account CloudFormation deployment through its task-based system, and a free open-source tool with no pipeline infrastructure required. The community templates repository is a genuine asset, with shared patterns for common multi-account setups that you can adapt without building from scratch.

CloudFormation Template Size Limits in Practice

CloudFormation has a hard limit of 51,200 bytes for inline templates. For complex Organizations configurations with many accounts and cross-account resources, this ceiling becomes a real constraint. CDK scales better here, because programming language constructs, loops, and functions manage complexity that YAML templates can't express dynamically.

When OrgFormation's Trade-offs Are Acceptable

OrgFormation makes sense if your team is already standardized on CloudFormation, your requirements are straightforward, and you're committed to open-source tooling. The "no diff/preview" limitation is the main reason I don't recommend it for production use at scale. For a sandbox environment or a small organization with low SCP change frequency, it's workable. For a production multi-account environment where a misconfigured SCP has immediate blast radius, the missing preview step is a real risk.

Decision Framework: Choosing Based on Your Team Profile

Work through these five questions in order. Each one narrows the field.

1. Are you already on AWS Control Tower? If yes, you're choosing a customization layer, and CfCT and AFT are designed for this. CDK Landing Zone or OrgFormation require a full rebuild, not an incremental addition. If no (starting fresh), all five are on the table.

2. Is your team Terraform-native or CDK/CF-native? Terraform teams on Control Tower should look hard at AFT. CDK/CF teams on Control Tower should look at CfCT (lightweight) or LZA (comprehensive). Teams starting fresh: CDK teams point toward CDK Landing Zone. CF teams point toward OrgFormation. No strong preference? Default to CDK Landing Zone for long-term flexibility.

3. Do you have a federal, healthcare, or financial services compliance deadline? Two distinct paths. For GovCloud, Secret, or Top Secret Region workloads, LZA standalone is the only option because Control Tower is unavailable there. For commercial regulated workloads (DoD IL4/IL5, SCCA, FedRAMP High that benefits from AWS-maintained config), CT + LZA is the AWS-recommended path. For commercial SOC 2, HIPAA, or PCI-DSS workloads where you want production-grade IaC without framework lock-in, CDK Landing Zone delivers the same compliance posture (100% CIS, 96% Security Hub, GuardDuty, Config, CloudTrail centralized) and your controls remain auditable as code rather than as YAML config.

4. What is your team size? A 1-2 person platform team running CfCT at ~$3/month is well-matched. The same team running LZA at ~$430/month is over-invested. Larger teams (4+ engineers) with dedicated capacity for pipeline management get more value from LZA's comprehensive coverage.

5. How much build effort is acceptable? CDK Landing Zone: highest initial build effort, lowest long-term maintenance cost. CfCT: low initial effort, stays low. AFT: moderate (requires Terraform expertise and an existing Control Tower installation). LZA: moderate configuration effort, ongoing YAML maintenance. OrgFormation: low to moderate, but no preview tooling.

Scenario-Based Recommendations

Choose CDK Landing Zone when: You want a compliance-complete IaC foundation for commercial AWS regions without framework lock-in. The Towards the Cloud implementation arrives at 100% CIS, 96% Security Hub, with GuardDuty, Config, CloudTrail, Security Hub Management, and centralized logging deployed via 12 StackSets, all in CDK code your auditors can read. Scales to 10,000 accounts via StackSets with no pipeline bottleneck.

Choose LZA when: You're deploying to GovCloud, Secret Region, or Top Secret Region (LZA standalone is the only path there because Control Tower is unavailable). Or you're in commercial AWS regions and want AWS-maintained config-driven compliance for DoD IL4/IL5, SCCA, or FedRAMP High. In that case it's CT + LZA, not LZA alone. You have dedicated platform engineering capacity for 45+ minute pipelines and 7 YAML configuration files.

Choose CfCT when: You're already on Control Tower and need lightweight, consistent customization on new accounts. Your requirements are baseline SCPs and CloudFormation templates. Your team is small and $3/month is the right operational overhead.

Choose AFT when: You're Terraform-native, already on Control Tower, and want GitOps-style account provisioning. Your primary region supports AFT and CodeConnections.

Choose OrgFormation when: Your team is CF-native and prefers YAML. Requirements are straightforward and unlikely to hit CloudFormation's size limits. You want a free, open-source tool with no pipeline infrastructure. The missing preview/diff capability is acceptable for your change frequency.

Migration Paths: Getting from Control Tower to Something Better

If you're already on Control Tower and evaluating a move, the paths have different friction levels.

Path A: Stay on Control Tower, Add CfCT or AFT

Lowest friction. No landing zone rebuild. CfCT takes a day to deploy and immediately starts applying custom SCPs and CloudFormation templates to new accounts. AFT takes longer (requires its own management account, VCS configuration, and Terraform module deployment) but gives you GitOps account provisioning. Both options keep all your existing Control Tower guardrails and Account Factory workflows intact. The constraint: you're still building on Control Tower's architecture (the 5-SCP-per-OU limit, the Service Catalog account vending, the console-driven management), and none of that changes.

Path B: Add LZA on Top of Control Tower for Compliance Framework Coverage

Medium complexity, and worth being clear about what this is and isn't: LZA does not replace Control Tower in commercial AWS regions. It deploys alongside it as the AWS-recommended pattern. Your 750+ Control Catalog controls stay active. LZA adds networking architecture, security service orchestration, and pre-built compliance configurations (NIST, HIPAA, SCCA, DoD IL4/IL5) on top of what Control Tower already manages. The main commitment is the ~$430/month baseline infrastructure cost and the operational discipline of managing 7 YAML configuration files. This is the right path when you specifically want AWS-maintained compliance config rather than implementing equivalent controls in CDK.

Path C: Full IaC Departure with CDK Landing Zone + StackSets

Highest initial effort, maximum long-term flexibility, and you don't lose compliance posture in the trade. This path means decommissioning Control Tower guardrails and rebuilding the baseline as CDK + StackSets, which (in the Towards the Cloud implementation) ships compliance-complete: 100% CIS, 96% Security Hub, GuardDuty, Config, CloudTrail, Security Hub Management, and centralized logging via 12 StackSets. The approach I've used with clients: provision a parallel management account structure, migrate accounts by OU, validate StackSet coverage before deprovisioning CT controls. For teams migrating from a single account or rebuilding a Control Tower environment they've outgrown, this path takes weeks to months. Budget for parallel operation of both environments during transition and strong CDK expertise on the team.

Frequently Asked Questions

Conclusion: Match the Abstraction Level to Your Team

The right Control Tower alternative depends on where you are today, your team's tooling preferences, and how much initial build effort you can absorb.

CDK Landing Zone is the clear pick for IaC-first teams starting fresh or migrating off Control Tower: native CDK, StackSets, zero framework lock-in, and 5-10 minute deployments instead of 45+ minute pipelines. LZA is the fastest path to compliance coverage for regulated industries (NIST, HIPAA, SCCA, FedRAMP). CfCT and AFT are the lightweight customization layers for teams staying on Control Tower: CfCT for CloudFormation, AFT for Terraform (mind the regional availability gaps). OrgFormation fits CF-native teams with simple requirements, with the caveat that the missing diff/preview is a real risk for production SCP changes.

The pattern for leaving Control Tower entirely: CDK for Organizations, StackSets for cross-account baseline resources, production-ready SCP examples for governance, everything in Git. Start with one OU and one StackSet, validate, expand. Pair this with AWS multi-account best practices and AWS Organizations best practices before committing.