Virtual Network Peering

Module: Design and Implement Core Networking

Lesson: Virtual Network Peering

Introduction to Virtual Network Peering

In the realm of cloud architecture, the ability for isolated networks to communicate is the backbone of any distributed system. When you deploy resources in the cloud, they typically reside within a Virtual Network (VNet). By default, resources within a single VNet can communicate with each other, but resources in different VNets are completely isolated. This isolation is a critical security feature, but it often conflicts with the practical need for multi-tier applications, shared services, or cross-departmental data sharing. Virtual Network Peering is the solution to this problem.

Virtual Network Peering allows you to connect two or more Virtual Networks in the same cloud region or across different regions. Once peered, the VNets appear as a single network for connectivity purposes. Traffic between virtual machines in peered virtual networks uses the underlying cloud provider's private backbone network. This is not just a routing convenience; it is a high-performance, low-latency, and secure connection method that keeps your traffic off the public internet entirely.

Understanding peering is essential for any cloud engineer because it dictates how you structure your environment. Whether you are building a "Hub and Spoke" topology—a standard industry pattern for centralizing network management—or simply connecting two development environments, mastering peering is non-negotiable. This lesson will guide you through the technical mechanics, configuration steps, and operational best practices for implementing and maintaining Virtual Network Peering.

The Architecture of Peering: How It Works

At its core, peering creates a logical link between two networks. When you configure peering, you are essentially telling the cloud provider's routing table to recognize the IP address space of the remote network as a valid destination. This happens at the software-defined networking (SDN) layer, meaning there are no physical cables to run or hardware switches to configure.

Types of Peering

While the specific terminology may vary slightly between providers, the fundamental concepts remain consistent across major platforms like Azure, AWS (VPC Peering), and GCP (VPC Network Peering).

1. Regional Peering: This occurs when two VNets are located in the same geographic region. It is the most common form of peering and is typically the most performant, as it minimizes physical distance and routing hops.
2. Global Peering: This allows you to connect VNets across different geographic regions. For example, you might have a VNet in North America and another in Europe. Global peering allows resources in these regions to talk to each other over the provider’s private global backbone.

Callout: Peering vs. VPN Gateways Many beginners confuse VNet Peering with VPN Gateways. A VPN Gateway is used to connect a VNet to an on-premises network or another VNet via an encrypted tunnel over the public internet. Peering, however, uses the cloud provider's private network infrastructure. Peering offers higher throughput and lower latency than VPNs, making it the preferred choice for VNet-to-VNet communication whenever possible.

Key Technical Considerations

Before you start clicking buttons or writing scripts, you must understand the underlying constraints and requirements of the peering process. If these are ignored, you will frequently run into connectivity issues that are difficult to troubleshoot.

Non-Overlapping IP Address Spaces

This is the most critical rule in networking: The address spaces of the peered VNets must not overlap. If VNet A uses the 10.0.0.0/16 range, and VNet B also uses 10.0.0.0/16, the router will not know which network to send the traffic to. You must plan your IP address schema carefully before creating any networks. If you find yourself with overlapping spaces, you will either need to re-IP one of the networks (a painful process) or implement complex NAT (Network Address Translation) solutions.

Bidirectional Configuration

Peering is not an "automatic" two-way street. In most cloud platforms, you must configure the peering link on both sides. If you create a link from VNet A to VNet B, you must also create a corresponding link from VNet B to VNet A. If you fail to do this, traffic may flow in one direction but be dropped on the return trip, leading to the classic "I can ping it but it doesn't respond" troubleshooting scenario.

Transitive Routing

By default, peering is non-transitive. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A cannot automatically communicate with VNet C through VNet B. To enable this, you would need to configure specialized routing, such as a Network Virtual Appliance (NVA) or a transit gateway, to handle the traffic between the networks.

Step-by-Step Implementation

Let’s look at how to implement peering using a practical example. We will assume a scenario where you have a "Hub" VNet (for central services) and a "Spoke" VNet (for an application workload).

Step 1: Planning the IP Spaces

• Hub VNet: 10.1.0.0/16
• Spoke VNet: 10.2.0.0/16
• Observation: These ranges do not overlap, making them perfect candidates for peering.

