What Is an AWS Landing Zone? How It Differs From Control Tower

When you first start using AWS, everything lives in one account. Development, staging, and production share it, and that works until a developer changes a production resource by accident, the security team can't apply stricter controls to production alone, and nobody can say which team caused last month's cost spike.

Most organizations respond by creating more accounts. A landing zone is what keeps those accounts governed as their number grows.

What Is an AWS Landing Zone?

An AWS landing zone is a multi-account AWS environment, built on AWS Organizations, that is secure, scalable, and governed from day one. It sets up the account structure, central identity, guardrails, logging, and security baseline that every new account inherits, so teams can deploy workloads without rebuilding that foundation each time.

No single AWS service is the landing zone. AWS Control Tower, Landing Zone Accelerator on AWS, and your own infrastructure as code are all ways to build one (compared below), and whichever you pick becomes the technical layer of your cloud foundation.

What a Landing Zone Sets Up

• Account structure: an organization in AWS Organizations with organizational units (OUs) that group accounts by purpose, plus dedicated accounts for log archiving and security tooling.
• Central identity: AWS IAM Identity Center (formerly AWS SSO) or federation with your identity provider. People sign in once and assume roles in each account, so there are no IAM users scattered across accounts.
• Account vending: an account factory that creates new accounts with the security baseline, access, and budgets already in place.
• Guardrails: service control policies (SCPs) and resource control policies (RCPs) that cap what principals and resources in member accounts can do. Account administrators can't grant themselves past those limits.
• Central logging and security: an organization trail in AWS CloudTrail delivering to a log archive account, with GuardDuty, AWS Config, and Security Hub managed from a delegated administrator account.
• Network baseline: often a hub-and-spoke design, with a network account hosting AWS Transit Gateway, shared DNS, and centralized egress for the spoke accounts. Some implementations leave networking to each workload team.
• Cost controls: consolidated billing with a cost breakdown per account, and budgets per account or environment. The cost optimization checklist covers what to apply across those accounts.

AWS Landing Zone vs AWS Control Tower

A landing zone is the multi-account foundation. AWS Control Tower is an AWS service that builds one and keeps governing it. The two get mixed up because Control Tower calls the environment it creates "your landing zone", and because AWS once shipped a solution literally named AWS Landing Zone. That solution is in long-term support with no new features, and AWS points new deployments to Control Tower instead.

So the question is never landing zone or Control Tower. Control Tower is one way to get a landing zone, and there are two other common ones:

AWS Control Tower: The Managed Option

Control Tower has no charge of its own; you pay for the services it turns on, such as AWS Config, CloudTrail, and Service Catalog. It gives you:

• Automated account provisioning through Account Factory
• Shared Log Archive and Audit accounts for central logging and security tooling
• A catalog of preventive, detective, and proactive controls (formerly called guardrails)
• Centralized logging to the Log Archive account
• A dashboard for compliance status and drift

Control Tower suits teams that want AWS best practices quickly and are comfortable configuring governance in the console.

The trade-off is change management. Settings changed in the console have no pull request, no review before they apply, and no Git history showing what changed and why, so you can't show an auditor that a change went through review. There's also no one-click export to replicate a console-built setup in another organization. And because Control Tower is opinionated about OU structure and baselines, requirements that don't fit tend to end up managed outside it, which leaves you running a hybrid. Because a landing zone change affects every account, "who changed this SCP and why?" shouldn't require digging through CloudTrail. Control Tower also builds on top of AWS Organizations rather than replacing it; the Control Tower vs Organizations guide explains where one ends and the other begins.

Infrastructure as Code: A Landing Zone You Own

Infrastructure as code defines the whole landing zone in code. With Terraform, CloudFormation, or AWS CDK you can build a landing zone that fits your requirements, with full version control. Teams choose this path when they need:

• Changes reviewed through pull requests and tracked in Git
• Custom compliance requirements that Control Tower's opinionated structure doesn't cover
• Specific OU structures, security patterns, or multi-Region designs
• The same setup replicated across several AWS organizations
• Integration with their existing CI/CD and review workflows

If you would rather have that foundation built for you, our AWS CDK Landing Zone is a multi-account AWS foundation built with AWS CDK and deployed in about a week, with CIS AWS Foundations Benchmark controls from day one and every line of CDK in your repository. It includes:

