VNet Peering and Service Endpoints
Connect two VNets using VNet peering for low-latency private communication, and use service endpoints to route traffic to Azure services without the public internet.
The Need for VNet Peering
Resources in different Azure VNets cannot communicate with each other by default — even if they are in the same Azure region. However, large organisations often have multiple VNets: separate VNets for development, staging, and production, or different VNets for different departments. VNet Peering connects two VNets directly through Microsoft's private backbone network, enabling resources in both VNets to communicate as if they were in the same network — without any traffic traversing the public internet or requiring a VPN gateway.
How VNet Peering Works
VNet Peering is a non-transitive connection: if VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C unless you create a separate peering between A and C. Peering links are bidirectional but must be configured on both sides — creating a peering from A to B does not automatically create one from B to A. Once both sides are configured, traffic between the peered VNets uses the Azure backbone with low latency and high bandwidth, comparable to inter-subnet communication within a single VNet.
# Create peering from VNet-A to VNet-B
az network vnet peering create \
--resource-group myRG \
--name A-to-B \
--vnet-name VNet-A \
--remote-vnet VNet-B \
--allow-vnet-access
# Create return peering from VNet-B to VNet-A
az network vnet peering create \
--resource-group myRG \
--name B-to-A \
--vnet-name VNet-B \
--remote-vnet VNet-A \
--allow-vnet-accessAll lessons in this course
- Virtual Networks and Subnets
- Network Security Groups and Application Security Groups
- VNet Peering and Service Endpoints
- Azure DNS and Load Balancer Essentials