Azure Landing Zone vs Hub-Spoke: Which Architecture Fits Your Org?
Choosing between an Azure Landing Zone and a Hub-Spoke network layout is one of the first strategic calls a solution architect makes. Both patterns can deliver governance, security, and scale, but they solve different problems and carry different operational trade-offs. This guide explains the core ideas, how to decide, and how to implement each approach in production-grade environments.
Key concepts
A Landing Zone is a prescriptive foundation for subscriptions, identity, policy, security, networking, and management. It standardizes how teams deploy workloads across the organization. A Hub-Spoke layout is a network topology: a shared hub provides connectivity and shared services, while spokes host isolated application VNets.
- Landing Zone: enterprise baseline spanning management groups, policies/initiatives, RBAC, logging, identity, and optionally a standard network design.
- Hub-Spoke: network segmentation that centralizes shared services (firewall, DNS, bastion) in a hub and connects application spokes via peering.
- They are complementary. A Hub-Spoke layout can live inside a Landing Zone. The decision is not either/or, but which scope to start from.
Design approach
When to lead with a Landing Zone
Start here when you have multiple teams or business units, compliance needs, and a goal to standardize how subscriptions are created and governed.
- Define a management group hierarchy (Tenant Root, Corp, Sandbox, Platform, Online/Offline workloads).
- Assign policy initiatives for security baselines, tags, approved SKUs, and diagnostic settings.
- Enable platform services: centralized Log Analytics workspace, Defender for Cloud, budget alerts.
- Integrate identity (Entra ID) and privileged access (PIM) for just-in-time admin on platform resources.
- Optionally prescribe a default network pattern: hub services, address conventions, and peer-reviewed VNet ranges.
When to lead with Hub-Spoke
Start here when the organization already has clear governance but needs secure, segmented connectivity and shared services.
- Create a platform hub VNet for egress control and shared services: Azure Firewall, Bastion, Private DNS, VPN/ExpressRoute gateways.
- Provision application spokes per workload or domain. Enforce address planning to avoid overlap.
- Use VNet peering with proper routing and UDRs. Force Internet egress through the hub firewall.
- Expose PaaS over Private Endpoints in spokes; resolve via Private DNS zones linked to hub/spokes.
- Monitor via a central workspace; route platform and workload diagnostics consistently.
Decision path
Use a Landing Zone-first approach when governance, compliance, and scale across many teams are the main drivers. Use Hub-Spoke-first when network segmentation and shared services are the immediate blockers. In most enterprises, the steady state is: Landing Zone (org-level baseline) plus Hub-Spoke (network realization) inside it.
Common pitfalls and best practices
- Leaving policy until later. Define and assign initiatives early; retrofit is costly.
- Unplanned address space. Reserve ranges up front for hub and future spokes; avoid renumbering.
- Mixing security controls. Decide what the hub enforces (egress via firewall) versus what the spokes own.
- Ignoring operations. Standardize diagnostics, budgets, alerts, and backup policy at management group scope.
- Over-peering. Keep peering purposeful; prefer hub mediation for east-west traffic and inspection.
- Public endpoints by default. Prefer Private Endpoints and Private DNS for PaaS data access.
- Inconsistent identity. Enforce RBAC patterns and PIM for platform and workload teams.
- One-region thinking. Plan paired regions and document failover/DR patterns from day one.
Diagram
The diagram below shows a Landing Zone management structure with policies at management group scope and, within the platform subscription, a Hub-Spoke network: hub services (firewall, bastion, DNS, gateways) and application spokes with Private Endpoints. Traffic flows through the hub for egress and inspection, while spokes remain isolated.
Conclusion
Treat the Landing Zone as your organizational baseline and Hub-Spoke as the repeatable network pattern within it. Decide which to prioritize based on current constraints: governance maturity or connectivity and segmentation. Standardize early, document decisions as ADRs, and automate provisioning so new workloads inherit the same strong defaults.