What Is a Cloud Landing Zone? AWS, Azure, and GCP Compared

A landing zone is the governed, multi-account (or multi-subscription, or multi-project) foundation you provision before a single workload runs on it. Identity, network topology, centralized logging and audit, security guardrails, and a cost baseline all exist on day one — not retrofitted after account forty, when three different teams have already built three different IAM conventions and nobody can tell you which accounts have which guardrail version.

The term originated with AWS's own reference solution, but the pattern isn't AWS-specific. All three major clouds now ship an opinionated answer to the same underlying problem: how do you let teams self-serve new accounts/subscriptions/projects without each one being a blank, ungoverned slate.

The problem a landing zone solves

Without one, this is the trajectory every growing cloud estate follows:

1. Someone needs a new AWS account (or Azure subscription, or GCP project) for a workload. They ask a platform engineer, who clicks through a console wizard.
2. The new environment has no standard IAM roles, no centralized logging, no network peering back to shared services, no budget alarms. Someone builds those by hand — differently than the account before it.
3. Six months and thirty environments later, nobody can answer "which environments have the current security baseline" without checking each one individually.
4. An audit asks "show me every account's logging configuration" and the honest answer is a week of manual work.

A landing zone front-loads all of that. The governance model — who can create what, what gets logged, what network paths exist, what policies are non-negotiable — is defined once, as code, and every new environment inherits it automatically. The engineering discipline here is the same one behind infrastructure as code generally: describe the desired state once, apply it repeatably, and stop hand-building things that should be generated.

The building blocks, regardless of cloud

Strip away the product names and every major cloud's landing zone answer is solving the same handful of problems:

• Resource hierarchy. A way to group accounts/subscriptions/projects (AWS Organizational Units, Azure management groups, GCP folders) so policy can be applied at a level above "one resource at a time."
• Identity foundation. Centralized identity (AWS IAM Identity Center, Azure Entra ID, GCP Cloud Identity) so access is federated in, not created locally per environment.
• Centralized logging and audit. One place logs and audit trails land, independent of which team owns the workload account.
• Guardrails, not gates. Preventive controls (service control policies, Azure Policy, GCP organization policies) and detective controls (config/compliance monitoring) applied at the hierarchy level, so a new environment inherits them automatically instead of a human remembering to apply them.
• A repeatable vending process. Some way to request and provision a new governed environment that doesn't involve a platform engineer clicking through a console form every time.

Where the clouds genuinely differ is which of these you get by default, which you have to explicitly wire up, and what the actual, current product name is — and this is exactly the part that's full of outdated information online, because all three vendors have renamed or restructured their offerings at least once.

AWS: Control Tower is the current answer

AWS's original standalone "AWS Landing Zone" solution — a CloudFormation-based reference implementation from before AWS had a managed multi-account service — has been superseded. Its old implementation-guide URL now redirects into AWS Control Tower's own customization documentation, and Control Tower's current FAQ doesn't reference the old solution at all. If you find a guide describing "AWS Landing Zone" as a thing you deploy from scratch today, treat it as historical, not current.

AWS Control Tower is the managed service that replaced it: it establishes the multi-account structure (via AWS Organizations), a Log Archive account, an Audit account, and applies guardrails through Account Factory when you vend a new account. It's the default starting point for a new AWS landing zone today.

Two things sit alongside Control Tower, and people regularly conflate all three:

• Customizations for AWS Control Tower (CfCT) — a GitOps framework for extending what an already-deployed Control Tower landing zone does, using CloudFormation templates tied to Control Tower's lifecycle events. It doesn't create accounts; it customizes what happens to them.
• Landing Zone Accelerator on AWS (LZA) — a config-driven (YAML), CDK-based, open-source solution that layers a large, prescriptive control set (network architecture, 35+ AWS security/logging services) on top of an existing Control Tower deployment. AWS's own guidance is explicit here: deploy Control Tower first as the foundational landing zone, then enhance it with LZA — LZA even uses Control Tower's own Account Factory to vend accounts. It's not a standalone alternative to Control Tower; treat it as the layer you add when you need a prescribed architecture matching a published compliance framework, and correspondingly harder to deviate from if you don't.

If you're automating account creation on top of Control Tower specifically with Terraform, that's a distinct third option — AWS Account Factory for Terraform (AFT) — and I've written a full deep-dive on when it's worth the operational weight and when it isn't: AWS Account Factory for Terraform (AFT).

Azure: landing zones under the Cloud Adoption Framework

Microsoft's current terminology, under the Cloud Adoption Framework (CAF), splits an Azure landing zone into two pieces:

