AWS Landing Zone vs Control Tower: Architecture, Best Practices, and Setup Guide

What is an AWS Landing Zone?

An AWS landing zone is a pre-configured, secure, multi-account environment that follows AWS best practices. Think of it as the foundation you pour before building anything — it establishes account structure, identity management, network topology, security guardrails, and logging before your first workload ever deploys.

Without a landing zone, teams end up with dozens of AWS accounts configured inconsistently. Each has its own logging setup (or none), its own VPC design, and its own interpretation of "secure." A landing zone solves this by providing a repeatable, governed baseline that every new account inherits automatically.

In practice, a landing zone includes:

AWS Organizations with a defined OU hierarchy
Centralized identity via IAM Identity Center (SSO)
Guardrails through Service Control Policies (SCPs) and AWS Config rules
Centralized logging — CloudTrail, VPC Flow Logs, and Config aggregated to a log archive account
Network connectivity — Transit Gateway or VPC peering patterns for cross-account communication
Account vending — automated provisioning of new accounts with consistent baselines

AWS offers two managed approaches to building this: AWS Control Tower and the Landing Zone Accelerator (LZA). You can also build a custom landing zone from scratch using Terraform or CloudFormation, though this is increasingly rare for new deployments.

AWS Control Tower vs Landing Zone Accelerator

This is the comparison most teams need to make. Both are AWS-supported, but they solve the problem differently.

Control Tower

Control Tower is a fully managed service with a console-driven experience. It deploys a landing zone in about an hour, provisions the core accounts (Management, Log Archive, Audit), and gives you Account Factory for provisioning new accounts. Guardrails are toggled on and off from the dashboard.

Best for: Organizations that want a managed service with minimal custom code, have standard governance needs, and prefer console-driven operations.

Landing Zone Accelerator (LZA)

LZA is an open-source solution (formerly called the "Secure Environment Accelerator") deployed via a CDK pipeline in your management account. You define your entire landing zone in configuration files — OUs, accounts, SCPs, network topology, security services — and the pipeline deploys and maintains it. It can operate on top of Control Tower or standalone with AWS Organizations.

Best for: Organizations with complex compliance requirements (GovCloud, PBMM, NIST 800-53), custom network architectures, or teams that want full infrastructure-as-code control.

Comparison Table

Capability	AWS Control Tower	Landing Zone Accelerator
Deployment model	Managed service (console + API)	CDK pipeline (infrastructure-as-code)
Setup time	~1 hour	2-4 hours initial, ongoing config
Account vending	Account Factory (Service Catalog)	Config-driven (accounts-config.yaml)
Guardrails	400+ built-in controls	Custom SCPs + Config rules via config
Network topology	Basic (no built-in Transit Gateway)	Full network design (TGW, IPAM, DNS)
Customization	AFC (Terraform/CFN blueprints)	Complete control via config files
Compliance frameworks	General best practices	NIST, CCCS PBMM, ACSC ISM, GovCloud
Ongoing maintenance	AWS-managed updates	Self-managed pipeline updates
Prerequisite	None (creates Organizations)	AWS Organizations (optionally Control Tower)
Best for	Standard enterprise governance	Regulated industries, complex networking

Many organizations use both: Control Tower as the governance layer with LZA deployed on top for network automation and advanced security configuration.

Landing Zone Architecture Components

A properly configured landing zone separates concerns into distinct organizational units with different governance policies.

Chart

Organizational Unit Structure

OU	Purpose	Account Types	Guardrails
Security	Centralized security services	Log Archive, Audit	Mandatory + strongly recommended
Infrastructure	Shared services and networking	Network Hub, Shared Services	Mandatory + custom
Sandbox	Developer experimentation	Individual dev accounts	Mandatory only
Workloads (Prod)	Production workloads	App-specific prod accounts	All guardrails
Workloads (NonProd)	Pre-production environments	Dev, staging, QA accounts	Mandatory + preventive
Policy Staging	Test guardrails before prod	Test accounts	Variable

