Landing Zone

What is a landing zone?

A landing zone is a pre-configured, secure, well-architected cloud environment established before you start deploying workloads — the foundational setup that gets your multi-account structure, networking, identity, security controls, logging, and governance right from day one, so applications “land” in a properly-governed environment rather than a greenfield free-for-all. The core idea is build the foundation first: rather than spinning up cloud resources ad hoc and trying to retrofit security, account structure, and governance later (painful, error-prone, and often never done properly), you set up a solid, standardized, secure baseline up front that every workload inherits.

What a landing zone includes

A landing zone codifies the foundational decisions and controls that are hard and disruptive to change once workloads are running. Typically it establishes: a multi-account structure (separate accounts for production, development, security, logging, shared services — using accounts as strong isolation boundaries, organized into OUs) rather than everything in one account; identity and access foundations (centralized SSO/IAM, federation, role structures, least-privilege baselines); network architecture (VPC design, connectivity, segmentation, hybrid links); security guardrails (org-wide policies like SCPs that cap what accounts can do, encryption baselines, allowed regions); centralized logging and monitoring (aggregating audit logs — CloudTrail, Config — into a dedicated security/logging account so they can’t be tampered with and are consistently collected); and compliance controls appropriate to the organization. The through-line is that these are the cross-cutting foundations every workload depends on, and getting them consistent and secure once, centrally, is vastly better than each team improvising. Cloud providers offer tooling to build landing zones: AWS Control Tower (automates a multi-account landing zone with guardrails on top of AWS Organizations), Azure Landing Zones (part of the Cloud Adoption Framework), and Google Cloud’s landing-zone guidance and blueprints — plus Terraform modules and reference architectures.

Why it matters, and the realities

The value of a landing zone is doing governance right before scale makes it impossible to fix. Without one, organizations start deploying workloads in an unstructured environment, and by the time they realize they need proper account isolation, centralized logging, consistent guardrails, and identity governance, they have dozens of workloads deeply embedded in an insecure, inconsistent setup — and retrofitting foundations under running production workloads is genuinely hard, risky, and frequently deferred forever. A landing zone front-loads that work so the foundation is solid and every new workload inherits security, governance, and best practices by default rather than by hoping each team gets it right. It embodies “secure by design” and “shift-left governance” at the infrastructure level. The realities: a landing zone is an investment up front (setting it up takes real effort and expertise, which is why provider tooling like Control Tower exists to accelerate it), and it must be treated as living, not one-time — it evolves as the organization’s needs, scale, and compliance requirements change, so it needs ongoing ownership (often a platform/cloud-foundation team). It should also balance guardrails with autonomy: too rigid and teams are blocked and route around it; too loose and it doesn’t actually govern — the goal is guardrails that keep teams safe while letting them move fast (self-service within safe boundaries). The recurring mistakes: skipping the landing zone and deploying workloads into an ungoverned environment (then facing painful retrofitting), treating it as a one-time setup that then goes stale, making it so restrictive that teams bypass it, and building it entirely by hand instead of leveraging provider frameworks (Control Tower, Azure Landing Zones) that encode proven patterns.

What people get wrong

• Skipping it and retrofitting later — deploying workloads into an ungoverned environment and trying to add account isolation, logging, and guardrails afterward is painful, risky, and often never finished properly.
• Treating it as one-and-done: a landing zone must evolve with the organization’s scale and compliance needs — without ongoing ownership it goes stale and stops reflecting reality.
• Too rigid or hand-rolled — overly restrictive guardrails make teams route around it, and building from scratch reinvents solved problems; balance safety with self-service and use provider frameworks (Control Tower, Azure Landing Zones).

Primary source: AWS: What is a landing zone?