5.1.3.1. Configure VNet Peering

💡 First Principle: VNet peering provides seamless, low-latency, and private connectivity between Azure Virtual Networks, allowing them to communicate as if they were a single network, all over the Microsoft backbone.

Scenario: You have a Virtual Network for your web servers and another Virtual Network for your database servers. These two VNets need to communicate frequently and securely, but you don't want traffic to go over the public internet, and you want to avoid deploying VPN Gateways between them.

What It Is: VNet peering is a networking mechanism that connects two or more Azure Virtual Networks.

Key Benefits:

• Direct Connectivity: Resources in peered VNets can communicate directly, using private IP addresses.
• Low Latency & High Bandwidth: Traffic between VNets stays on the Microsoft backbone.
• No Gateway Required: VNet peering removes the need for VPN gateways for inter-VNet communication.

High-Level Configuration Steps (Azure Portal):

1. In the Azure portal, select the first VNet and add a peering connection to the target VNet.
2. Repeat the process from the second VNet to create a reciprocal peering.
3. Configure peering settings, such as allowing traffic flow and enabling gateway transit.

Key Considerations:

• Non-Transitive: If VNet A is peered with B, and B with C, A cannot communicate with C unless a direct peering exists.
• No Overlapping IP Spaces: Peered VNets cannot have overlapping address spaces.

Visual: VNet Peering

Loading diagram...

⚠️ Common Pitfall: Assuming VNet peering is transitive. For a hub-and-spoke model where spokes need to communicate with each other, you must either peer the spokes directly or use a Network Virtual Appliance (NVA) or Azure Firewall in the hub to route traffic.

Key Trade-Offs:

• Simplicity (Peering) vs. Scalability (Hub-and-Spoke): Peering is simple for a few VNets. A hub-and-spoke model is more scalable for many VNets but adds complexity.

Reflection Question: How does configuring VNet peering fundamentally enable scalable, secure, and interconnected Azure network architectures by allowing resources in different VNets to communicate as if they were on the same network, using private IP addresses and without gateways?