We see this in almost every engagement. Someone signs up for Azure, creates a subscription, spins up a couple VMs, and starts migrating workloads. Fast forward six months — three subscriptions with no naming convention, a completely flat network, zero cost management, and five people sharing the same admin credentials. Nobody planned it that way. It just... happened. And that's the problem. It's not a technology failure. It's a "we skipped the boring foundation work" failure.
What an Azure Landing Zone Actually Is
Strip away the marketing and an Azure Landing Zone is just this: a pre-configured environment — subscriptions, management groups, policies, networking, identity — built according to Microsoft's Cloud Adoption Framework. Think of it as answering five questions before you touch a single resource:
Organization
How are we grouping and governing subscriptions?
Networking
How do resources actually talk to each other?
Identity
Who gets access to what — and how do we prove it?
Governance
What guardrails stop someone from deploying something dumb?
Security
Where do logs go and how do we catch threats?
The Management Group Hierarchy
Tenant Root Group
└── Organization (top-level)
├── Platform
│ ├── Management (Log Analytics, Automation)
│ ├── Identity (Domain Controllers, Entra Connect)
│ └── Connectivity (Hub VNet, VPN, DNS)
├── Landing Zones
│ ├── Corp (internal workloads)
│ └── Online (internet-facing)
├── Sandbox (dev/test)
└── DecommissionedThe beauty of this structure: assign a policy at the Platform level and it automatically cascades to every subscription underneath. Same with RBAC. Grant a role at Landing Zones and it flows down. You configure once, not per-subscription.
Subscription Topology
Subscriptions are free. There's zero excuse for putting everything in one. Yet we walk into this constantly. The landing zone pattern separates by function, and here's why it matters:
Platform Subscriptions
- Management — Log Analytics, Azure Monitor, Defender for Cloud
- Identity — Entra Connect, domain controllers, PIM
- Connectivity — Hub VNet, VPN Gateway, Azure Firewall, DNS
Application Subscriptions
- Corp — Internal LOB apps, file servers, databases
- Online — Internet-facing web apps, APIs, CDN services
If you're under 500 users, don't overthink it. Start with three subscriptions: Platform (combined), Production, and Sandbox. You can split them later. The point is separation from day one.
Hub-Spoke Networking
This is the part that saves you when something goes wrong. One hub VNet handles your shared services — VPN gateway, firewall, DNS. Spoke VNets peer to the hub and host your actual workloads. Every packet crosses a chokepoint where you can inspect it, log it, and kill it if needed. No hub? You're flying blind.
Hub VNet
Address: 10.0.0.0/16
GatewaySubnet, AzureFirewallSubnet, DNS
VPN Gateway, Azure Firewall, Private DNS Resolver
Spoke VNets
Address: 10.1.0.0/16, 10.2.0.0/16, etc.
Application, Data, Management subnets
Peered to hub via VNet Peering
Learned this the hard way: Plan your IP address spaces on paper before you create a single VNet. Overlapping address ranges break peering, and re-IPing a production VNet is nobody's idea of a good time.
Azure Policy Assignments
Without policies, your landing zone is just a nice diagram in a PowerPoint deck. Azure Policy is what actually enforces the rules. This is where theory becomes reality.
| Initiative | Applied To | What It Enforces |
|---|---|---|
| Deploy-Diagnostics | Tenant Root | Forces every resource to ship diagnostics to your central Log Analytics workspace |
| Enforce-ALZ-Sandbox | Sandbox MG | Keeps sandbox isolated — no peering, no VPN, no hybrid connectivity |
| Deny-PublicIP | Corp MG | Blocks public IPs on internal workloads (you'd be surprised how often this gets missed) |
| Deploy-ASC-Defender | Landing Zones | Turns on Defender for Cloud across all landing zone subscriptions automatically |
| Allowed-Locations | Tenant Root | Locks deployments to your approved regions — no rogue resources in random geographies |
Pro tip: always start with Audit mode, never Deny. Let it run for a week or two, review the compliance results, make sure you're not about to break something critical, then flip to Deny. Trust us on this one.
Common Mistakes
Flat management group structure
Everything dumped under Tenant Root Group. No inheritance, no boundaries. It's the Azure equivalent of a junk drawer.
Single subscription for everything
Production VMs, dev/test, shared services — all piled into one subscription. Again: subscriptions are free. Use them.
No hub networking
Every subscription gets its own VNet with no peering, no firewall, no centralized DNS. Good luck troubleshooting that.
Permanent admin roles
We can't tell you how many times we've walked into a tenant with five people holding permanent Owner on every subscription. That's what PIM is for — just-in-time elevation, not permanent keys to the kingdom.
No IP address planning
Three VNets all using 10.0.0.0/16 that can never peer. This one hurts because it's so easy to prevent and so painful to fix.
Skipping policies
The landing zone looks great in the diagram but nothing is actually enforced. It's decoration, not governance.
No logging baseline
Resources deployed with no diagnostic settings. Then something happens and there are zero logs to investigate. You're guessing.