• A complete multi-account architecture deployed through CDK
• A 100% score on the CIS AWS Foundations Benchmark
• A 96% rating on AWS Foundational Security Best Practices
• Automated security baselines, logging, and monitoring
• Pre-configured organizational units and SCPs
• The full feature list in our public roadmap

Networking is not part of it: VPCs, Transit Gateway, and any shared network account stay yours to design for your workloads, including how you allocate CIDRs across accounts with IPAM.

Which approach fits depends on how your team wants to make and review changes. For that decision, compare Control Tower's managed console model with a CDK landing zone you own. If compliance frameworks drive the choice, read Landing Zone Accelerator vs CDK Landing Zone, and for every option side by side, see the Control Tower alternatives guide.

Why One AWS Account Stops Being Enough

Starting with a single AWS account is sensible: it's simple and gets you running quickly. As you scale, four problems appear:

• Access control: separating development and production access through IAM policies alone turns into a tangle of roles, conditions, and exceptions.
• Compliance: production handling cardholder data needs strict PCI DSS controls while a sandbox needs room to experiment, and both live under the same account settings.
• Cost attribution: finding out which team drives the bill depends on tagging discipline that rarely holds up, so an unexpected bill becomes a forensic investigation.
• Blast radius: an overly permissive S3 bucket policy in development can expose production data, and a runaway Lambda function in staging can use up the account's concurrency that production depends on.

Teams usually fix this by adding accounts as needs come up: a logging account after an audit, a data science account for SageMaker experiments, a separate account for a new product team. Each one solves a local problem. Together they create a new one: every account has its own IAM users, security settings, and network configuration, and nothing manages identity, security baselines, connectivity, or policy across all of them. Enforcing "no unencrypted S3 buckets" or "no resources outside approved Regions" account by account depends on human discipline.

A landing zone solves that second problem. If you're already running workloads in one account, the single to multi-account migration guide covers a five-phase path that doesn't disrupt them.

How a Landing Zone Works in Practice

Here's what onboarding a new product team looks like once a landing zone is in place:

1. The team requests an account through the account factory
2. The landing zone automatically:
   • Creates the account in the right organizational unit
   • Applies the SCPs for that environment type
   • Connects it to shared network services, if your landing zone manages networking
   • Enables the security baseline (CloudTrail, GuardDuty, Config, Security Hub)
   • Sets up budgets and alerts
   • Grants the team access through IAM Identity Center
3. The team starts deploying into an account that already meets your baseline, without a ticket for each of those steps

Those security services are the baseline controls that protect every account. For what each one does and how to configure it, see AWS Account Security Best Practices.

Key Components of Landing Zone Architecture

Regardless of which implementation approach you choose, every landing zone shares common architectural components that enable governance at scale.

Account Structure and Organization

A landing zone organizes accounts into a hierarchy using AWS Organizations. The organizational unit (OU) structure determines how policies are inherited and enforced.

