A No-Nonsense Cloud Landing Zone Checklist (Azure, AWS, Google Cloud)

If you've ever been handed a brand-new Azure subscription, AWS account or Google Cloud project and told to "just get something running," you already know the real problem isn't the workload. It's everything around it: who's allowed to log in, how the network is wired, what stops someone from spinning up a public storage bucket at 2am, and where the audit logs actually end up. That governed foundation - the thing you build before any workload lands on it - is what the industry calls a cloud landing zone. Put simply: Microsoft calls an Azure landing zone the architecture behind governing, securing and scaling a multi-subscription setup. AWS's Control Tower documentation describes essentially the same thing - a well-architected, multi-account environment built around security and compliance. Google Cloud treats a landing zone as close to a prerequisite for any serious enterprise workload. Different vocabulary, same job: keep the platform (identity, network, guardrails, logging, cost) separate from the workloads that sit on top of it. ## Same concepts, three different names The confusing part of landing zones isn't the concept - it's that every cloud names the pieces differently: | What it does | Azure | AWS | Google Cloud | |---|---|---|---| | Groups everything | Management groups | Organizational units (OUs) | Folders | | Workload boundary | Subscriptions | Accounts | Projects | | Workforce identity | Microsoft Entra ID | IAM Identity Center | Cloud Identity / Workspace | | Preventive rules | Azure Policy | Service control policies | Organization policies | | Network hub | Hub VNet / Virtual WAN | Transit Gateway | Shared VPC, hub-and-spoke | | Central logging | Log Analytics workspace | CloudTrail org trail | Aggregated log sinks | Once you can translate between those three columns, "landing zone" stops being cloud-specific jargon and turns into a checklist you can run against any of them. ## Get identity right before anything else Every landing zone starts the same way: pick one authoritative directory and wire it up before a single resource gets provisioned. - Assign roles to groups, never individuals, at the highest scope the access should apply to. - Turn on MFA everywhere, and keep a small, actively watched set of break-glass accounts for emergencies. - Never let workloads sit inside the AWS management account - service control policies don't restrict it, so anything deployed there is ungoverned by definition. - Give pipelines their own identity - managed identities, IAM roles, service accounts - instead of long-lived static keys. ## Network: hub-and-spoke, still the default answer Most landing zones converge on the same topology: a central hub carrying shared firewalls, DNS and gateways, with every workload sitting in its own spoke network peered back to it. Azure typically wires this up as a dedicated connectivity subscription (or Virtual WAN); AWS does it with Transit Gateway; Google Cloud's enterprise foundations blueprint leans on Shared VPC in a similar hub-and-spoke shape. Pick non-overlapping IP ranges for every region and environment before the first spoke exists - retrofitting addressing after the fact is miserable. ## Guardrails: rules that sit above the workload This is the layer that actually stops mistakes from turning into incidents. Azure Policy can audit, deny or auto-remediate resources across a whole management group. AWS service control policies cap the maximum permissions available inside an account - they only restrict, they never grant anything. Google Cloud organization policies do the same job through inherited constraints. A sane starting baseline: restrict which regions can be used, block public storage by default, require encryption, and don't let anyone outside the platform team touch the logging account. Roll guardrails out in audit or dry-run mode first - on a test OU or a handful of accounts. Turning them on organization-wide before testing them is exactly how landing zones earn their bad reputation. ## Don't skip logging and cost tagging Centralize logs somewhere workload teams can read but not delete: an AWS CloudTrail organization trail, a Log Analytics workspace on Azure, an aggregated log sink on Google Cloud. Agree a tagging scheme - owner, cost centre, environment, application - before resources start getting created, because retrofitting tags across hundreds of existing resources later is its own special kind of pain. ## Build it as code, or don't bother A landing zone that got clicked together by hand in a console has already failed at its one job. Treat it like a product with its own repo, reviewers and pipeline: - Azure → Azure Verified Modules, in Terraform or Bicep - AWS → Account Factory for Terraform, layered on top of Control Tower - Google Cloud → the Terraform-based enterprise foundations blueprint Keep the platform repo separate from application code, and make changes only through that pipeline. Clicking around a landing zone's guardrails outside the tooling that manages them is exactly how AWS warns a Control Tower environment ends up in an unknown state. ## The condensed checklist 1. Nail down compliance requirements, regions and environments up front. 2. Stand up billing, the org root, and a naming/tagging standard. 3. Put everything behind a reviewed pipeline, as code, from commit #1. 4. Connect your identity provider, enforce MFA, define group-based roles. 5. Build the management group / OU / folder hierarchy - platform separate from workloads. 6. Stand up shared platform services: identity, logging, security, connectivity. 7. Plan IP ranges, then deploy the hub network and DNS. 8. Trial every guardrail in audit mode before you enforce it. 9. Centralize logs, and turn on budgets and cost alerts from day one. 10. Automate account/project vending, migrate one low-risk workload, then iterate. None of this has to be perfect on day one. It has to be code, reviewed, and moving in the right direction. --- A longer version of this - with full cloud-by-cloud comparison tables, Control Tower vs. a custom AWS build, and answers to things like "how long does this actually take" and "do small teams even need one" - is on the WIEWAVE guides hub: What is a cloud landing zone? A checklist for Azure, AWS and Google Cloud. WIEWAVE is a cloud, DevOps and AI company that builds landing zones like this for clients worldwide, delivered as infrastructure-as-code your team actually keeps. More at wiewave.com. For further actions, you may consider blocking this person and/or reporting abuse Top comments (0)