• Platform landing zone — the centralized foundation: the management group hierarchy, centralized connectivity/security/identity resources, and the process for distributing new application landing zones to teams. Most organizations should have exactly one per Microsoft Entra tenant.
• Application landing zones — one per workload, containing that workload's dev/test/prod environments (each potentially its own subscription), inheriting governance from wherever the platform team placed it in the management group hierarchy (Microsoft's baseline hierarchy groups these under Corp, Online, or Local management groups).

Microsoft's currently recommended deployment path is the Azure Landing Zones IaC Accelerator, built on Azure Verified Modules (AVM) for either Terraform or Bicep — a four-phase process (plan → prerequisites → bootstrap → run) that sets up the CI/CD pipeline and then deploys the platform landing zone from code. For teams without IaC in place yet, there's also an Azure platform landing zone portal accelerator — a console-driven deployment — though Microsoft is explicit that the portal path is harder to version and update over time and recommends moving to IaC when you can.

GCP: officially called a landing zone, delivered as a Terraform foundation

Google Cloud is the one vendor here that uses the term "landing zone" in its own official documentation without a rename — Google also calls it a cloud foundation, and defines it around the same four elements as everyone else: identity provisioning, resource hierarchy, network design, and security controls.

The two paths Google documents:

• Terraform Example Foundation (terraform-google-modules/terraform-example-foundation) — an opinionated, deployable landing zone covering organization structure, folders, projects, and networking, meant to be forked and adapted rather than used as-is.
• Enterprise Foundations Blueprint — Google's security-focused reference architecture, documented as an opinionated view of Google Cloud security best practices.

There's also a console-based Google Cloud Setup guide for a lighter-weight starting point, but the Terraform Example Foundation is what most teams reach for when the goal is a real, version-controlled organizational baseline.

The comparison, side by side

Getting started

The honest starting point on any of the three is the same: don't design your ideal landing zone from a whiteboard first. Deploy the vendor's own reference implementation, understand what it actually does, and customize from there — that's a far shorter path than hand-building a resource hierarchy and guardrail set from scratch and discovering the gaps later.

I've written hands-on setup tutorials for each cloud's current path:

• Setting Up an AWS Landing Zone with Control Tower
• Setting Up an Azure Landing Zone
• Setting Up a GCP Landing Zone with Terraform

And if you're specifically on AWS and already have Control Tower running, the AFT deep-dive covers whether automating account vending on top of it is worth the operational weight for your account count.

Frequently Asked Questions

Is a landing zone the same as a "cloud foundation"?

Functionally, yes — Google Cloud's own documentation uses the two terms interchangeably. AWS and Microsoft use "landing zone" without the "cloud foundation" label, but describe the same underlying pattern: a governed environment that exists before workloads land on it.

Do I need Control Tower to have an AWS landing zone?

Strictly, no — nothing stops you from hand-building the equivalent governance directly on AWS Organizations plus your own Terraform or CloudFormation. In practice, though, both of AWS's own accelerators assume it: Landing Zone Accelerator's own guidance is to deploy Control Tower first and layer LZA on top (it uses Control Tower's Account Factory to vend accounts), and AFT automates Control Tower's account creation directly. Control Tower is the default recommendation because it's managed, comes with Account Factory built in, and is the foundation AWS's own tooling is built to sit on — not because it's technically the only path.

How long does setting up a landing zone actually take?

For the managed/accelerator paths (Control Tower, the Azure Landing Zones IaC Accelerator, Terraform Example Foundation), the initial deployment is typically hours, not weeks — the tooling is designed to get you to a working baseline fast. The time that actually varies is customization: mapping the reference architecture's assumptions onto your org's real requirements (network topology, existing identity provider, compliance obligations) is where a "quick start" turns into a multi-week project.

See also

• What Is Infrastructure as Code? — the underlying discipline every landing zone approach here depends on
• AWS Account Factory for Terraform (AFT) — automating account vending on top of an existing AWS Control Tower landing zone
• Terraform vs CloudFormation — relevant to the AWS IaC-path decision above
• AWS IAM Roles, Policies and IRSA — the identity layer a landing zone's account baseline should provision

---

Planning a multi-account/subscription/project foundation and not sure which of these paths fits your team? Get in touch — this is exactly the kind of decision that's cheaper to get right before account #5 than to unwind after account #50.

Official References

• AWS Control Tower customization documentation
• What is an Azure landing zone? — Microsoft Cloud Adoption Framework
• Platform landing zone implementation options — Microsoft Learn
• Google Cloud landing zones
• Terraform Example Foundation (terraform-google-modules)