Foundational OUs (Control Tower's default setup):

Root Organization
├── Security OU
│   ├── Log Archive Account (centralized, immutable logging)
│   └── Audit Account (security tooling, delegated admin)
├── Sandbox OU
│   └── Developer experimentation accounts
└── [Additional OUs you create]

Recommended Additional OUs based on AWS best practices:

Root Organization
├── Security OU
├── Infrastructure OU
│   ├── Network Hub Account (Transit Gateway, DNS)
│   └── Shared Services Account
├── Workloads OU
│   ├── Production OU
│   │   └── Production workload accounts
│   └── Non-Production OU
│       ├── Development accounts
│       └── Staging accounts
├── Sandbox OU
├── Policy Staging OU (test policy changes before production)
├── Suspended OU (decommissioned accounts)
├── Deployments OU (CI/CD accounts)
└── Transitional OU (accounts being migrated)

Key principles:

• Apply policies at the OU level, not individual accounts
• Avoid deep hierarchies (maximum 5 levels)
• Group workloads based on business purpose and compliance requirements
• Use delegated administrators to manage security services from the Audit account instead of the management account

For comprehensive guidance on account architecture patterns for different organization sizes, see our AWS multi-account strategy guide.

Preventive Controls Through SCPs and RCPs

AWS Control Tower uses controls (formerly called "guardrails") to enforce governance. There are three types:

Preventive Controls use Service Control Policies (SCPs) and the newer Resource Control Policies (RCPs) to block actions before they happen:

• SCPs restrict what IAM principals in member accounts can do
• RCPs restrict access to resources in member accounts for supported services, regardless of who makes the request
• A preventive control is either enforced or not enabled (no partial enforcement)
• Neither affects the management account

Common preventive control implementations include:

• Denying the ability to disable CloudTrail or delete logs
• Preventing resource creation outside approved regions
• Requiring encryption for all data storage services
• Blocking public access to databases and storage
• Enforcing tagging requirements for cost allocation

For production-ready implementations of these controls, see our AWS SCP Examples with 25+ copy-paste policies organized by OU.

Important limitations:

• Maximum of 10 SCPs per OU
• Maximum of 5 OU hierarchy levels
• Controls are inherited through the organization hierarchy

Detective Controls and Monitoring

While preventive controls block violations, detective controls identify issues and drift after the fact:

Detective Controls use AWS Config rules to:

• Continuously evaluate resource compliance
• Identify configuration drift
• Provide alerts when resources violate policies

Control Catalog additions: AWS Control Tower's Control Catalog added 223 AWS Config controls in April 2025 and 279 more in November, along with:

• Mappings to industry frameworks such as CIS v8.0, FedRAMP r4, ISO/IEC 27001, NIST CSF v1.1, NIST SP 800-171 r2, PCI DSS v4.0, and SOC 2
• Three-level classification system (Domain, Objective, Common control)

Proactive Controls use CloudFormation Hooks to:

• Check whether resources are compliant before provisioning
• Prevent non-compliant resources from being created
• Apply only to resources provisioned through CloudFormation

The combination of preventive, detective, and proactive controls creates defense in depth for your landing zone.

The Business Benefits of a Landing Zone

A landing zone pays off in operational time, security posture, and how fast teams get new accounts. The landing zone benefits guide covers the business case in more detail.

• Less operational overhead: account creation, baselines, and access are automated, so adding the twentieth account costs the same effort as the second.
• Stronger security posture: baselines apply consistently, detective controls flag issues across every account, and an incident stays contained to one account.
• Faster delivery: teams get a configured account without waiting on a chain of tickets, and developers can experiment in sandbox accounts without risking production.
• Cost visibility: spend breaks down per account on the consolidated bill, and budgets can differ by account type.
• Audit readiness: centralized logging and continuous compliance checks turn audit preparation into a report instead of a fire drill. Those controls map closely to what SOC 2, HIPAA, and PCI DSS auditors ask for.

When we deployed our CDK-based landing zone for Accolade, they reached the CIS and AWS Foundational Security Best Practices scores listed above, which simplified their SOC 2 compliance process.

How to Set Up an AWS Landing Zone

Where you start depends on whether you are new to AWS or already running workloads.

For Organizations New to AWS

Starting with a landing zone before migrating workloads is the most cost-effective approach. You avoid accumulating technical debt and establish good practices from day one.

If choosing Control Tower:

• Setup takes about 30 minutes once the prerequisites are in place
• To create new Log Archive and Audit accounts, you'll need two email addresses that aren't tied to an existing AWS account (or bring existing accounts)
• Choose your home region carefully as it cannot be changed after setup
• Only govern regions where you'll actually deploy workloads
• Use SCPs to deny access to ungoverned regions

Prerequisites:

• An existing AWS account to serve as the management account
• Administrator access
• Decision on which additional regions to govern beyond your home region

If choosing Landing Zone Accelerator: LZA can set up Control Tower for you. Start from an organization with all features enabled and only the management account in it, then deploy the LZA installer stack with its Control Tower option turned on; LZA creates the Control Tower landing zone before applying its configuration files. The LZA implementation guide lists the full prerequisites.

If choosing your own infrastructure as code: define the organization, OUs, and SCPs in code first, then roll the account baseline (logging, security services, IAM roles) out to every account with CloudFormation StackSets or your tool's equivalent, all through one reviewed pipeline.

For Organizations Already Using AWS

Migrating existing accounts into a landing zone requires planning, but the process is well-documented:

1. Assess your current state: Document existing accounts, OUs, SCPs, and pain points
2. Design your target architecture: Define OU structure, control requirements, and network topology
3. Prepare accounts for enrollment: Existing accounts need the AWSControlTowerExecution role enabled before enrollment
4. Address potential conflicts: Existing SCPs can block landing zone deployments; existing AWS Config resources may need migration
5. Migrate incrementally: Start with non-production accounts to validate the process

Migration strategy for larger organizations:

1. Replicate data from existing workloads to new accounts
2. Create Infrastructure as Code templates for all resources
3. Test workloads in a discrete OU with required SCPs
4. Migrate workloads to new accounts within the landing zone
5. Move AWS accounts to appropriate OUs
6. Validate and decommission old configurations

For detailed guidance on each step, see our comprehensive implementation guide: AWS Multi-Account Best Practices.

Key Decisions to Make

Before implementing a landing zone, decide on:

• Account strategy (per application, per environment, or per team)
• Network architecture (centralized, distributed, or hybrid)
• Identity provider and federation approach
• Compliance requirements and necessary controls
• Budget and cost allocation model
• Implementation approach (Control Tower, LZA, or your own IaC)

Landing Zone Updates and Maintenance

Landing zones aren't set-and-forget infrastructure. AWS releases updates, security requirements evolve, and your organization's needs change. Understanding the maintenance model is essential for long-term success.

AWS Control Tower Version Updates

AWS Control Tower releases landing zone versions with enhanced features and security improvements. Recent significant updates include:

Version 4.0 (November 2025):

• Flexible Controls-Only experience for existing multi-account environments
• Optional service integrations (choose which services to enable)
• Dedicated resources for key services with better isolation
• Service-linked Config aggregator
• No required Security OU; hub accounts just need to share one OU

Version 3.3 (December 2023):

• Required aws:SourceOrgID condition for write permissions to Audit bucket
• The same condition added to the AWS Config SNS topic policy
• Updates to the landing zone Region deny control

Benefits of staying current:

• Enhanced security features
• Cost optimization (e.g., AWS Config global resource data in your home Region only)
• Ability to encrypt CloudTrail trails with your own KMS key
• Increased number of available controls
• Better integration with AWS Security Hub

Updating Your Landing Zone

For Control Tower: Updates are initiated through the AWS Control Tower console. Best practices include:

• Test upgrades in a non-production environment first
• Review release notes for breaking changes
• When upgrading from 2.x to 3.x, the account-level CloudTrail trails Control Tower created are replaced by an organization-level trail (logs are preserved)
• Plan for potential double costs if some accounts have their own account-level trails during transition

For IaC-based landing zones:

• Updates follow your standard deployment pipeline
• Changes are version controlled and reviewed
• Rollback is straightforward if issues occur
• Maintain a testing/staging organization for validating major changes

Drift Detection and Resolution

Drift occurs when the actual state of resources differs from the expected configuration. AWS Control Tower provides built-in drift detection:

How it works:

• Automatically detects drift in managed SCPs and policies
• Sends notifications through Amazon SNS (from landing zone 4.0, through EventBridge in the management account)
• Scans managed SCPs, RCPs, and declarative policies daily

Types of drift:

• Account movement between organizational units
• Policy changes to SCPs
• Deletion of required resources (Security OU, required IAM roles)
• Renaming OUs or accounts (permitted but creates resolvable drift)

Resolution approaches:

• Console-based resolution for Control Tower-managed drift
• For IaC landing zones, a redeploy reverts drift only if the tool compares live state (Terraform, CloudFormation drift-aware change sets); a plain CDK deploy doesn't
• Critical drift (deleted Security OU or required roles) must be resolved immediately

Common Misconceptions About Landing Zones

"We're too small for a landing zone" If you have more than one AWS account or more than one team using AWS, you already need central management. Every account you add by hand is another set of IAM users, logging settings, and security services to keep consistent.

"It will slow down our development" It usually speeds teams up. Without a landing zone, a properly configured account takes a chain of manual requests. With one, the account factory hands teams an account that already meets the baseline.

"We can build this ourselves as we go" Account architecture is expensive to fix later. Retrofitting governance, security, and networking across accounts that already run workloads means moving resources, rewriting policies, and re-enrolling accounts, which is far harder than starting with the structure in place.

Conclusion

An AWS landing zone is the multi-account foundation that keeps identity, guardrails, logging, and account creation consistent as you add accounts. Once you run more than a handful of accounts or teams, you need one, and the earlier you set it up the less you have to retrofit.

AWS Control Tower is the managed way to build it; Landing Zone Accelerator and your own infrastructure as code are the others. The right choice depends on how your team wants to make and review changes: Control Tower gets you started quickly, while code gives you review, history, and replication. To see that trade-off worked through change by change, compare Control Tower's managed console model with a CDK landing zone you own outright.

Frequently Asked Questions