Virtual Network Peering Connectivity and Security

Establish and Configure Virtual Network Peering

Virtual network peering in Azure connects two separate virtual networks, allowing resources in each network to communicate as if they were on the same network. This connection is made directly through the Azure portal. The process starts by navigating to Virtual networks, selecting a network, and then adding a new peering under its settings. A critical requirement is that the address spaces of the two networks must not overlap, or the peering will fail.

When configuring the peering, you must decide whether to enable traffic forwarding between the networks and whether to allow gateway transit, which lets one network use a VPN gateway in the peered network. You also need to consider DNS settings to ensure resources can find each other by name. After creation, you verify the connection by testing communication between virtual machines and monitoring the traffic flow to confirm there are no performance issues.

Configure Peering Security and Access Controls

Peering creates a high-speed, private link where traffic stays on Microsoft's network and never touches the public internet. To control what traffic can flow, you configure specific peering properties. The Allow virtual network access setting must be enabled for any direct communication. The Allow forwarded traffic setting permits traffic that did not originate within the peered network itself to pass through, which is necessary for certain routing scenarios.

Security is enforced using Network Security Groups (NSGs), which are applied to subnets to create inbound and outbound rules that filter traffic crossing the peering link. Permissions to create or manage peerings are controlled by Azure role-based access control (RBAC), typically requiring the Network Contributor role. A key security principle is that peering is not transitive; connecting Network A to B and B to C does not automatically connect A to C, which helps maintain isolation.

Advanced controls include gateway transit, which allows a "spoke" virtual network to use a VPN or ExpressRoute gateway in a central "hub" network for connectivity to on-premises locations. User-Defined Routes (UDRs) can be used for service chaining, directing traffic through a security appliance like a Network Virtual Appliance (NVA) in the hub. A newer feature, Subnet Peering, allows linking only specific subnets between networks instead of the entire address space, providing more granular control.

Evaluate Peering Connectivity and Traffic Flow

Azure offers two types of peering: Regional VNet Peering for networks in the same Azure region and Global VNet Peering for networks in different regions. Both types keep traffic on the private Microsoft backbone, offering low latency and high bandwidth. The bandwidth available between peered resources is ultimately limited by the size of the Virtual Machines involved.

A core routing concept is that VNet Peering is non-transitive. This means you cannot route traffic through an intermediate peered network to reach a third network. To connect multiple networks, you must peer each pair directly or implement a hub-and-spoke design where all "spokes" peer only with a central "hub" network. Gateway Transit is a key property in this topology, allowing the hub's gateway to provide on-premises connectivity for all the spokes.

There are important constraints to evaluate. With Global VNet Peering, resources cannot communicate with the front-end IP of a Basic Load Balancer in the remote network. While you can resize a peered network's address space, you must synchronize the peering connection afterward for the change to take effect. Also, name resolution across peered networks requires either Azure Private DNS or a custom DNS server. Finally, data transferred over a peering link incurs nominal ingress and egress charges, so traffic should be monitored for cost management.