Cloud Landing Zones

What it is

A cloud landing zone is the foundational envelope within which all cloud workloads run. It establishes the multi-account (AWS) or multi-subscription (Azure) or multi-project (GCP) hierarchy, the networking topology connecting those accounts, the identity and access management (IAM) model, the security guardrails that prevent dangerous configurations, and the baseline logging and monitoring infrastructure. Rather than each team provisioning their own accounts ad-hoc, a landing zone provides a governed, repeatable starting point — "ready to land" infrastructure that meets organisational security, compliance, and operational requirements from day one.

On AWS, landing zones are typically implemented with AWS Control Tower, which automates multi-account setup via AWS Organizations, applies mandatory Service Control Policies (SCPs), provisions shared accounts (Log Archive, Audit), and enrolls accounts in AWS Security Hub and GuardDuty. Azure's equivalent is the Azure Landing Zone Accelerator (Enterprise Scale), which deploys Management Groups, Policy Assignments, and a hub VNet. GCP offers GCP Landing Zone blueprints using Organization Policies and Shared VPCs. All three follow the same conceptual model: a hierarchy of management containers (OUs/Management Groups/Folders) with policy inheritance, shared networking hub accounts, and an account vending machine for self-service team account provisioning.

Why it exists

Without a landing zone, organisations fall into one of two failure modes: either a central IT team manually provisions and reviews every cloud resource (creating a bottleneck that defeats the agility promise of cloud), or teams self-provision without governance (leading to security incidents, compliance failures, and uncontrolled costs). Landing zones solve this by automating the repeatable security and networking baseline so teams can move fast within guardrails. The security baseline (CloudTrail enabled, GuardDuty active, encryption-at-rest enforced, no public S3 buckets) applies automatically to every new account, without requiring a security review for each team.

The multi-account model itself is a security boundary — AWS accounts are the strongest isolation primitive in AWS. Running production, staging, and development in the same account exposes all environments to the same blast radius if a credential is compromised. Separating workloads across accounts means a compromised dev IAM key cannot access production data. The landing zone automates account separation and enforces it via SCPs that prevent even account root users from disabling core security services.

When to use

• Your organisation is moving from a single shared AWS account to a proper multi-account structure and needs a repeatable, governed baseline.
• You have compliance requirements (PCI-DSS, HIPAA, FedRAMP, ISO 27001) that mandate specific security controls applicable to all cloud environments.
• Multiple autonomous product teams need independent cloud environments but must share networking infrastructure (Transit Gateway, DirectConnect) and meet common security baselines.
• You are beginning a large-scale cloud migration and need a "ready to receive workloads" environment established before migration waves begin.
• Your FinOps practice requires per-account cost allocation and budget guardrails that are difficult to enforce in a shared account.

When not to use

• Single-team startups — the multi-account overhead (cross-account IAM roles, centralized logging aggregation) is not justified when one team owns all workloads and a single account with strict IAM suffices.
• When landing zone tooling introduces long provisioning delays — poorly implemented account vending machines that take days or weeks to provision accounts replace manual bottlenecks with automated ones; optimise the pipeline first.
• Over-engineered OU hierarchy — deeply nested OUs with dozens of SCPs create policy inheritance complexity that is difficult to debug; prefer a flat, simple structure with clear SCP purposes.
• When it replaces workload security — a landing zone provides infrastructure security baseline, not application security; teams still need to implement their own encryption, secrets management, and least-privilege IAM.

Typical architecture

AWS Organizations Root
├── Management OU
│   ├── Management Account (billing, Control Tower, SSO)
│   ├── Log Archive Account  (S3 centralised CloudTrail, Config)
│   └── Security/Audit Account (GuardDuty master, Security Hub)
│
├── Infrastructure OU
│   ├── Networking Account   (Transit Gateway, DirectConnect, DNS)
│   └── Shared Services Acc  (Container Registry, Artifactory)
│
├── Workloads OU
│   ├── Production OU
│   │   ├── prod-payments   (team account)
│   │   └── prod-identity   (team account)
│   └── Non-Production OU
│       ├── staging-payments
│       └── dev-payments
│
└── Sandbox OU  (no TGW attachment, relaxed SCPs)

