Scenario
You want to build a secure and scalable Azure network layout that separates environments such as Dev, Test, and Prod, while still allowing controlled communication between them. A Hub‑Spoke topology is a common enterprise pattern that centralises shared services (like firewalls, DNS, Bastion, or VPN gateways) in a hub VNET, while isolating workloads in spoke VNETs.
Azure VNET Peering allows these VNETs to communicate privately using Microsoft’s backbone network. In this lab, you’ll configure a hub VNET and peer it with three spoke VNETs representing Dev, Test, and Prod.
Lab Objectives
- Create a Hub‑Spoke network topology in Azure
- Deploy Hub, Dev, Test, and Prod VNETs
- Configure VNET peering between Hub and each Spoke
- Validate connectivity between VNETs
- Understand how traffic flows in a Hub‑Spoke design
Prerequisites
- Azure subscription
- Basic understanding of VNETs and IP addressing
- Azure Portal access
Create a Resource Group
Group all resources to keep your environment organised.
- Navigate to Resource Groups > + Create
- Set:
- Name:
rg-vnet-lab - Region:
UK South
- Name:
- Click Review + Create, then Create
Create Virtual Networks and Subnets
Create four isolated VNets for Hub, Dev, Test, and Prod. Each will have a single subnet with distinct address ranges. Use the table below when setting up each VNet.
Go to Virtual Networks > + Create for each one.
| VNet Name | Address Space | Subnet Name | Subnet Prefix |
|---|---|---|---|
vnet-dev | 10.0.0.0/16 | subnet-dev | 10.0.0.0/24 |
vnet-test | 10.1.0.0/16 | subnet-test | 10.1.0.0/24 |
vnet-prod | 10.2.0.0/16 | subnet-prod | 10.2.0.0/24 |
vnet-hub | 10.3.0.0/16 | subnet-hub | 10.3.0.0/24 |
Create VMs for testing connectivity
We’ll deploy one VM in each VNet. Only the Hub VM will have a public IP and allow SSH access (jump host). Spoke VMs remain private.
Use these settings in Virtual Machines > + Create for each VM:
| VM Name | VNet | Subnet | Public IP | VM Size | Auth Type | Inbound Ports |
|---|---|---|---|---|---|---|
vm-dev |
vnet-dev |
subnet-dev |
No | B2s | Password | None |
vm-test |
vnet-test |
subnet-test |
No | B2s | Password | None |
vm-prod |
vnet-prod |
subnet-prod |
No | B2s | Password | None |
vm-hub |
vnet-hub |
subnet-hub |
Yes | B2s | Password | 22 (SSH) |
Test connectivty before Peering
SSH into the Hub VM using its public IP. Then try to ping the private IPs of the Dev, Test, Prod VMs.
ping 10.0.0.4 # vm-dev
ping 10.1.0.4 # vm-test
ping 10.2.0.4 # vm-prod
Expected result:
Destination Host Unreachable
This confirms that the VNets are isolated and no connectivity exists yet.
Set up VNet Peering
For each connection:
- Go to Virtual Networks in the Azure Portal.
- Select
vnet-hub. - In the left-hand menu, Settings > Peerings
- Click + Add.
- Fill in the following:
- Peering link name (remote network):
dev-to-hub(ortest-to-hub,prod-to-hub) - Peering link name (local network):
hub-to-dev(orhub-to-test,hub-to-prod)
- Peering link name (remote network):
- Leave the default options ticked to allow access for both remote and local network.
- Click Add.
Test Connectivity After Peering
From inside vm-hub, ping spoke VMs private IPs again:
ping 10.0.0.4 # vm-dev
ping 10.1.0.4 # vm-test
ping 10.2.0.4 # vm-prod
This time you should get a response:
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=1.2 ms
You can also SSH into the spoke VMs from vm-hub:
ssh rajinder@10.0.0.4 # From within hub VM
Conclusion
We've now built a secure, scalable Azure networking lab with:
- Isolated VNets for Dev, Test, and Prod.
- A central Jump Host in the Hub for access.
- Security controls which ensure no external access to spoke VMs.
- VNet Peering to enable private traffic across VNets.
