Skip to main content
Configuring peering between two Azure Virtual Networks (VNets) enables private, low-latency, high-bandwidth connectivity between VNets without routing traffic across the public internet. This guide explains the peering options you should consider, shows the PowerShell deployment script used in this example (creates two VNets in different regions, two VMs, and a Private DNS zone with VNet links), and demonstrates how to enable peering in the Azure portal and validate connectivity. Why use VNet peering?
  • Private connectivity between VNets in the same or different regions
  • Low latency and high throughput (backed by Azure’s Microsoft backbone)
  • Simple to configure and low operational overhead compared to VPN or ExpressRoute for VNet-to-VNet traffic
Peering key options
OptionPurposeWhen to enable
Virtual network accessAllows resources in one VNet to reach resources in the peered VNet (VM-to-VM)Most basic peering scenarios
Forwarded trafficPermits traffic routed through a VNet (for example via firewall/NVA) to continue into a peered VNetHub-and-spoke topologies requiring centralized inspection/forwarding
Gateway / Route Server accessAllows a VNet to use the remote VNet’s VPN Gateway or Route ServerWhen multiple VNets share a single gateway to on-premises networks
Bidirectionality (peer both sides)Peering must be configured on both VNets for full two-way accessAlways confirm both sides are configured; unilateral peering can cause one-way failures
Always verify peering settings on both sides (local and remote). Only enable the options required by your topology (for example, forwarded traffic or gateway transit) to minimize attack surface and complexity.
Ensure VNets do not have overlapping IP address spaces — peering will fail (or routes will be invalid) if address spaces overlap. Also remember that peering must be created/configured on both VNets for bidirectional traffic unless using automation to provision both sides.
PowerShell deployment script (example) Below is the PowerShell script used for this demonstration. It creates two VNets in different regions, deploys one VM in each VNet, and creates a Private DNS zone with virtual network links so the VMs register DNS records automatically. 
# --------------------- Variables ---------------------
$resourceGroup        = "rg-az700-peering"
$locationEUS          = "eastus"
$locationWUS          = "westus"
$username             = "kodekloud"
$passwordPlain        = "@adminP@55w0rd"
$securePassword       = (ConvertTo-SecureString $passwordPlain -AsPlainText -Force)
$credential           = New-Object System.Management.Automation.PSCredential($username, $securePassword)

# Naming (eastus)
$vmName1              = "vm-az700-peering-eus-01"
$vnetName1            = "vnet-az700-peering-eus"
$subnetName1          = "subnet-az700-peering-eus"
$ipName1              = "ip-az700-peering-eus"
$nicName1             = "nic-az700-peering-eus"
$nsgName1             = "nsg-az700-peering-eus"

# Naming (westus)
$vmName2              = "vm-az700-peering-wus-01"
$vnetName2            = "vnet-az700-peering-wus"
$subnetName2          = "subnet-az700-peering-wus"
$ipName2              = "ip-az700-peering-wus"
$nicName2             = "nic-az700-peering-wus"
$nsgName2             = "nsg-az700-peering-wus"

# Create NICs (example)
$nic1 = New-AzNetworkInterface -Name $nicName1 -ResourceGroupName $resourceGroup -Location $locationEUS -Subnet $subnetObj1 -PublicIpAddress $pip1 -NetworkSecurityGroup $nsg1
$nic2 = New-AzNetworkInterface -Name $nicName2 -ResourceGroupName $resourceGroup -Location $locationWUS -Subnet $subnetObj2 -PublicIpAddress $pip2 -NetworkSecurityGroup $nsg2

# -------------------- VM Configs --------------------
Write-Host "Building VM configurations" -ForegroundColor Cyan
$vmConfig1 = New-AzVMConfig -VMName $vmName1 -VMSize "Standard_B1s" |
    Set-AzVMOperatingSystem -Linux -ComputerName $vmName1 -Credential $credential |
    Set-AzVMSourceImage -PublisherName $imagePublisher -Offer $imageOffer -Skus $imageSku -Version $imageVersion |
    Add-AzVMNetworkInterface -Id $nic1.Id

$vmConfig2 = New-AzVMConfig -VMName $vmName2 -VMSize "Standard_B1s" |
    Set-AzVMOperatingSystem -Linux -ComputerName $vmName2 -Credential $credential |
    Set-AzVMSourceImage -PublisherName $imagePublisher -Offer $imageOffer -Skus $imageSku -Version $imageVersion |
    Add-AzVMNetworkInterface -Id $nic2.Id

# -------------------- Create VMs --------------------
Write-Host "Creating VMs (this can take several minutes)" -ForegroundColor Cyan
New-AzVM -ResourceGroupName $resourceGroup -Location $locationEUS -VM $vmConfig1 | Out-Null
New-AzVM -ResourceGroupName $resourceGroup -Location $locationWUS -VM $vmConfig2 | Out-Null

# -------------------- Private DNS Zone --------------------
$privateDnsZoneName = "az700peering.com"
$linkNameEUS = "link-eus"
$linkNameWUS = "link-wus"

Write-Host "Creating Private DNS zone $privateDnsZoneName" -ForegroundColor Cyan
$dnsZone = New-AzPrivateDnsZone -Name $privateDnsZoneName -ResourceGroupName $resourceGroup

