Landing zones on AWS, Azure and GCP: the same five decisions
Every cloud has its own landing zone accelerator, and they all look different. Underneath, I keep coming back to the same five questions.
AWS, Azure and Google Cloud each have their own landing zone accelerator, and each comes with its own diagrams and vocabulary. The first time I worked across all three, I thought I’d need three different mental models.
It turns out I don’t. Whenever I review a setup, I ask the same five questions, whatever the cloud. Here they are.
1. How do people and workloads prove who they are?
- Pick one identity provider (Entra ID, Okta, Google Workspace, whatever you already use) and federate it into every cloud.
- Humans get access through groups. Never through one-off assignments that someone forgets about.
- Workloads use workload identity or IAM roles. If I find long-lived keys in a CI system, that goes to the top of the report.
2. How is everything organised?
The names change, but the ideas map across pretty cleanly:
| Concept | AWS | Azure | GCP |
|---|---|---|---|
| Top-level policy | Organization / SCPs | Management groups | Organization |
| Unit of isolation | Account | Subscription | Project |
| Grouping | OU | Management group | Folder |
My one piece of advice: group by blast radius and ownership, not by org chart. Org charts change every year. Blast radius doesn’t.
3. What does the network look like?
Hub-and-spoke is still a safe default. What I really want to see is an IP address plan agreed early. Overlapping CIDR ranges are one of the most expensive mistakes to undo later, and I’ve watched a few teams learn that the hard way.
4. What are the guardrails?
Use preventive controls (SCPs, Azure Policy, Org Policy) for the handful of things that must never happen. Use detective controls (Config, Defender, Security Command Center) for everything else. If you try to prevent everything, people will find a way around it.
5. Can you see what’s happening, and what it costs?
That means a central log archive, a tagging standard that’s actually enforced by policy, and budgets with alerts on every account, subscription or project from day one. Not “once we go live”. Day one.
Once these five decisions are written down and codified in Terraform, the provider-specific accelerator becomes an implementation detail. It’s no longer the thing driving your design.
Found a sixth question that belongs on this list? Tell me, I’m always happy to steal a good idea.
Written by Daniel Ulisses
Cloud Architect & DevOps Engineer. I write about cloud platforms, GitOps and bringing AI into DevOps workflows. Questions or feedback on this post? I'd love to hear it.