Skip to main content

Command Palette

Search for a command to run...

Implementing VNet-to-VNet Peering in Azure: A Complete Guide

Updated
3 min read
Implementing VNet-to-VNet Peering in Azure: A Complete Guide
C

Tech Enthusiast | 19+ Years in IT | Security, Coding, Trends With over 19 years of experience in the ever-evolving world of Information Technology, I’m passionate about staying ahead of the curve. From mastering secure coding practices to exploring the latest trends in AI, cloud computing, and cybersecurity, my mission is to share valuable insights, practical tips, and the latest industry updates. Whether it's about writing cleaner, more efficient code or enhancing security protocols, I aim to empower developers and IT professionals to excel in their careers while keeping pace with the rapidly changing tech landscape.

Azure Virtual Network (VNet) peering enables seamless connectivity between two VNets using private IP addresses, as if they were on the same network. This allows resources like VMs, databases, or services to communicate across VNets without going over the public internet, providing low-latency, high-bandwidth connectivity.

VNet-to-VNet peering is commonly used for:

  • Connecting workloads in different VNets within the same subscription

  • Connecting workloads across different subscriptions

  • Building Hub-Spoke architectures

  • Enabling hybrid connectivity through a centralized VPN/ExpressRoute gateway


🔹 Prerequisites Before Peering

  1. Non-overlapping IP address spaces

    • Each VNet must have a unique CIDR block. Example:

      • Hub VNet → 10.0.0.0/16

      • Spoke VNet → 10.1.0.0/16

  2. Permissions

    • You need Network Contributor or Owner rights on both VNets.

    • Cross-subscription peering requires approval from the other subscription.

  3. DNS Considerations

    • Peered VNets do not resolve private DNS names by default.

    • Options: Use Azure DNS private zones linked to both VNets or configure custom DNS forwarders.

  4. Plan Gateway Transit (if hybrid connectivity needed)

    • Hub VNet with VPN/ExpressRoute → Enable Allow Gateway Transit

    • Spoke VNet → Enable Use Remote Gateway


🔹 Step-by-Step Implementation

Step 1: Create VNets

  • Hub VNet (shared services, gateway, firewall)

  • Spoke VNet (workload-specific)

  • Ensure non-overlapping CIDR ranges

Step 2: Configure Subnets

  • Hub VNet → subnets for VPN/ExpressRoute, firewall, and applications

  • Spoke VNet → workload-specific subnets

Step 3: Create Peering from Hub to Spoke

  1. Go to Hub VNet → Peerings → Add

  2. Configure:

    • Peering link name

    • Remote VNet → select Spoke

    • Enable Allow forwarded traffic if using NVAs

    • Enable Allow gateway transit (if Hub has VPN/ExpressRoute)

Step 4: Create Peering from Spoke to Hub

  1. Go to Spoke VNet → Peerings → Add

  2. Configure:

    • Peering link name

    • Remote VNet → Hub

    • Enable Use remote gateways

    • Allow forwarded traffic if needed

Step 5: Configure NSGs and Route Tables

  • Ensure Network Security Groups (NSGs) allow required traffic between VNets

  • Update User Defined Routes (UDRs) if traffic should flow through firewalls or NVAs

Step 6: Test Connectivity

  • Deploy VMs in both VNets and ping or use Test-NetConnection

  • Ensure workloads can communicate on required ports


🔹 Best Practices

  1. Avoid overlapping IP ranges → Critical for successful peering

  2. Hub-Spoke design → Reduces complexity and prevents “spaghetti networking”

  3. DNS configuration → Use Private DNS zones or custom forwarders

  4. Transitive routing → Peering is non-transitive; use NVAs or Hub for controlled routing

  5. Regional considerations → Intra-region peering is free; cross-region incurs bandwidth cost

  6. Security → Use NSGs, Azure Firewall, or NVAs to restrict traffic as needed

  7. Monitoring & Cost Management → Track cross-region traffic usage


🔹 Common Scenarios

1. Hub-Spoke Architecture

  • Hub VNet → shared firewall, VPN/ExpressRoute gateway

  • Spokes → isolated workloads

  • Benefits: scalable, secure, and centrally managed

2. Cross-Subscription Peering

  • Useful for multi-team or multi-department setups

  • Requires approval from the remote subscription

  • Same principles as standard peering, with attention to permissions

3. Hybrid Connectivity

  • Spokes use Hub’s VPN or ExpressRoute gateway

  • Reduces duplication of expensive network resources


🔹 Diagram Example

       [ Hub VNet ]
     /       |       \
    /        |        \
[Spoke1]  [Spoke2]  [Spoke3]
     \       |       /
      \      |      /
        VPN / ExpressRoute
             |
        On-Premises
  • All spokes connect to the Hub

  • Hub provides shared services, security, and hybrid connectivity

  • Peering ensures low-latency communication


🔹 Final Thoughts

VNet-to-VNet peering is a powerful tool for connecting workloads securely and efficiently in Azure. By following these steps and best practices, you can:

  • Achieve low-latency connectivity

  • Maintain network security and governance

  • Optimize costs and simplify management

  • Avoid common pitfalls like overlapping IPs or misconfigured gateways

Peering, when combined with Hub-Spoke architecture, is the backbone of scalable, enterprise-grade Azure networking.

More from this blog

Code Sky

59 posts

“I write technical blogs on Azure, cloud architecture, and modern software solutions, sharing practical insights and best practices for beginners and professionals alike.”