Step 2: Configuring the Hub Side

You will navigate to the Virtual Network settings in your cloud portal and select "Peerings."

1. Click "Add."
2. Provide a name (e.g., HubToSpoke).
3. Select the subscription and the target VNet (Spoke).
4. Ensure the settings for "Allow forwarded traffic" and "Allow gateway transit" are set to your specific requirements.

Step 3: Configuring the Spoke Side

You must repeat the process on the Spoke VNet:

1. Click "Add" under the Spoke's peering settings.
2. Provide a name (e.g., SpokeToHub).
3. Select the target VNet (Hub).
4. Save the configuration.

Warning: The "Gateway Transit" Trap If you are using a VPN or ExpressRoute connection in your Hub VNet, you can allow your Spoke VNets to use that connection to reach on-premises networks. This is called "Gateway Transit." However, you must enable "Allow gateway transit" on the Hub side and "Use remote gateways" on the Spoke side. If these are mismatched, the peering will show as "Connected," but your Spoke resources will fail to reach the on-premises network.

Code-Based Implementation (Infrastructure as Code)

In a professional environment, you should never configure networking manually through a portal. Using Infrastructure as Code (IaC) tools like Terraform ensures your network topology is version-controlled, repeatable, and documented.

Below is an example of how to define a peering link using HCL (HashiCorp Configuration Language) for Terraform:

# Define the peering from Hub to Spoke
resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  name                      = "hub-to-spoke-peering"
  resource_group_name       = "hub-rg"
  virtual_network_name      = "hub-vnet"
  remote_virtual_network_id = azurerm_virtual_network.spoke.id

  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
  allow_gateway_transit        = false
}

# Define the peering from Spoke to Hub
resource "azurerm_virtual_network_peering" "spoke_to_hub" {
  name                      = "spoke-to-hub-peering"
  resource_group_name       = "spoke-rg"
  virtual_network_name      = "spoke-vnet"
  remote_virtual_network_id = azurerm_virtual_network.hub.id

  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
  use_remote_gateways          = false
}

Explanation of the code:

• allow_virtual_network_access: This allows resources in one VNet to communicate with the other. It is almost always set to true.
• allow_forwarded_traffic: This is crucial if you have an NVA or a firewall in your network that acts as a router. If you don't enable this, the VNet will drop any traffic that doesn't originate from its own address space.
• remote_virtual_network_id: This is the unique resource identifier (ARM ID) of the target network, which ensures the peering is directed at the correct object.

Best Practices and Industry Standards

Implementing peering is easy, but implementing it sustainably requires discipline. Follow these guidelines to avoid "spaghetti networking," where you lose track of which network connects to which.

1. Adopt the Hub and Spoke Model

Do not create a mesh of peerings where every VNet is connected to every other VNet. This becomes unmanageable as your organization grows. Instead, designate a central Hub VNet for shared services (firewalls, jump hosts, logging servers) and connect all other "Spoke" VNets to the Hub. This centralizes control and simplifies security policy enforcement.

2. Centralize Security via NVA

If you need to inspect traffic between VNets, do not rely on simple peering. Route your traffic through a Network Virtual Appliance (NVA) located in the Hub. By using User-Defined Routes (UDRs), you can force traffic from Spoke A to Spoke B to flow through the Hub's firewall first.

3. Use Consistent Naming Conventions

Peering links should be named in a way that makes their directionality obvious. Using a convention like {SourceVNet}-to-{TargetVNet} is highly recommended. This prevents confusion when you are looking at a list of dozens of peering links and trying to determine which one is which.

4. Monitor Peering Health

Cloud providers offer metrics on peering performance and health. Set up alerts for when a peering link status changes from "Connected" to "Disconnected." A disconnected link often indicates that one side of the peering has been deleted or modified without the other side being updated.

Callout: Troubleshooting Connectivity When troubleshooting, always follow the traffic flow:

1. Check the Peering Status: Is it "Connected" on both sides?
2. Check the NSG (Network Security Group): Are there rules blocking the traffic? Even if the peering is active, an NSG rule might explicitly block the traffic.
3. Check the Routing Table: Is there a custom UDR that is overriding the system route and sending traffic to a non-existent gateway?
4. Check the Application/OS: Is the firewall inside the guest OS (e.g., Windows Firewall or iptables) blocking the connection?

