Azure VNet Peering

Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. It enables Azure resources, like virtual machines (VMs), to securely communicate with each other, the internet, and on-premises networks. However, by default, VNets are isolated from each other. This isolation is a security feature – it prevents unintended traffic between different workloads. But what if you need resources in separate VNets to talk to each other? For example, you might have a web application VNet and a database VNet, and you want the web servers to access the database servers directly, without going over the public internet. Or you might have multiple VNets in different regions that need to exchange data. This is where VNet Peering comes in.

VNet Peering is a networking feature that connects two Azure virtual networks, allowing resources in each VNet to communicate directly with resources in the other VNet. The traffic between peered VNets is routed through Microsoft's backbone network, not the public internet. This means the connection is private, secure, and offers low latency and high bandwidth. VNet Peering is a regional or global service: you can peer VNets within the same Azure region (regional peering) or across different Azure regions (global peering).

- The name of the peering (e.g., "web-to-db"). - The subscription and VNet of the remote VNet. - Whether to allow virtual network access (yes, for communication). - Whether to allow forwarded traffic (if you want the peered VNet to route traffic through a network virtual appliance in the other VNet). - Whether to allow gateway transit (if you want to use a VPN gateway in one VNet to connect to on-premises from the other VNet). 3. Validation: Azure validates that the VNets exist, that there are no overlapping IP address spaces (they must not overlap, or peering will fail), and that you have the necessary permissions (at least Network Contributor role on both VNets). 4. Route Update: After both peering connections are established, Azure updates the routing tables in both VNets. Each VNet learns the address space of the peered VNet, and traffic destined for that address space is sent directly via the Microsoft backbone. 5. Traffic Flow: When a VM in VNet A sends a packet to a VM in VNet B, the packet is routed within VNet A to the Microsoft edge, then over the backbone to the region of VNet B, and then into VNet B. The entire path is managed by Azure; you don't need to configure any additional routing unless you have custom routes.

VNet Peering itself does not incur a setup fee. You pay for the data transfer between peered VNets. For regional peering, ingress/egress rates are lower; for global peering, egress rates are higher (similar to standard data transfer pricing). There is no per-peering charge, only data transfer costs.

In a traditional on-premises data center, connecting two separate networks (e.g., two different subnets or VLANs) typically requires a router or a Layer 3 switch with appropriate routing protocols (like OSPF or BGP). The configuration is complex and requires manual IP address management. Azure VNet Peering abstracts all of this: Azure handles the routing automatically, as long as IP address spaces don't overlap. It's like having a virtual router that instantly connects the two networks without any hardware or complex configuration.

You can create VNet Peering via the Azure portal, Azure CLI, PowerShell, or ARM templates.

Azure Portal: 1. Navigate to your VNet (e.g., VNet-A). 2. Under Settings, click "Peerings". 3. Click "+ Add" to create a new peering. 4. Fill in the details: peering name, subscription, remote VNet, and access settings. 5. Repeat on the remote VNet to create the reverse peering.

Azure CLI:

# Create peering from VNet-A to VNet-B
ez network vnet peering create \
    --name peering-A-to-B \
    --resource-group RG-A \
    --vnet-name VNet-A \
    --remote-vnet /subscriptions/{sub-id}/resourceGroups/RG-B/providers/Microsoft.Network/virtualNetworks/VNet-B \
    --allow-vnet-access

# Create peering from VNet-B to VNet-A
ez network vnet peering create \
    --name peering-B-to-A \
    --resource-group RG-B \
    --vnet-name VNet-B \
    --remote-vnet /subscriptions/{sub-id}/resourceGroups/RG-A/providers/Microsoft.Network/virtualNetworks/VNet-A \
    --allow-vnet-access

PowerShell:

# Create peering from VNet-A to VNet-B
$vnetA = Get-AzVirtualNetwork -ResourceGroupName RG-A -Name VNet-A
$vnetB = Get-AzVirtualNetwork -ResourceGroupName RG-B -Name VNet-B
Add-AzVirtualNetworkPeering -Name peering-A-to-B -VirtualNetwork $vnetA -RemoteVirtualNetworkId $vnetB.Id
Add-AzVirtualNetworkPeering -Name peering-B-to-A -VirtualNetwork $vnetB -RemoteVirtualNetworkId $vnetA.Id

A global e-commerce company runs its primary application in the East US region and wants a disaster recovery (DR) site in West US. They have two VNets: 'app-east' (10.1.0.0/16) and 'app-west' (10.2.0.0/16). They use global VNet Peering to connect these VNets. During normal operations, traffic is minimal (just database replication). If East US goes down, they fail over to West US, and the peering ensures that any remaining resources in East US can still communicate with West US. The team configures the peering with 'Allow forwarded traffic' disabled and 'Allow gateway transit' disabled. They monitor data transfer costs, which are higher for global peering. A common mistake is forgetting to create the reverse peering, which would break bidirectional communication. In this scenario, the company saves costs compared to using a VPN Gateway because peering is faster and does not require a separate gateway instance.

A large enterprise has multiple application teams, each deploying their own VNets. To centralize security and management, the networking team creates a hub VNet containing a firewall (Azure Firewall) and a DNS server. Each application VNet (spoke) is peered to the hub. The spokes do not need to communicate with each other directly; all traffic goes through the hub firewall for inspection. The team configures 'Allow forwarded traffic' on the hub peering and 'Use remote gateways' on the spoke peerings. This allows the spokes to use the VPN gateway in the hub to connect to on-premises. The challenge is ensuring that IP address spaces do not overlap across all VNets. If a new spoke uses an overlapping range, peering fails. Also, because peering is not transitive, the spokes cannot talk to each other without routing through the hub. This topology scales well but requires careful planning of address spaces.

A SaaS provider hosts customer environments in separate VNets for isolation. Customer A's VNet needs to access a shared database VNet. The provider peers Customer A's VNet with the database VNet. When Customer B needs similar access, they peer Customer B's VNet with the same database VNet. The database VNet becomes a hub. The provider must ensure that Customer A cannot access Customer B's VNet. Because peering is not transitive, this is automatically enforced – unless the provider explicitly creates a peering between A and B. However, if the database VNet has a route that forwards traffic between A and B (e.g., via a network virtual appliance), that could break isolation. So the provider disables 'Allow forwarded traffic' on both peerings. This scenario highlights the importance of understanding transitive behavior and the 'Allow forwarded traffic' setting.