Service Control Policies (SCPs)

SCPs are the backbone of preventive governance. They define the maximum permissions boundary for every account in an OU. Even if an IAM policy grants AdministratorAccess, the SCP can block specific actions at the organization level.

Key SCPs for any landing zone:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsOutsideAllowed",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1",
            "eu-central-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/AWSControlTowerExecution",
            "arn:aws:iam::*:role/OrganizationAccountAccessRole"
          ]
        }
      }
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyCloudTrailModification",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail",
        "cloudtrail:PutEventSelectors"
      ],
      "Resource": "arn:aws:cloudtrail:*:*:trail/aws-controltower-*"
    }
  ]
}

Account Vending

Account Factory automates provisioning with consistent configurations. Instead of manually creating accounts and applying baselines, you define the parameters and Account Factory handles creation, OU placement, SSO access, and baseline application:

import boto3

def provision_account(account_name, email, ou_name, sso_user_email):
    """Provision a new account via Account Factory."""
    sc_client = boto3.client('servicecatalog')

    products = sc_client.search_products(
        Filters={'FullTextSearch': ['AWS Control Tower Account Factory']}
    )
    product_id = products['ProductViewSummaries'][0]['ProductId']

    artifacts = sc_client.list_provisioning_artifacts(ProductId=product_id)
    artifact_id = artifacts['ProvisioningArtifactDetails'][-1]['Id']

    response = sc_client.provision_product(
        ProductId=product_id,
        ProvisioningArtifactId=artifact_id,
        ProvisionedProductName=f"account-{account_name}",
        ProvisioningParameters=[
            {'Key': 'AccountName', 'Value': account_name},
            {'Key': 'AccountEmail', 'Value': email},
            {'Key': 'ManagedOrganizationalUnit', 'Value': ou_name},
            {'Key': 'SSOUserEmail', 'Value': sso_user_email},
            {'Key': 'SSOUserFirstName', 'Value': 'Admin'},
            {'Key': 'SSOUserLastName', 'Value': 'User'}
        ]
    )
    return response['RecordDetail']['RecordId']

Network Topology

The network account typically hosts a Transit Gateway that connects workload VPCs. A common topology:

Hub VPC in the network account with Transit Gateway
Spoke VPCs in workload accounts attached to TGW
Inspection VPC with AWS Network Firewall for east-west traffic filtering
Shared services VPC for DNS resolvers, Active Directory connectors, and CI/CD
Egress VPC centralizing NAT Gateways to reduce costs

Setting Up AWS Control Tower: Step-by-Step Overview

Prerequisites

A fresh AWS account (or an existing Organizations management account with no conflicting config)
A unique email address for the Log Archive account
A unique email address for the Audit account
AWS SSO not already configured in the region (Control Tower will set it up)

Deployment Steps

Enable Control Tower — Navigate to the Control Tower console in your home region and launch the setup wizard. Choose your governance regions and provide the audit/log archive emails.
Wait for initial deployment (~60 minutes) — Control Tower creates the foundational OUs (Security, Sandbox), provisions the Log Archive and Audit accounts, configures CloudTrail, and sets up AWS Config.
Create additional OUs — Add Infrastructure, Workloads-Prod, Workloads-NonProd, and Policy Staging OUs through the Control Tower console.
Enable guardrails per OU — Start with strongly recommended guardrails on production OUs. Enable detective guardrails for visibility before enforcing preventive ones.
Configure Account Factory — Set default VPC configuration (or disable default VPCs), define which regions are governed, and configure SSO settings for new accounts.
Apply Account Factory Customization — Create blueprints for your account baselines:

# customizations/account-baseline/main.tf
resource "aws_securityhub_account" "main" {}

resource "aws_guardduty_detector" "main" {
  enable                       = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"
}

resource "aws_s3_account_public_access_block" "main" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Provision initial workload accounts — Use Account Factory to create your first accounts and verify the baselines apply correctly.
Set up centralized networking — Deploy Transit Gateway in your network account and share it via RAM to workload accounts.

