Azure Virtual Network (VNET) Peering allows you to connect two or more VNETs privately through the Azure backbone network, enabling low-latency, high-bandwidth communication between resources in different VNETs—without going over the internet.

Regional And Global Peering in Azure

Key Points:

• Traffic flows over Azure’s private backbone, not the public internet.
• Peering can occur across different Azure subscriptions.
• Peering can be: Regional (within the same region) & Global (across different regions)
• Ensure IP address spaces do not overlap between peered VNETs.

Communication between subnets within the same VNET is allowed by default. Azure automatically creates system routes that allow communication between subnets. There’s no need for peering between subnets in the same VNET. All subnets in a single VNET are part of the same IP address space.

NOTE: Use Network Security Groups (NSGs) to block or allow traffic between subnets

However, subnets in different VNETs cannot communicate unless peering is enabled.

Regional Peering Example

Subnet 1 (S 1A) and Subnet 2 (S 2A) within the same VNET (VNET A) can communicate with each other by default. However, they cannot communicate with Subnet 1 (S 1B) or Subnet 2 (S 2B) in a different VNET (VNET B), even if both VNETs are in the same region.

Once peering is enabled, they can communicate over the Azure backbone. This setup is called Regional Peering.

Global Peering Example

• VNET B (US-West)
• VNET C (US-East)

If these are peered, it’s called Global Peering as the VNETs are in different Azure regions. So, now S 1B and S 2B can communicate to S 1C.

Can VNET A communicate with VNET C?

No, VNET A cannot directly communicate with VNET C based on this setup, because:

• VNET A is peered only with VNET B via Regional Peering.
• VNET B is peered with VNET C via Global Peering.
• VNET Peering is not transitive, meaning just because A is peered with B and B is peered with C, A and C cannot communicate unless they have a direct peering relationship.

VPN as an Alternative

You can use a VPN Gateway to enable communication between VNETs or between VNET and on-premises networks.

However:

• Traffic flows through the public internet.
• Higher latency and more complexity.
• Requires a VPN Gateway in each VNET.

Recommendation: Use VNET Peering whenever possible for low latency, security, and cost-efficiency.

Hub-and-Spoke Model (for VPN) To reduce complexity:

• Create Hub VNET.
• Install the VPN Gateway in the Hub.
• Peer spoke VNETs to Hub.
• The Hub can then connect to on-premises.

Example with VPN and HUB -Spoke Architecture

Explanations:

Architecture Explanation

🌐 1. On-Premises Network

• Located outside Azure (your physical or corporate datacenter).
• Has a server: btadc01 with private IP
• Connects to Azure via a Site-to-Site VPN using IPSec IKE tunnel.