Hub-and-spoke: segmentation you can prove.

The instinct of a beginner is to put everything in one virtual network because it "just works" — everything can reach everything. That is precisely the problem: when a single workload is compromised, a flat network lets the blast spread to all of them. The enterprise answer is hub-and-spoke. A central hub holds shared services (a firewall, a gateway, DNS); each workload lives in its own spoke, peered to the hub but not to its siblings. Traffic between workloads is routed and inspected on purpose, never by accident. This lab builds that shape and then demonstrates the isolation — that two spokes genuinely cannot reach each other — without spinning up a single chargeable resource.

You will create a hub and two spokes with non-overlapping address spaces, peer each spoke to the hub, confirm the spokes are not peered to one another, and add an NSG that spells out the allowed and denied paths as explicit rules.

A flat network trusts everything once. Segmentation makes trust a decision.

Address spaces must not overlap or peering will refuse them. Give the hub 10.0.0.0/16 and the spokes their own /16s, each with a workload subnet.

# Windows/Git Bash: stop it mangling /subscriptions/... arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

RG="campux-lab-net-rg"
az group create -n "$RG" -l eastus

# hub
az network vnet create -g "$RG" -n hub-vnet --address-prefix 10.0.0.0/16 \
  --subnet-name shared --subnet-prefix 10.0.1.0/24

# spoke 1
az network vnet create -g "$RG" -n spoke1-vnet --address-prefix 10.1.0.0/16 \
  --subnet-name workload --subnet-prefix 10.1.1.0/24

# spoke 2
az network vnet create -g "$RG" -n spoke2-vnet --address-prefix 10.2.0.0/16 \
  --subnet-name workload --subnet-prefix 10.2.1.0/24

Peering is directional, so each link needs two halves — spoke→hub and hub→spoke. Create all four.

for S in spoke1 spoke2; do
  az network vnet peering create -g "$RG" -n "${S}-to-hub" \
    --vnet-name "${S}-vnet" --remote-vnet hub-vnet --allow-vnet-access
  az network vnet peering create -g "$RG" -n "hub-to-${S}" \
    --vnet-name hub-vnet --remote-vnet "${S}-vnet" --allow-vnet-access
done

az network vnet peering list -g "$RG" --vnet-name hub-vnet \
  --query "[].{name:name, state:peeringState}" -o table

This is the segmentation payoff, and it needs no traffic test — the routing tells the truth. Azure VNet peering is non-transitive: spoke1 peers with the hub and spoke2 peers with the hub, but that does not connect spoke1 to spoke2. List spoke1's peerings and see that the hub is its only neighbour.

az network vnet peering list -g "$RG" --vnet-name spoke1-vnet \
  --query "[].{name:name, remote:remoteVirtualNetwork.id}" -o table

Non-transitive peering already isolates the spokes, but real landing zones state their rules out loud so intent survives future changes. Attach an NSG to spoke1's workload subnet that allows the hub's range and denies spoke2's range explicitly.

az network nsg create -g "$RG" -n spoke1-nsg

az network nsg rule create -g "$RG" --nsg-name spoke1-nsg -n allow-hub \
  --priority 100 --direction Inbound --access Allow --protocol '*' \
  --source-address-prefixes 10.0.0.0/16 --destination-address-prefixes '*' \
  --destination-port-ranges '*'

az network nsg rule create -g "$RG" --nsg-name spoke1-nsg -n deny-spoke2 \
  --priority 200 --direction Inbound --access Deny --protocol '*' \
  --source-address-prefixes 10.2.0.0/16 --destination-address-prefixes '*' \
  --destination-port-ranges '*'

az network vnet subnet update -g "$RG" --vnet-name spoke1-vnet -n workload \
  --network-security-group spoke1-nsg

az network nsg rule list -g "$RG" --nsg-name spoke1-nsg \
  --query "sort_by([].{p:priority,name:name,access:access,src:sourceAddressPrefix}, &p)" -o table

Everything is in one resource group — delete it and confirm.

az group delete -n campux-lab-net-rg --yes
az group exists -n campux-lab-net-rg      # -> false

You built a hub-and-spoke topology, peered spokes to a hub, demonstrated that non-transitive peering keeps the spokes isolated, and expressed that isolation as explicit NSG rules. That is the networking backbone of every Azure landing zone in the job descriptions — "segmentation and least-privilege connectivity between workloads" is this, exactly. The next step in a real design is putting a firewall or a gateway in the hub so spoke-to-spoke traffic can be forced through inspection when it is wanted; the shape you just built is what that inspection plugs into.