Best Practices for Multi-Account Strategy

Account Design Principles

One workload per account. The strongest isolation boundary AWS provides is the account boundary. Separate production workloads into distinct accounts. A breach in one account cannot access resources in another (assuming proper SCP design).

Separate environments by account, not by VPC. A "dev VPC" and "prod VPC" in the same account share the same IAM boundary. An overly permissive dev role can access production data. Separate accounts eliminate this risk.

Dedicated accounts for shared services. DNS, CI/CD pipelines, container registries, and artifact storage belong in a shared services account accessible to workload accounts through cross-account roles or Resource Access Manager.

Guardrail Strategy

Layer guardrails based on environment sensitivity:

Layer	Sandbox	Non-Prod	Production
Region deny	Optional	Yes	Yes
Root user access denied	Yes	Yes	Yes
S3 public access blocked	No	Yes	Yes
VPC internet access restricted	No	No	Yes
CloudTrail modification denied	Yes	Yes	Yes
Delete protection (RDS, DynamoDB)	No	No	Yes

Tagging and Cost Allocation

Enforce tagging through SCPs that deny resource creation without required tags:

Environment (prod, staging, dev, sandbox)
CostCenter (maps to business unit for chargebacks)
Owner (team or individual responsible)
Application (maps to workload for cost allocation)

Identity and Access

Use IAM Identity Center (SSO) exclusively — no IAM users in workload accounts
Define permission sets at the OU level, not per-account
Keep permission sets under 10 per OU to avoid sprawl
Use session policies for temporary elevated access rather than permanent broad roles

Common Mistakes and How to Avoid Them

1. Putting Everything in the Management Account

The management account should run nothing except Organizations, Control Tower, and billing. Every workload, CI/CD pipeline, and monitoring tool belongs in a member account. The management account has implicit access to all member accounts via OrganizationAccountAccessRole — compromising it means compromising everything.

2. Flat OU Structure

A single "Workloads" OU with 200 accounts means one SCP policy applies to all of them. You cannot differentiate guardrails between a sandbox experiment and a PCI-compliant production service. Structure OUs by governance requirements, not by team name.

3. Ignoring Landing Zone Drift

Control Tower detects drift when resources it manages are modified outside its control (manual SCP changes, deleted Config rules, modified CloudTrail). Ignoring drift warnings leads to governance gaps. Check for drift weekly and resolve immediately.

4. Overly Permissive Sandbox OUs

Sandboxes with no guardrails become shadow production environments. At minimum, enforce region restrictions, budget alerts, and prevent creation of IAM users. Set auto-nuke policies (using tools like aws-nuke) on a weekly schedule.

5. Not Testing Guardrails Before Deployment

Deploying a preventive guardrail directly to a production OU can break running workloads. Always test in a Policy Staging OU first. A region-deny SCP that forgets to exclude us-east-1 for global services (IAM, CloudFront, Route53) will cause widespread failures.

6. Manual Account Configuration

Every manual step in account setup is a step that will be missed eventually. If you are SSH-ing into accounts to configure baselines, you have already lost. Use Account Factory Customization or LZA to codify every baseline requirement.

When to Use Control Tower vs Custom Landing Zone

Choose Control Tower When:

You need a landing zone in production within a week
Your governance requirements align with AWS best practices without heavy customization
Your team does not have dedicated platform engineers for ongoing maintenance
You have fewer than 100 accounts and standard compliance needs
You want AWS to maintain the governance layer through managed updates

Choose Landing Zone Accelerator When:

You operate in regulated industries (finance, healthcare, government)
You need centralized network architecture (Transit Gateway, IPAM, DNS) managed as code
You require compliance mapping to specific frameworks (NIST 800-53, HIPAA, PCI DSS)
Your organization exceeds 200 accounts with diverse governance needs
You have platform engineering capacity to maintain the CDK pipeline

Choose a Custom Landing Zone When:

