Azure Documentation

Virtual Network (VNet) Peering

Azure Virtual Network peering enables you to seamlessly connect two Azure Virtual Networks (VNets) in Azure. Once peered, networks are treated as one for connectivity purposes. Traffic between peered VNets stays within the Azure backbone network and does not traverse the public internet.

Key Concepts and Benefits

  • Inter-VNet Connectivity: Allows resources in different VNets to communicate directly as if they were in the same network.
  • Low Latency and High Bandwidth: Traffic uses the Azure backbone, ensuring efficient data transfer.
  • No Gateway Required: Direct peering eliminates the need for VPN gateways or ExpressRoute circuits for inter-VNet communication within the same region or globally.
  • Namespace Overlap: VNets must have non-overlapping address spaces to be peered.
  • Transitivity: VNet peering is not transitive. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot communicate with VNet C through VNet B. You would need to explicitly peer VNet A with VNet C.

How VNet Peering Works

When you create a VNet peering connection between two VNets, you define:

  • Local VNet Data Gateway: Allows resources in the local VNet to access resources in the peered VNet.
  • Remote VNet Data Gateway: Allows resources in the peered VNet to access resources in the local VNet.
  • Virtual Network Gateway: If you have a VPN gateway or ExpressRoute circuit configured in a VNet, you can choose to allow or disallow transit routing of traffic from on-premises or other VNets through the peering connection.

You can peer VNets within the same region (local VNet peering) or across different regions (global VNet peering).

Tip:

Ensure your VNet address spaces do not overlap before creating a peering connection. Overlapping address spaces will prevent the peering from succeeding.

Creating a VNet Peering Connection

You can create VNet peering connections using the Azure portal, Azure CLI, Azure PowerShell, or ARM templates.

Using the Azure Portal:

  1. Navigate to your first virtual network in the Azure portal.
  2. Under "Settings", select "Peerings".
  3. Click "+ Add".
  4. Fill in the required details:
    • Peering link name: A descriptive name for the peering connection.
    • Virtual network deployment model: Resource Manager or Classic.
    • First virtual network: The VNet you are currently configuring.
    • Second virtual network: The VNet you want to peer with.
    • Peering link name (for the remote VNet): A descriptive name for the peering from the remote VNet's perspective.
    • Allow virtual network access: Enable to allow traffic from the remote VNet to this VNet.
    • Allow gateway transit: Enable if the remote VNet has a gateway and you want to allow traffic from on-premises or other VNets to transit through it.
    • Use remote virtual network's gateway or Route Server: Enable if you want to use the remote VNet's gateway for transit.
    • Allow forwarded traffic: Enable if you want to allow traffic from this VNet to be forwarded to the remote VNet.
  5. Click "Add".
  6. Repeat the process on the second virtual network to establish the peering from its perspective.

Note:

Peering is a mutual connection. You must configure peering on both VNets for the connection to be active.

Azure CLI Example:


# Define variables
RESOURCE_GROUP="myResourceGroup"
VNET1_NAME="vnet1"
VNET2_NAME="vnet2"
PEERING1_NAME="vnet1-to-vnet2"
PEERING2_NAME="vnet2-to-vnet1"

# Peer VNet1 to VNet2
az network vnet peering create \
  --resource-group $RESOURCE_GROUP \
  --vnet-name $VNET1_NAME \
  --name $PEERING1_NAME \
  --remote-vnet $VNET2_NAME \
  --allow-vnet-access

# Peer VNet2 to VNet1
az network vnet peering create \
  --resource-group $RESOURCE_GROUP \
  --vnet-name $VNET2_NAME \
  --name $PEERING2_NAME \
  --remote-vnet $VNET1_NAME \
  --allow-vnet-access

Scenarios for VNet Peering

  • Connecting VNets in different subscriptions.
  • Connecting VNets within different Azure regions.
  • Connecting VNets in different resource groups.
  • Facilitating disaster recovery by replicating workloads across regions.
  • Creating a hub-spoke network topology.

Important Considerations:

  • Cost: While VNet peering itself does not incur charges, data transfer costs still apply based on egress traffic.
  • Security Groups and UDRs: Network Security Groups (NSGs) and User Defined Routes (UDRs) function independently in each VNet. You need to configure them appropriately in both VNets to control traffic flow.
  • DNS Resolution: By default, private DNS zones are not shared across peered VNets. You may need to configure custom DNS servers or use Azure Private DNS Zones with VNet linking.

Troubleshooting VNet Peering

If you encounter issues, check the following:

  • Ensure that the address spaces of the peered VNets do not overlap.
  • Verify that peering is configured in both directions.
  • Check Network Security Groups (NSGs) and firewall rules in both VNets.
  • Confirm that DNS resolution is working correctly if needed.
  • Review routing tables for any unexpected routes.

Azure provides diagnostic tools and connection troubleshooters to help identify issues with VNet peering.