Write-Host "Linking VNet's to Private DNS zone with auto-registration" -ForegroundColor Cyan
New-AzPrivateDnsVirtualNetworkLink -ZoneName $privateDnsZoneName -ResourceGroupName $resourceGroup -Name $linkNameEUS -VirtualNetworkId $vnet1.Id -EnableRegistration
New-AzPrivateDnsVirtualNetworkLink -ZoneName $privateDnsZoneName -ResourceGroupName $resourceGroup -Name $linkNameWUS -VirtualNetworkId $vnet2.Id -EnableRegistration

# -------------------- Output --------------------
Write-Host "Deployment complete." -ForegroundColor Green
Write-Host "VM 1 Public IP:" ((Get-AzPublicIpAddress -Name $ipName1 -ResourceGroupName $resourceGroup).IpAddress)
Write-Host "VM 2 Public IP:" ((Get-AzPublicIpAddress -Name $ipName2 -ResourceGroupName $resourceGroup).IpAddress)
After the deployment completes, you should see two virtual machines in the Azure portal (deployed to different regions with public IPs):
A screenshot of the Microsoft Azure portal on the Compute infrastructure > Virtual machines page, showing a list of two running Linux virtual machines with their subscriptions, resource groups, locations, VM sizes and public IP addresses. The highlighted VM name is "vm-az700-peering-wus-01."
Pick one VNet to start the peering configuration — you can begin from either VNet. Peering must be created on both sides for full functionality. The Virtual Networks list shows the VNets and their regions:
A screenshot of the Microsoft Azure portal showing the "Network foundation | Virtual networks" page. It lists three virtual networks with their resource groups, locations (West Europe, East US, West US), and subscription.
Check the VNet DNS configuration before peering. In this example the VNet is using the default Azure-provided DNS. If your environment requires it, configure custom DNS servers at the VNet level.
A screenshot of the Microsoft Azure portal showing the "vnet-az700-peering-eus | DNS" settings page, with the DNS servers option set to "Default (Azure-provided)." The left-hand menu shows virtual network options like Subnets, Firewall, DNS, and Monitoring.
Because the VMs were registered in a Private DNS zone, you can confirm the A records exist for each VM:
Screenshot of the Microsoft Azure portal open to a Private DNS zone named "az700peering.com." The Recordsets pane shows an SOA record and two A records (vm-az700-peering-eus-01 and vm-az700-peering-wus-01) with their IP addresses and TTLs.
Validate name resolution and connectivity from one VM to the other before peering is configured (this verifies DNS registration but also demonstrates that network connectivity is blocked until peering is enabled): 
# SSH to the West US VM public IP (example)
ssh kodekloud@20.253.255.34

# On the VM, check name resolution for the East US VM
nslookup vm-az700-peering-eus-01.az700peering.com
# Try to ping the private IP (will fail before peering)
ping vm-az700-peering-eus-01.az700peering.com
# Result: 100% packet loss before peering is configured
You will typically observe successful DNS resolution (Private DNS zone provides the private IP), but network-level connectivity fails until peering is established because the VNets remain isolated. Add peering in the Azure portal
  1. Open the source VNet in the Azure portal.
  2. Select Peerings → Add peering.
  3. Configure the local and remote options:
    • Remote virtual network: select the remote VNet.
    • Allow virtual network access: enable for basic connectivity.
    • Allow forwarded traffic: enable if you need traffic forwarded from an NVA or firewall.
    • Allow gateway transit / Use remote gateways: enable only if you intend to share a VPN Gateway or Route Server.
The portal’s Add peering page exposes these options:
A screenshot of the Microsoft Azure portal open to the "Add peering" page for a virtual network, showing subscription and virtual network fields and remote virtual network peering settings with several checkboxes. The page includes options like allowing access, receiving forwarded traffic, and gateway/route server settings.
Repeat the peering configuration on the remote VNet (or use automation/templates to create the corresponding peering). When both sides are configured successfully, the peering status in the portal will show Connected for both VNets and you’ll receive notifications about the successful creation. Validate connectivity after peering After enabling peering on both sides, test name resolution and network connectivity (ping/SSH) from one VM to the other over the private IP addresses. Example successful ping after peering: 
# From East US VM to West US VM private DNS name
ping vm-az700-peering-wus-01.az700peering.com

# Sample responding output:
64 bytes from 10.40.1.4: icmp_seq=91 ttl=64 time=73.0 ms
64 bytes from 10.40.1.4: icmp_seq=92 ttl=64 time=72.6 ms
...
# Ping statistics:
113 packets transmitted, 33 received, 70.7965% packet loss, time 113949ms
rtt min/avg/max/mdev = 71.888/72.476/73.552/0.347 ms
SSH directly over private IP or private DNS name: 
# SSH from East US VM to West US VM using reachable private IP (example)
ssh kodekloud@10.40.1.4

# On successful connect, you will see the remote VM prompt:
kodekloud@vm-az700-peering-wus-01:~$
If connectivity still fails after peering:
  • Re-check that both peerings are Connected in the portal.
  • Ensure NSG rules on subnets/VMs allow ICMP/SSH traffic.
  • Confirm there are no overlapping IP address spaces between VNets.
  • Verify forwarded traffic/gateway transit settings if traffic is being routed via an NVA or shared gateway.
Summary & checklist
  • Configure required peering options according to your topology: virtual network access, forwarded traffic, gateway access.
  • Always create/configure peering on both VNets for bidirectional traffic unless automated.
  • Use Private DNS zones with virtual network links to provide name resolution for VMs across peered VNets.
  • Test DNS (nslookup) and network connectivity (ping, SSH) after peering to validate setup.
  • Verify NSG rules, address space uniqueness, and any gateway or NVA forwarding requirements.
Links and references

Watch Video