Configuring Azure Virtual Network (VNet) Peering for Cross‑Region Resource Connectivity

Background: Many public‑cloud users need to interconnect resources within a cloud while keeping them isolated from other tenants, and also want to extend their on‑premises LAN into the cloud. Azure provides Virtual Networks (VNet) as its VPC‑style solution.

Azure offers several ways for users to access cloud resources—public IP exposure, VPN (point‑to‑point or site‑to‑site), and ExpressRoute—as well as three VNet‑to‑VNet connectivity options: VPN gateway, ExpressRoute, and VNet peering.

The article focuses on VNet peering, which keeps traffic within a private network, offers low latency and high bandwidth, and can span subscriptions, deployment models, and (preview) regions. Limitations include lack of cross‑region communication, non‑overlapping address spaces, and the need for reciprocal peer mappings.

Three VNets (vnet01, vnet02, vnet03) are created in the Southeast Asia region with address spaces 10.1.0.0/16, 10.2.0.0/16, and 10.3.0.0/16 respectively. A gateway is added to vnet01, and remote‑gateway settings are configured so that vnet02 and vnet03 can use vnet01’s gateway.

Peering connections are then established: vnet01 ↔ vnet02, vnet01 ↔ vnet03, and vnet02 ↔ vnet03. All peerings show a “Connected” state.

Finally, a Windows Server VM is deployed in each VNet and ping tests confirm successful inter‑VNet connectivity, demonstrating that the peering configuration works as intended.