🌐 Building an Azure Landing Zone in an Existing Hub-and-Spoke Architecture

As organizations scale their cloud infrastructure, a landing zone becomes a foundational construct for deploying workloads in a governed, secure, and scalable way.
But what happens when you already have an existing hub-and-spoke network topology in Azure?

Good news: you don’t need to redesign everything. You can integrate new landing zones into your current setup by adding new spokes and connecting them to the existing hub.

🧭 Quick Recap: What Is a Hub-and-Spoke Network?

The hub-and-spoke topology is a well-architected model where:

  • The hub is a central VNet that hosts shared services (firewalls, DNS, VPNs, Azure Bastion, etc.).
  • Spokes are VNets that host workloads or landing zones and connect to the hub using VNet peering.

🏗️ Scenario: Adding a New Landing Zone

Let’s say your organization wants to provision a new environment (for example, for a new business unit or application workload) within your existing network.

Instead of creating a new isolated network, you’ll create a new spoke VNet and peer it with the existing hub.

🔧 Step-by-Step: Integrate a Landing Zone into the Hub-and-Spoke Model

1. Create a New Subscription or Use an Existing One

Landing zones are often deployed in separate subscriptions to isolate workloads, apply policies, and manage billing more effectively.

💡 Tip: Use Management Groups and Azure Policy to apply guardrails at scale.

2. Create a Resource Group for the Landing Zone

az group create --name rg-landingzone-prod --location eastus

3. Provision the Spoke Virtual Network

az network vnet create \
  --resource-group rg-landingzone-prod \
  --name vnet-spoke-prod \
  --address-prefix 10.20.0.0/16 \
  --subnet-name snet-app \
  --subnet-prefix 10.20.1.0/24

4. Peer the New Spoke VNet to the Existing Hub VNet

Assuming your hub VNet is in a separate subscription, you’ll need to:

  • Enable VNet peering from spoke to hub
  • Then from hub to spoke

From Spoke to Hub:

az network vnet peering create \
  --name spoke-to-hub \
  --resource-group rg-landingzone-prod \
  --vnet-name vnet-spoke-prod \
  --remote-vnet /subscriptions/<hub-subscription-id>/resourceGroups/<hub-rg>/providers/Microsoft.Network/virtualNetworks/<hub-vnet-name> \
  --allow-vnet-access

From Hub to Spoke:

az network vnet peering create \
  --name hub-to-spoke \
  --resource-group <hub-rg> \
  --vnet-name <hub-vnet-name> \
  --remote-vnet /subscriptions/<landing-zone-subscription-id>/resourceGroups/rg-landingzone-prod/providers/Microsoft.Network/virtualNetworks/vnet-spoke-prod \
  --allow-vnet-access

5. Configure Route Propagation and Security

  • Use User Defined Routes (UDRs) if necessary to route traffic through a firewall in the hub.
  • Ensure Network Security Groups (NSGs) in the spoke allow required traffic.
  • Integrate with Azure Firewall, Route Server, or NVAs for advanced scenarios.

6. Apply Policies and Blueprints

  • Use Azure Policy to enforce rules (e.g., region restrictions, tag enforcement).
  • Deploy Azure Blueprints or Bicep/Terraform templates for standardized environments.

🛡️ Optional: Integrate with Shared Services

Once peered, the new landing zone (spoke) can access services in the hub:

  • Private DNS zones
  • Azure Bastion
  • Firewalls and NVAs
  • On-prem connectivity via ExpressRoute or VPN

✅ Summary

Expanding an existing hub-and-spoke network to include new landing zones is not only possible — it’s the recommended approach to scale securely and efficiently.
By peering new VNets (spokes) to the hub, you retain centralized governance and shared services while giving teams autonomy within their landing zones.

💬 Looking Ahead

For enterprise-scale deployments, consider automating with:

  • Terraform or Bicep
  • Azure Landing Zone Accelerator
  • Azure DevOps Pipelines or GitHub Actions

Have questions or want a visual walkthrough of this architecture? Drop a comment or connect — happy to help!