Landing Zone

Last reviewed: August 2026

What Is a Landing Zone

A landing zone is the foundational setup for operating a multi-account cloud environment securely and consistently. It generally includes the following elements:

Network: standardized VPC/VNet structure, hub-and-spoke topology, connectivity policies
Security: security boundaries between accounts, encryption policies, threat detection
Logging: centralized log collection, audit trails, compliance evidence
Guardrails: preventive/detective policies applying consistent governance across the organization

A landing zone lets you provision new workload accounts quickly and safely, while automatically applying your organization’s security and compliance requirements.

graph TB
    subgraph "Landing Zone Components"
        A[Organization Root] --> B[Security OU]
        A --> C[Shared Services OU]
        A --> D[Workload OU]
        B --> B1[Log Archive Account]
        B --> B2[Security Audit Account]
        C --> C1[Network Hub Account]
        C --> C2[Shared Services Account]
        D --> D1[Production Account]
        D --> D2[Development Account]
        D --> D3[Test Account]
    end

Comparing Major CSP Landing Zones

Item	AWS	Azure	Google Cloud	OCI
Service name	AWS Control Tower	Azure Landing Zone	Google Cloud Foundation Toolkit	OCI Landing Zone
Account structure	AWS Organizations + OU	Management Group + Subscription	Organization + Folder + Project	Tenancy + Compartment
Guardrails	Controls (preventive/detective/proactive)	Azure Policy + Deployment Stacks	Organization Policy	CIS Benchmark-based policies
Default network structure	VPC + Transit Gateway	Hub-Spoke VNet + Azure Firewall	Shared VPC + Cloud Interconnect	Hub-Spoke VCN + DRG
IaC support	AWS CloudFormation (built-in)	Bicep / Terraform modules	Terraform modules	Terraform modules
Logging	AWS CloudTrail + Config	Activity Log + Defender for Cloud	Cloud Audit Logs + Security Command Center	Audit + Cloud Guard

Design Checklist

When designing a landing zone, first work out the following items.

Organization structure — decide the criteria for dividing accounts, subscriptions, projects, and compartments.
Environment separation — separate production, development, test, security, and shared-services accounts.
Network boundaries — decide the hub-and-spoke design, internet entry points, and on-premises connectivity method.
Identity integration — standardize your in-house IdP, SSO, MFA, and how admin privileges are granted.
Logging and audit — collect audit logs from all accounts into a central repository.
Guardrails — automatically apply policies such as restricted regions, blocking public storage, and enforced encryption.

Adoption Sequence

Stage	Description
1	First build a minimal account structure and a central log repository.
2	Template network, security, and IAM standards as IaC.
3	Automate the procedure for creating new workload accounts.
4	Operate policy violation detection and an exception approval process.

Multi-Account VPC Separation Patterns

VPC design is a core element of a landing zone. Separate VPCs per workload to create security boundaries, and place shared services in a central VPC.

Separation by Workload

Separation Criteria	Example	Reason
By environment	dev / staging / prod VPC	Production isolation, mistake prevention
By team/service	Team A VPC / Team B VPC	Security boundaries, independent operation
By regulation	PCI VPC / general VPC	Minimizing compliance scope

Shared Services VPC

A pattern where logging, security tools, DNS, proxies, and similar services are placed in a central VPC and accessed from other VPCs.

Vendor Implementations

Vendor	Account/project separation	VPC sharing	Hub connectivity
AWS	Organizations + OU	Subnet sharing via RAM	Transit Gateway
Azure	Separation by subscription	Hub-Spoke VNet	Virtual WAN
Google Cloud	Shared VPC (host + service projects)	Subnet sharing from the host project	VPC Peering / NCC
OCI	Compartment separation	—	DRG hub

CIDR Planning

Allocate CIDR blocks in advance to prevent IP range conflicts between accounts/projects.

Reserve a /8 or /10 range for the entire organization, and distribute /16–/20 units per account/environment
If CIDR ranges overlap during VPC peering/Transit Gateway connections, routing becomes impossible
Allocate generously to account for future growth (adding subnets, creating new accounts)

For detailed network design, see VPC and Subnets.

Landing Zone Adoption Checklist

Common Mistakes

Creating VPCs without a CIDR plan — later, VPC peering/Transit Gateway connections become impossible to route due to IP range conflicts
Creating workload accounts before central logging is in place — audit logs end up scattered across accounts, making integrated investigation impossible during a security incident
Deploying accounts without guardrails — developers accidentally create public S3 buckets or provision resources in restricted regions

2025-2026 Landing Zone Evolution

Modularization: The Controls-Only Model

AWS Control Tower Landing Zone 4.0 (November 2025) moved away from a “single enforced blueprint” approach toward a modular model where you apply only the controls and choose the rest.

Before	After LZ 4.0
Setting up Control Tower created a fixed OU/account structure	Controls can be applied while keeping your existing organizational structure
All service integrations were provided as a package	Service integrations (Config, CloudTrail, etc.) can be enabled selectively
Difficult to customize in large organizations	Can run alongside existing IaC pipelines

Azure’s Cloud Adoption Framework (CAF) also continues to expand its modular landing zone architecture, and Google Cloud Foundation Toolkit supports similar selective application based on Terraform modules.

Sovereign Landing Zone

As data sovereignty requirements intensify, landing zones have emerged that keep not just data storage but also processing within the jurisdiction.

Vendor	Solution	Key Features	Timing
Microsoft	Cloud for Sovereignty — SLZ + Sovereign Public Cloud	Data residency guardrails, confidential computing, EU Data Boundary, Data Guardian, IaC policies	2025-2026
Google Cloud	Sovereign Cloud Controls	In-jurisdiction processing, key management, access transparency	2025-2026
AWS	Sovereign Controls (Control Tower + Nitro)	Region-restriction guardrails, Nitro confidential computing, data residency policies	Existing (ongoing enhancement)
OCI	EU Sovereign Cloud	Physically isolated EU-only infrastructure	Existing

EU Regulatory Linkage

Regulation	Impact on Landing Zone
DORA (effective 2025.01.17)	Requires financial institutions to manage ICT third-party risk → cloud vendors must be managed as critical ICT providers, exit strategy required
NIS2	Strengthens security obligations for critical infrastructure operators → requires landing-zone-level governance evidence
EU AI Act (GPAI obligations 2025.08; sanction powers and Article 50 transparency 2026.08; high-risk AI deferred by Digital Omnibus — standalone 2027.12, product-embedded 2028.08)	Data governance requirements for high-risk AI systems → landing zone must include data classification/access control per AI workload