Guardrails applied at OU level via SCPs:
  Preventive: deny disable CloudTrail, deny public S3 ACLs
  Detective:  AWS Config rules for encryption, MFA on root

Pros and cons

Implementation notes

Start with AWS Control Tower's standard landing zone deployment, which provisions the Management, Log Archive, and Audit accounts and applies AWS-managed guardrails. Extend with Account Factory for Terraform (AFT) — an open-source account vending machine that allows teams to request accounts via a Git pull request, triggering a Terraform pipeline that provisions the account, enrolls it in Control Tower, applies custom SCPs, and configures the hub-spoke network attachment. Define an account request as a terraform.tfvars file with fields: account_name, account_email, ou_name, account_tags. This GitOps approach gives a full audit trail of every account ever created.

For networking, use a hub-spoke topology with Transit Gateway: the Networking account hosts the TGW and attaches VPCs from workload accounts as spokes. Route all egress through a centralised inspection VPC (AWS Network Firewall or third-party NVA) in the hub. Allocate non-overlapping CIDR ranges across all accounts at the outset — a common convention is to assign each account a /20 from a pre-allocated supernet (e.g., 10.0.0.0/8) managed in an IPAM tool (AWS VPC IPAM). For IAM, use AWS IAM Identity Center (SSO) with permission sets assigned to accounts — engineers assume time-limited roles via SSO rather than holding long-lived IAM users in each account.

Common failure modes

• Slow account vending: Manual account provisioning steps (ticket-based approvals, manual SCP attachment) that take days or weeks defeat the purpose; automate end-to-end with AFT or a similar pipeline targeting <30 min provisioning.
• SCP over-restriction: SCPs applied at root OU that deny services needed by security tooling (e.g., denying AWS Lambda prevents GuardDuty findings remediation); always test SCPs in sandbox OU before applying to production.
• CIDR exhaustion: Not pre-allocating IP ranges before the first accounts are created leads to overlapping CIDRs that prevent TGW route table configuration.
• Drift from baseline: Teams bypass the account vending machine to create accounts directly, or modify SCPs without change control, breaking the landing zone consistency guarantees.
• No sandbox OU: Without a clearly defined low-guardrail sandbox, developers experiment in production-adjacent accounts or escalate every request for relaxed permissions.

Decision checklist

• Is your OU hierarchy designed around security and compliance boundaries, not org chart structure?
• Can a new team account be provisioned end-to-end in under 30 minutes via self-service?
• Are CloudTrail, Config, GuardDuty, and SecurityHub enabled and centralised in every account by default?
• Have you pre-allocated non-overlapping CIDR ranges for all current and projected accounts?
• Are SCPs documented, version-controlled, and tested before deployment to production OUs?
• Do developers access accounts via SSO/federated roles rather than long-lived IAM user credentials?

Example use cases

• Enterprise AWS migration: 200-person engineering org migrates from a shared account to 40 workload accounts over 6 months, using AFT to provision accounts and Transit Gateway for private inter-account connectivity; security team gains centralised GuardDuty findings in the Audit account without any per-account configuration.
• PCI-DSS compliance: Cardholder data environment (CDE) isolated in its own OU with SCPs that restrict to approved regions only, deny internet gateway attachment, and require CMK encryption for all EBS volumes; Config rules continuously verify compliance.
• SaaS product with per-tenant isolation: Account vending machine provisions a new AWS account for each enterprise customer, attaching it to the TGW and applying tenant-specific SCPs; customer data is completely isolated at the account boundary.

Related patterns

• Shared Responsibility Model — defines what the cloud provider secures vs what the landing zone and workload teams must implement.
• Cloud Networking — Transit Gateway, VPC design, and hub-spoke topology that the landing zone networking account implements.
• Cloud Cost Optimization — per-account cost allocation tags and budget policies enforced via landing zone SCPs and account factory.
• Infrastructure as Code — AFT and Terraform modules are the execution layer for landing zone provisioning.

Further reading

• AWS Control Tower — User Guide
• Azure Landing Zones — Microsoft Cloud Adoption Framework
• Google Cloud Security Foundations Blueprint