Skip to main content
Virtual Network (VNet) peering in Microsoft Azure enables two separate VNets to communicate directly and privately as if they were part of the same network. Peering uses Microsoft’s global backbone network, eliminating the need for VPN gateways or routing traffic over the public internet. This results in low-latency, high-throughput connectivity suitable for cross-region and cross-subscription architectures.

​
Types of VNet peering

A slide titled "Virtual Network Peering" showing four panels that list features: types of peering (global/regional), high-speed data transfer and easy configuration, use of Microsoft's backbone for privacy and low latency, and connectivity across Azure virtual networks. Each panel is paired with a colorful circular icon.

​
Key benefits and capabilities

​
What this demo covers

In this lesson we demonstrate VNet peering by:
  • Deploying two Linux VMs into separate VNets (one in East US, one in West US).
  • Creating peering between those VNets.
  • Verifying name resolution and connectivity (before and after peering).

​
Repository and deployment script

  • Open the repository folder: Administer Intersite Connectivity.
  • This folder contains peering-pref-infra.ps1, a PowerShell script that deploys:
    • Two virtual networks with non-overlapping address spaces.
    • Two Linux VMs (one in East US, one in West US) for testing.

​
Preparing and inspecting resources (DNS lookups)

The test environment includes DNS lookups from a workload VM to demonstrate name resolution across VNets and to external DNS records. Example nslookup outputs:

​
Deploying the test environment

  1. Confirm your current Azure context:
  1. Run the deployment script:
What the script does:
  • Creates two VNets with non-overlapping address ranges (this is required — do not overlap).
  • Deploys one Linux VM in the East US VNet and one Linux VM in the West US VNet.
  • Assigns private IPs for the demo (examples: 192.168.0.4 and 192.168.1.4).

​
Initial connectivity test (before peering)

SSH into the East US VM and confirm its IP configuration:
Attempt to ping the West US VM’s private IP (before peering):
This failure is expected: without VNet peering, VNets (especially across regions) do not route directly.
Make sure VNets you plan to peer do not have overlapping IP address ranges. Overlapping address spaces prevent successful peering and cause routing conflicts.

​
Configuring VNet peering in the Azure portal

To add peering from the portal:
  1. Open one of the virtual networks (either East US or West US) in the Azure portal.
  2. Select “Peerings” → “Add”.
  3. Provide a name for the local peering (for example, WUS-EUS-Link).
  4. Configure peering options:
    • Allow virtual network access (enable to allow VM-to-VM traffic).
    • Allow forwarded traffic (enable if you expect to route forwarded traffic).
    • Allow gateway transit / Use remote gateways — enable only if you intend to route on-premises traffic through a remote gateway.
  5. Select the remote virtual network and create the peering. Repeat on the remote VNet if required — Azure will show peering status changes as the connection is established.
If you need to route on-premises traffic through peered VNets, enable gateway transit on the VNet with the gateway and enable “Use remote gateways” on the VNet that needs to use it. This requires a gateway in one VNet and proper permissions.
After creating peering, the portal will show the status change from “Initiated” to “Connected” on both VNets.
A screenshot of the Microsoft Azure portal showing the "vnet-wus | Peerings" page with a peering entry named "eus-wus-link" marked as "Initiated" and peer "vnet-eus." Notification toasts at the top right confirm virtual network peering was added.

​
Testing connectivity after peering

Once peering is connected, retry the ping from the East US VM to the West US VM:
You can also SSH using the peered private IP:

​
Network Security Group (NSG) considerations

  • Default NSG rules include AllowVNetInbound which permits traffic from within the same VNet and from peered VNets. For many scenarios, no additional NSG changes are required.
  • To restrict peered traffic, add explicit NSG rules with higher priority to allow or deny traffic from specific IP ranges (include the peered VNet’s address ranges).

​
Best practices and summary

  • Always plan and verify non-overlapping IP address spaces before peering.
  • Use peering for high-performance, private connectivity across VNets and regions.
  • Configure gateway transit only when necessary and ensure only the VNet with the gateway exposes transit to others.
  • Both sides of the peering must reflect the connection; validate the peering status in the Azure portal or via CLI/PowerShell.
  • Review NSG rules if you need to tighten or allow specific traffic flows across the peering.

Watch Video

Practice Lab