You have unique multi-cloud requirements that LZA does not address
Your organization predates Control Tower and has deeply customized automation
You need governance patterns that neither Control Tower nor LZA supports

In practice, most organizations starting fresh in 2024-2025 should start with Control Tower. If you outgrow it, layer LZA on top — they are complementary, not competing tools.

Ongoing Operations

Landing Zone Updates

# Check for available Control Tower updates
aws controltower list-landing-zones \
  --query 'landingZones[].{Arn:arn,Version:version,Status:status}'

# Update landing zone (test in staging first)
aws controltower update-landing-zone \
  --landing-zone-identifier "arn:aws:controltower:us-east-1:123456789:landingzone/ABC123" \
  --version "3.3"

Drift Detection

# Detect configuration drift
aws controltower list-landing-zone-operations \
  --filter '{"types": ["UPDATE", "RESET"], "statuses": ["SUCCEEDED", "FAILED"]}'

# Get drift details
aws controltower get-landing-zone-operation \
  --operation-identifier "op-123456"

Compliance Metrics to Track

Metric	Target	How to Measure
Account provisioning time	< 30 min	Account Factory completion time
Guardrail coverage	100% of OUs	Config compliance percentage
Non-compliant resources	< 2%	Detective guardrail findings
SCP drift	0 instances	Organizational policy audit
SSO permission sets	< 10 per OU	IAM Identity Center review
Cross-account access paths	Documented	IAM Access Analyzer findings

FAQ

What is the difference between a landing zone and Control Tower?

A landing zone is the concept — a secure, multi-account foundation. Control Tower is one implementation of that concept. You can build a landing zone with Control Tower, with LZA, with custom Terraform, or even manually. Control Tower just automates the AWS-recommended version of a landing zone.

Is AWS Landing Zone deprecated?

The original "AWS Landing Zone" solution (a CodePipeline-based deployment from ~2018) is deprecated. It was replaced by AWS Control Tower (managed service) and Landing Zone Accelerator (open-source IaC). If you are on the old solution, migrate to Control Tower. AWS provides a migration guide.

Can I use Control Tower with existing AWS Organizations?

Yes. Control Tower can be enabled on an existing organization. It will not modify accounts outside the OUs it creates. You can enroll existing accounts into Control Tower-managed OUs over time. However, resolve any conflicting AWS Config or CloudTrail configurations in the management account first.

How many accounts should a landing zone have?

There is no fixed number. A startup might have 4-5 accounts (management, log archive, audit, production, staging). An enterprise might have 500+. The key principle is one workload per account for production, with shared services centralized. Let governance requirements drive the structure, not arbitrary limits.

Does Control Tower cost extra?

Control Tower itself is free. You pay for the underlying services it deploys: AWS Config rules, CloudTrail, and any additional services in your baselines (GuardDuty, Security Hub). For a typical 20-account organization, expect $200-500/month in governance overhead — trivial compared to the cost of a security incident from ungoverned accounts.

Can I customize Control Tower guardrails?

Yes. Beyond the 400+ built-in controls, you can create custom guardrails using custom SCPs (preventive) and custom AWS Config rules (detective). Account Factory Customization lets you apply Terraform or CloudFormation blueprints to every new account. For more complex customization, layer Landing Zone Accelerator on top of Control Tower.

Key Takeaways

A landing zone is your multi-account foundation — get it right early, and every workload you deploy inherits security and governance automatically.
Control Tower is the starting point for most organizations — it deploys a governed landing zone in under an hour with minimal custom code.
Landing Zone Accelerator adds infrastructure-as-code control — use it on top of Control Tower when you need advanced networking, compliance mapping, or full config-driven management.
Structure OUs by governance requirements, not team names — this determines which guardrails apply where.
Automate everything — manual account configuration guarantees inconsistency and drift over time.
Test guardrails in Policy Staging before applying to production OUs to avoid breaking running workloads.
Start simple, layer complexity — enable Control Tower, then add LZA if you outgrow it. You do not need to solve every problem on day one.