Common Pitfalls and How to Avoid Them

Even experienced engineers make mistakes with peering. Here are the most frequent issues encountered in production environments.

• The "Orphaned" Peering: This happens when you delete one VNet but forget to delete the peering link on the other side. While the cloud provider will eventually clean this up, it can cause confusion in IaC deployments where the code expects the link to exist but the target resource is gone. Always remove peering links before deleting the VNet itself.
• Assuming Transitivity: As mentioned earlier, assuming that VNet A can reach VNet C because both are connected to VNet B is the most common cause of "why doesn't this work" tickets. Always remember that you need to explicitly route traffic through a transit hub if you need multi-hop communication.
• Ignoring MTU Limits: In some specific cases involving large packet sizes or nested tunnels, the Maximum Transmission Unit (MTU) of the peering connection might cause packet fragmentation. While rare, if you are seeing high packet loss or slow performance, investigate if your MTU settings are aligned across your network path.
• Over-reliance on Global Peering: Global peering is convenient, but it can introduce significant latency for time-sensitive applications. If your application relies on synchronous database calls between regions, the latency of the physical distance might be the bottleneck, not the peering itself.

Comparison Table: Peering Configurations

Frequently Asked Questions (FAQ)

Q: Can I change the address space of a VNet after it has been peered? A: Generally, no. Most cloud providers will prevent you from modifying the address space of a VNet if it is currently involved in a peering relationship. You must delete the peering link, update the address space, and then recreate the peering.

Q: Does peering incur additional costs? A: Yes. You are charged for the data transfer between the peered networks. The rates are usually lower for regional peering and higher for global peering. Always review your cloud provider's pricing documentation for the specific regions you are operating in.

Q: How many peering links can I have on a single VNet? A: There is usually a limit on the number of peering links per VNet (often around 500 in major providers like Azure). However, you should rarely hit this limit if you are using a well-structured Hub and Spoke topology. If you find yourself hitting this limit, it is a sign that your architecture needs to be re-evaluated.

Q: Can I peer a VNet to a resource in another subscription? A: Yes, most cloud providers allow peering across different subscriptions, provided they are within the same tenant or have the necessary cross-tenant permissions. This is common in enterprise environments where different departments own their own subscriptions but share a common networking Hub.

Comprehensive Key Takeaways

To conclude, Virtual Network Peering is a foundational skill for any cloud professional. It is the most efficient way to connect isolated network environments, providing a secure and high-performance path for data exchange. As you move forward in your career, keep these final points in mind:

1. Plan Your IP Ranges: Address space planning is the most important step. If you start with overlapping IP ranges, you will face significant technical debt later on. Always use a CIDR calculator and document your network schema.
2. Use Hub and Spoke: Avoid complex "spaghetti" meshes. A Hub and Spoke architecture is the industry standard for a reason—it simplifies management, security, and troubleshooting.
3. Automate Everything: Use IaC (Terraform, Bicep, Pulumi) to manage your peering. Manual configuration in the portal is prone to human error and makes it impossible to track changes over time.
4. Understand Routing: Remember that peering is just a logical route. If you need to inspect or filter traffic, you must combine peering with User-Defined Routes (UDRs) and Network Virtual Appliances (NVAs).
5. Test for Connectivity: Never assume a connection is working just because the portal says "Connected." Always perform end-to-end testing using tools like ping, telnet, nc (netcat), or cloud-native connectivity checkers.
6. Monitor Costs: Data transfer costs can add up in large-scale environments. Keep an eye on your egress costs, especially when using global peering across different continents.
7. Maintain Hygiene: Always clean up peering links when you decommission a VNet. Leaving orphaned links behind is a common source of confusion and can cause deployment failures in your IaC pipelines.

By mastering these concepts, you will be able to design complex, multi-layered network architectures that are reliable, secure, and easy to scale. Networking is not just about connecting two points—it is about creating an environment where your applications can communicate reliably while maintaining the strict isolation required for security and compliance.