An AWS Landing Zone is a pre-configured, multi-account AWS environment with baseline security, governance, networking, and operational tooling already in place. It establishes the foundation that organizations build on top of. Instead of every workload starting from a single AWS account with default settings, a landing zone provides organized account structure, enforced security baselines, centralized logging, identity management, and standard networking patterns. The landing zone is the AWS-side equivalent of corporate IT establishing standards before users start building.
AWS Control Tower is the managed service that creates and maintains landing zones for most use cases. Customers enable Control Tower in their management account; Control Tower provisions the multi-account structure, applies baseline guardrails, sets up centralized logging, configures identity, and provides ongoing governance. The service automates what was previously manual landing zone setup, reducing implementation time from months to days for standard configurations.
By 2026 landing zones are standard practice for organizations using AWS at any meaningful scale. Multi-account AWS architecture is the default rather than the exception. Account boundaries provide isolation (one account's mistakes do not break other accounts), governance scope (different policies for different account types), and cost attribution (clearer tracking of which workloads cost what). The landing zone establishes the foundation that makes multi-account architecture practical.
The concept of landing zones predates Control Tower. Before AWS provided a managed service, organizations built custom landing zones using AWS Organizations, Service Control Policies, CloudFormation templates, and various governance tools. The custom approach is still valid for organizations with unusual requirements, but Control Tower handles most standard cases more easily. Most new landing zone deployments use Control Tower as the foundation, possibly with customizations on top.
What landing zones are not: they are not a one-time setup that finishes and stops. The landing zone evolves continuously as AWS adds new services, as organizational needs change, and as security and compliance requirements update. The team that builds the landing zone owns it ongoing; ownership transitions are common pain points.
Multi-account structure. Separate AWS accounts for separate workloads, environments, or teams. Account boundaries provide isolation, governance scope, and cost attribution. Common account types include security accounts (for cross-account audit and security tools), logging accounts (for centralized log aggregation), networking accounts (for shared connectivity), workload accounts (one per application or team), and sandbox accounts (for experimentation).
Organization Units (OUs). Logical groupings of accounts for governance purposes. AWS Organizations provides OUs as the structure for applying policies across multiple accounts. Common OU patterns include one OU per environment (dev, staging, production), one OU per business unit (each department gets its own OU), or one OU per security tier (production-equivalent, lower-stakes, sandbox).
Guardrails. Preventive controls (denying actions that would violate policy) and detective controls (alerting on violations after they occur) enforced across accounts. Examples include preventing creation of public S3 buckets, requiring encryption on EBS volumes, blocking certain regions, and enforcing tagging standards. Control Tower provides default guardrails plus the ability to add custom ones.
Centralized logging. CloudTrail, AWS Config, VPC Flow Logs, and other logs from all accounts aggregated to a logging account. Centralization enables unified audit, security monitoring, and compliance reporting across the entire AWS environment. Without centralized logging, security investigations would require querying every account separately.
Identity. AWS IAM Identity Center (formerly AWS SSO) provides centralized identity for cross-account access. Users authenticate once and get access to multiple accounts based on their roles. Permission sets define what users can do in target accounts. The pattern replaces the unmanageable model of separate IAM users in every account.
Networking. VPCs, Transit Gateway, shared services VPC, network connectivity to on-premise. Networking architecture varies by organization but landing zones typically establish patterns that workload accounts can follow. Common patterns include hub-and-spoke through Transit Gateway, with shared services in a hub account and workloads in spoke accounts.
Security tooling. GuardDuty, Security Hub, AWS Config rules, AWS Inspector, and similar services configured across accounts. The security baseline detects threats, identifies misconfigurations, and provides compliance reporting. Centralized security operations works at the landing zone level rather than separately per account.
Without one, AWS adoption tends to produce inconsistent setups. Each team that needs AWS gets an account with default settings. Security configurations vary unpredictably. IAM policies are ad hoc. Logging may or may not be enabled. Networking is whatever the team figured out. The result is a sprawl of inconsistent accounts that becomes a security and operational nightmare to manage.
Landing zones enforce baselines so every new account starts from a known good configuration. New teams onboarding to AWS get accounts with security tooling already enabled, logging already configured, identity already integrated, and networking already established. The team focuses on their workload rather than reinventing the operational foundation.
The pattern speeds delivery. New workloads can be deployed faster because the foundation is already there. Teams do not have to learn AWS administration to start building; they consume the landing zone's capabilities. Time to first deployment drops significantly compared to custom account setup.
The pattern improves security. Centrally managed guardrails, logging, and security tooling apply consistently. Security teams can monitor and respond across the entire landing zone rather than per account. Compliance audits become easier because the baseline is documented and enforced.
The pattern enables governance at scale. Organizations with hundreds of AWS accounts cannot manage them through ad hoc configuration. Landing zones provide the systematic approach that scales with organizational growth.
Plan the account structure. What types of accounts do you need? How will you organize them into OUs? What naming conventions will you use? The account structure is the foundation; changes are painful later, so the planning matters.
Deploy Control Tower in the management account. Control Tower provisions the foundational accounts (security, logging, audit) and applies the baseline guardrails. The deployment takes a few hours and produces a functioning landing zone.
Configure identity. Set up IAM Identity Center with appropriate permission sets. Integrate with corporate identity provider if applicable. Define user roles and group assignments. Identity is foundational; mistakes here cascade through everything else.
Set up networking. Decide on connectivity patterns (Transit Gateway hub, VPC peering, etc.). Configure shared services VPC if needed. Set up connectivity to on-premise if applicable. Document networking conventions so workload accounts know how to connect.
Customize guardrails. Control Tower provides default guardrails; most organizations add custom ones reflecting their specific compliance and security requirements. The customization happens through Service Control Policies, AWS Config rules, and custom code.
Onboard workload accounts. Create new accounts as needed (manually through Control Tower or programmatically through Account Factory for Terraform). Migrate existing accounts into the landing zone if applicable. Train teams on landing zone capabilities.
Plan ongoing maintenance. Landing zones evolve. New AWS services need governance. New compliance requirements need controls. New workloads need accounts. The team that owns the landing zone needs ongoing capacity to maintain and evolve it.
AWS's managed service for creating and operating landing zones. Provisions the multi-account structure (security, logging, audit accounts), applies baseline guardrails, sets up centralized logging, configures IAM Identity Center, and provides ongoing governance. The service automates what was previously manual landing zone setup. Control Tower is opinionated. It enforces specific patterns that work for most organizations but may not fit all requirements. Organizations with unusual needs sometimes find Control Tower too rigid and build custom landing zones instead. For most organizations, Control Tower's opinions match their needs and the automation is worth the constraint.
Depends on organization size and structure. Common patterns include foundational accounts (security, logging, audit), networking accounts, plus per-workload or per-team accounts. Smaller organizations might have ten to thirty accounts. Larger organizations have hundreds. The right structure varies. The patterns that work group accounts by isolation needs (workloads that should not affect each other go in separate accounts), governance scope (different policies for different account types), and cost attribution (clear cost ownership per account). Account proliferation has costs too, so balance is important. What are guardrails? Preventive (denying actions that violate policy) and detective (alerting on violations) controls applied across accounts. Examples include preventing creation of public S3 buckets, requiring encryption on volumes, blocking specific regions, and enforcing tagging standards. Control Tower provides default guardrails covering common security and compliance requirements. Most organizations add custom guardrails reflecting their specific needs. The customization happens through Service Control Policies (preventive) and AWS Config rules (detective). Together they enforce the baseline that the landing zone establishes.
AWS IAM Identity Center provides centralized SSO with permission sets that map to roles in target accounts. Users authenticate once through Identity Center; permission sets determine what they can do in each target account. Integration with corporate identity providers (Active Directory, Okta, Azure AD) is supported. The pattern replaces the unmanageable model of creating separate IAM users in every AWS account. Identity governance happens centrally; accounts inherit identity configuration rather than managing it independently. The centralization is one of the most important benefits of landing zone adoption.
Control Tower can enroll existing accounts into a landing zone. The enrollment applies the landing zone's guardrails to the existing account and brings it under centralized governance. Existing configuration may need cleanup to comply with the new guardrails. Migration timing varies. Simple accounts that already follow good practices can be enrolled quickly. Accounts with non-compliant configurations need work to bring them into compliance before enrollment succeeds. Plan the migration as a multi-week to multi-month project for organizations with many existing accounts.
An open-source extension to Control Tower that uses Terraform for account provisioning customizations. Standard Control Tower account creation uses opinionated templates; AFT lets organizations apply custom configurations during account creation through Terraform code. AFT bridges the gap between Control Tower's opinionated automation and organizations' specific needs. Custom networking configuration, custom IAM roles, custom resource provisioning all happen through AFT. The pattern preserves Control Tower's automation benefits while adding necessary customization.
Common patterns use Transit Gateway for cross-account connectivity, with shared services in a hub account and workloads in spoke accounts. Workload accounts connect to the Transit Gateway and gain access to shared services (DNS, monitoring, logging) and other accounts as authorized. Some organizations use VPC peering or AWS PrivateLink for specific connectivity needs alongside Transit Gateway. The networking architecture is one of the more variable parts of landing zones because organizational requirements differ significantly. Document the networking conventions so workload teams know how to connect their workloads. What about cost? Control Tower itself is free; you pay for the underlying services it provisions (CloudTrail, AWS Config, GuardDuty, etc.). Costs vary by number of accounts and resources but typically run hundreds to thousands per month for the baseline services across a moderate-sized landing zone. The baseline costs are usually manageable. The cost surprises come from over-provisioned services or runaway resource creation in workload accounts. The landing zone itself does not produce surprises; the workloads running in it can.
Landing zones implement many Well-Architected practices automatically, especially in Operational Excellence (centralized logging and monitoring), Security (baseline guardrails and identity), and Reliability (multi-account isolation). The landing zone provides foundational compliance with Well-Architected; workload-level architecture decisions still need separate review. The two frameworks complement each other. Landing zones handle the foundation. Well-Architected Reviews handle workload-specific architecture. Together they provide layered architectural discipline from foundation to specific applications.
Tighter integration with new AWS services as they launch. Better automation for customization (AFT and similar tools maturing). Expanded guardrails as security and compliance practices evolve. Continued investment in Control Tower as a strategic AWS service. The bigger trend is landing zones becoming invisible foundation underneath broader cloud platforms. Organizations increasingly build internal developer platforms (IDPs) on top of landing zones. Application teams interact with the IDP; the IDP runs on the landing zone. By 2027 or 2028, expect landing zones to be standard infrastructure that most engineers do not think about directly.
