What is a cloud landing zone? A checklist for Azure, AWS and Google Cloud

What is a cloud landing zone?

A cloud landing zone is the governed foundation every workload inherits. Microsoft describes an Azure landing zone as an architecture for governing, securing and scaling a multi-subscription environment. AWS Control Tower calls it a well-architected multi-account environment based on security and compliance best practices, and Google Cloud describes it as often a prerequisite to deploying enterprise workloads.

The core idea is separating platform from workloads. Microsoft distinguishes a platform landing zone, which holds central governance and shared services, from application landing zones where workload teams deploy within those guardrails.

How should you structure accounts, subscriptions and projects?

On Azure, management groups organise subscriptions, and policies applied to a management group are inherited by every subscription beneath it. Microsoft's reference hierarchy keeps platform subscriptions for identity, management, security and connectivity apart from workload management groups such as Corp, Online and Local. Most organisations need only one platform landing zone per Microsoft Entra tenant.

On AWS, Organizations groups accounts into organisational units, and Control Tower orchestrates Organizations, IAM Identity Center and Service Catalog, with Account Factory provisioning accounts from pre-approved configurations. On Google Cloud, the organisation resource is the root node, folders are an optional grouping layer for departments or teams, and projects are the unit for enabling APIs, billing and permissions.

Which identity and access controls come first?

Connect one authoritative directory before anything else. Azure uses Microsoft Entra ID with Azure role-based access control. AWS uses IAM Identity Center, which Control Tower can configure with groups and single sign-on. Google Cloud supports Cloud Identity or Google Workspace, federation with a provider such as Microsoft Entra ID or Okta, or Workforce Identity Federation.

• Assign roles to groups, not individuals, at the highest scope where access applies.
• Enforce multi-factor authentication and keep a small, monitored set of emergency access accounts.
• Keep workloads out of the AWS management account, because service control policies do not restrict it.
• Give pipelines workload identities, such as managed identities, IAM roles or service accounts, instead of long-lived keys.

What network topology suits a landing zone?

Hub-and-spoke is a common starting point: a central hub carries shared firewalls, gateways and DNS, and each workload network is a spoke. Microsoft's reference architecture places the hub in a dedicated connectivity subscription, with Azure Virtual WAN as an alternative. On AWS, Transit Gateway interconnects VPCs and on-premises networks. Google Cloud's enterprise foundations blueprint offers two Shared VPC topologies: a separate network for each environment, or hub-and-spoke with a network virtual appliance in the hub filtering traffic between environments.

Allocate non-overlapping IP ranges for every region and environment before the first workload lands. Decide early where outbound traffic is inspected and how private DNS resolves between hub and spokes.

How do security guardrails work on each cloud?

Guardrails are rules set high in the hierarchy that everything below inherits. Azure Policy can deny, audit or modify resources across a management group. AWS service control policies set the maximum available permissions for IAM users and roles in member accounts; they never grant permissions and do not affect the management account. Google Cloud organisation policies use constraints that descendants inherit by default. In Google's framing, IAM focuses on who, while organisation policy focuses on what.

Typical baseline guardrails restrict regions, block public storage, require encryption, protect central logging and require cost tags. On AWS, use the Control Tower Region deny control rather than a custom SCP, because AWS warns that denying Regions through SCPs puts Control Tower into an undefined state. Control Tower also offers detective and proactive controls.

Roll guardrails out gradually. AWS advises testing SCPs on a test OU, moving accounts in a few at a time, before attaching them to the organisation root. Azure Policy's audit effect and Google Cloud's dry-run mode for organisation policies support the same staged approach.

Where should audit logs and cost data live?

Centralise audit and platform logs where workload teams can read but not alter them. An AWS CloudTrail organisation trail logs events for the management account and every member account, and member accounts cannot modify or delete it. On Azure, Log Analytics workspaces in a management subscription collect logs, and built-in Azure Policy initiatives can automatically create diagnostic settings that send resource logs there. Google Cloud aggregated sinks route logs from an organisation or folder and its children to one destination.

Agree a tagging standard, typically owner, cost centre, application and environment, before resources exist. Azure Policy can add or require tags. AWS cost allocation tags must be activated before they appear in billing reports. Google Cloud labels flow into billing data for cost breakdowns.

How do you build a landing zone with infrastructure-as-code?

Treat the landing zone as a product with its own repository, code reviews and deployment pipelines. Microsoft recommends its Azure Landing Zones IaC accelerator, built on Azure Verified Modules for Terraform or Bicep, over the portal accelerator. AWS Account Factory for Terraform (AFT) sets up a Terraform pipeline to provision and customise Control Tower accounts in a GitOps model. Google Cloud advises using infrastructure-as-code, giving Terraform as an example, and publishes the enterprise foundations blueprint with a deployable Terraform example foundation.

Keep platform code separate from application code; AWS notes that AFT is for provisioning and customising accounts, not deploying workload resources. Make changes only through the pipeline or the provider's supported tools; AWS warns that modifying or deleting Control Tower managed resources outside its supported methods will cause the landing zone to enter an unknown state.

What does a practical landing zone checklist look like?

Work through the steps in order, since each builds on the one before. WIEWAVE, a cloud, DevOps and AI company, can help at any stage, delivering the landing zone as reviewable infrastructure-as-code that your team keeps.

1. 1Agree requirements: compliance obligations, regions, environments and platform ownership.
2. 2Set up billing, the tenant or organisation root, and naming and tagging standards.
3. 3Set up a repository and reviewed pipeline, then define everything as code from the first change, in Terraform, Bicep or AWS CloudFormation.
4. 4Connect your identity provider, enforce multi-factor authentication and define group-based roles.
5. 5Build the management group, OU or folder hierarchy, separating platform from workloads.
6. 6Create shared platform environments for identity, logging, security and connectivity.
7. 7Plan IP addressing, then deploy the hub network, DNS and firewall.
8. 8Trial guardrails in audit or dry-run mode, or in a test OU, before enforcing them.
9. 9Centralise audit logs, security findings and monitoring with agreed retention.
10. 10Enable budgets, cost alerts and tag enforcement for every environment from day one.
11. 11Automate subscription, account or project vending for new workloads.
12. 12Migrate a low-risk pilot workload, then refine the baseline.