Skip to main content

AWS Glossary

AWS Landing Zone

Multi-account AWS environment blueprint providing baseline security, compliance, and operational foundation.

Definition

An AWS landing zone is a multi-account AWS environment pre-configured with security, networking, logging, and operational baselines so workload teams can deploy faster without reinventing governance per project. Typical building blocks include an organization structure (management, shared services, security, workload OUs), centralized logging (CloudTrail, Config), identity federation (IAM Identity Center), network foundations (VPCs, Transit Gateway), encryption (KMS), and organization-wide guardrails (SCPs). AWS Control Tower is AWS’s managed implementation of a landing zone; you can also build one manually or from AWS Solutions Library templates.

When to use it

  • Any organization moving from one or few accounts to many accounts with consistent security and billing boundaries
  • Regulated industries (healthcare, fintech) that need segregated accounts for audit scope and blast-radius containment
  • Platform teams establishing shared services (central logging, DNS, egress, CI/CD) once instead of per team
  • Migrations where you need a target environment before lifting workloads

When not to use it

  • Early-stage single-account startups with one product and no compliance mandate — a well-hardened single account plus good IAM is enough until complexity demands split
  • “Landing zone” as a one-time project with no ongoing enforcement — without SCPs and monitoring, accounts drift within weeks
  • Copy-pasting another company’s OU diagram without mapping your teams, data classification, and network topology

Tips

  • Design the account vending process before the network diagram — who gets an account, how long provisioning takes, and who pays the bill
  • Centralize CloudTrail and security-tooling accounts early; retroactive log aggregation across ad hoc accounts is painful
  • Document tagging standards in the landing zone baseline — cost allocation and Config rules depend on consistent tags
  • Plan workload account patterns (dev/staging/prod per product vs per environment OU) upfront; moving accounts between OUs is workable but slow
  • Pair the landing zone with a network hub strategy (Transit Gateway or centralized egress) before hundreds of VPCs sprawl

Gotchas

Serious

  • Scope without enforcement: A landing zone document that teams ignore is worse than no landing zone — drift creates a false sense of compliance.
  • Shared services as a bottleneck: Central networking or identity teams without SLAs become the critical path for every new workload.
  • Compliance one-size-fits-all: Healthcare, PCI, and general SaaS workloads often need different account baselines — a single template may over- or under-constrain.

Regular

  • Confusing “landing zone” (architecture pattern) with “Control Tower” (managed product) leads to wrong tooling choices in RFPs and internal roadmaps.
  • Landing zone templates age — review AWS Prescriptive Guidance and Solutions updates when enabling new regions or services.
  • Workload teams sometimes create shadow accounts outside Organizations to “move faster,” undoing centralized governance.

Official references

Need help with this topic?

Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.