Peering is essentially a very fancy way of saying that you want to join two VNets together.
By peering two VNets together, you leverage Microsoft’s backbone network (it doesn’t egress onto a public network), and you can still achieve the very low latencies you’d expect on non-peered VNets. You can even peer across regions, so a VNet in UK South could be peered with a VNet in West Europe. It also works across Azure subscriptions and Entra tenants – meaning you can connect with VNets that you don’t actually own or manage directly (think third party connectivity).
You don’t gain or lose any bandwidth by peering, as this is constrained by the limits imposed on the sizing of VMs or other resources that are associated to the VNet.
Whilst you can peer VNets, you might on occasion want to limit the amount of access the peered VNet has into your network, this can be achieved by applying NSG rules to subnets to explicitly allow/deny certain types of access.
The peering process doesn’t result in any downtime, so you can put up and take down peerings as needed.
There are some limitations with this approach, as mentioned, you can’t have overlapping address spaces, as this would cause a conflict in routing requests between the two VNets. You can resize your address space by changing the CIDR of the network range (e.g. downsize from a /16 to a /17) (more info here: https://learn.microsoft.com/en-us/azure/virtual-network/update-virtual-network-peering-address-space ). Resizing or adding ranges doesn’t incur any downtime, obviously deleting ranges that are in use is a destructive change.
VNet peerings are also not transitive.
Wait, what does transitive mean and do I need it?
Imagine you have three VNets, very imaginatively called vnet1, vnet2 and vnet3. vnet1 and vnet3 are peered, and so is vnet2 and vnet3. If VNet peerings were transitive, vnet1 would also be able to communicate with vnet2, by virtue that it has a peering with vnet3. However, VNets do not support this (i.e. they are non-transitive) and if you go back the early principle of what the core VNet offering is – it is isolated by default – you can see why this wouldn’t be the case.
OK I’m ready, (a) single (VNet) ready to mingle (Peer)
Hold on, there’s a couple more things to consider:
- You want to use VNet peering for simple point to point connectivity. If you need a more hub and spoke approach, use gateways or a ‘transit VNet’ instead, otherwise you’ll end up peering a tonne of VNets together for basic connectivity which is an absolute admin nightmare.
- When you create VNet peerings, you will see additional UDRs created
OK, enough talk! Let’s do this!
Alright, well to actually connect (or peer) your VNets, you need to run the command on both VNets. On first command execution, you will see an ‘Initiated’ status, and then on second command completion, ‘Connected’. Let’s create new resource groups and VNets and peer the networks together in the same subscription:
az group create --location "UK South" \
--name "my-rg1"
az network vnet create --name "vnet1" \
--resource-group "my-rg1" \
--address-prefixes "10.10.0.0/16"
az group create --location "UK South" \
--name "my-rg2"
az network vnet create --name "vnet2" \
--resource-group "my-rg2" \
--address-prefixes "10.20.0.0/16"
az network vnet peering create --name "VNet1ToVnet2" \
--vnet-name "vnet1" \
--remote-vnet /subscriptions/<subscriptionId>/resourceGroups/my-rg2/providers/Microsoft.Network/VirtualNetworks/vnet2 \
--resource-group "my-rg1"
Then you must peer in the other direction (vnet2 to vnet1)
az network vnet peering create --name "VNet2ToVnet1" \
--vnet-name "vnet2" \
--remote-vnet /subscriptions/<subscriptionId>/resourceGroups/my-rg1/providers/Microsoft.Network/VirtualNetworks/vnet1 \
--resource-group "my-rg2"
If you make any changes to VNets, such as changes to address spaces, you must sync the VNets again!