Skip to main content
Multi-CloudNetworkingintermediate

VPC/VNet/VCN Peering Across Clouds

Compare VPC Peering across AWS, Azure, GCP: peering models, transit routing, cross-cloud VPN, and IP planning.

CloudToolStack Team24 min readPublished Mar 14, 2026

Prerequisites

  • Understanding of IP addressing and subnetting (CIDR notation)
  • Familiarity with at least one cloud provider's networking

Network Peering Across Cloud Providers

Network peering connects two virtual networks so that resources in each can communicate using private IP addresses without traversing the public internet. Every major cloud provider offers intra-cloud peering (connecting networks within the same cloud), but connecting networks across different clouds requires VPN tunnels or dedicated interconnects. Understanding the peering models, limitations, and transit routing options is essential for designing multi-cloud and hybrid architectures.

This guide compares VPC Peering (AWS), VNet Peering (Azure), and VPC Network Peering (GCP), covers transit routing patterns, examines cross-cloud connectivity options, and provides Terraform configurations for common peering topologies.

Key Terminology

Peering: Direct connection between two virtual networks. Transit: Routing traffic through an intermediary (Transit Gateway, Azure Virtual WAN, GCP NCC). Interconnect: Dedicated physical connection between cloud provider and on-premises or between clouds. VPN: Encrypted tunnel over the public internet.

AWS VPC Peering

AWS VPC Peering creates a networking connection between two VPCs using private IPs. Peered VPCs can be in the same account, different accounts, or different regions (inter-region peering). Data transferred over intra-region peering is free; inter-region peering incurs standard inter-region data transfer charges.

AWS Peering Limitations

LimitationImpactWorkaround
Non-transitiveVPC A peered to B, B to C: A cannot reach CUse Transit Gateway
No overlapping CIDRsPeered VPCs must have non-overlapping IP rangesPlan CIDR allocation carefully
No edge-to-edge routingCannot route through a peered VPC's VPN or Direct ConnectUse Transit Gateway
125 peerings per VPCHard limit (not adjustable)Use Transit Gateway for many-to-many
bash
# Create VPC peering between two VPCs
PEERING_ID=$(aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-aaa111 \
  --peer-vpc-id vpc-bbb222 \
  --peer-owner-id 111222333444 \
  --peer-region us-west-2 \
  --query 'VpcPeeringConnection.VpcPeeringConnectionId' \
  --output text)

# Accept the peering (from the peer account/VPC owner)
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id "$PEERING_ID" \
  --region us-west-2

# Add routes to each VPC's route table
aws ec2 create-route \
  --route-table-id rtb-aaa111 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id "$PEERING_ID"

aws ec2 create-route \
  --route-table-id rtb-bbb222 \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id "$PEERING_ID" \
  --region us-west-2

Azure VNet Peering

Azure VNet Peering connects two VNets in the same region or across regions (global VNet peering). Unlike AWS, Azure peering can be transitive when used with Azure Virtual WAN or a hub VNet with routing. VNet peering within the same region is free for ingress and egress; global peering charges data transfer.

bash
# Create bidirectional VNet peering
az network vnet peering create \
  --name hub-to-spoke1 \
  --resource-group network-rg \
  --vnet-name hub-vnet \
  --remote-vnet spoke1-vnet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --allow-gateway-transit

az network vnet peering create \
  --name spoke1-to-hub \
  --resource-group network-rg \
  --vnet-name spoke1-vnet \
  --remote-vnet hub-vnet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --use-remote-gateways

# Check peering status
az network vnet peering list \
  --resource-group network-rg \
  --vnet-name hub-vnet \
  --query '[].{Name:name, State:peeringState, AllowForwarded:allowForwardedTraffic}' \
  --output table

GCP VPC Network Peering

GCP VPC Network Peering is unique because GCP VPCs are global (they span all regions). Peering two GCP VPCs gives each access to all subnets in the other VPC across all regions. GCP peering also supports exporting and importing custom routes, making it more flexible than AWS peering for some scenarios.

bash
# Create bidirectional VPC peering
gcloud compute networks peerings create hub-to-app \
  --network=hub-vpc \
  --peer-network=app-vpc \
  --peer-project=app-project-id \
  --export-custom-routes \
  --import-custom-routes

gcloud compute networks peerings create app-to-hub \
  --network=app-vpc \
  --peer-network=hub-vpc \
  --peer-project=hub-project-id \
  --export-custom-routes \
  --import-custom-routes \
  --project=app-project-id

# Check peering status
gcloud compute networks peerings list \
  --network=hub-vpc \
  --format='table(name, network, peerNetwork, state, exportCustomRoutes, importCustomRoutes)'

Transit Routing Models

For architectures with many VPCs/VNets, direct peering creates an unmanageable mesh. Transit routing consolidates connectivity through a central hub. Each cloud provides a managed transit service.

FeatureAWS Transit GatewayAzure Virtual WANGCP Network Connectivity Center
ModelHub with VPC attachmentsHub-spoke with auto-routingHub with spokes (hybrid focus)
Max connections5,000 VPCs per TGWThousands of VNetsVaries by spoke type
Cross-regionTGW peering (inter-region)Built-in global routingGlobal by default (GCP VPC)
Cost$0.05/hr + data processing$0.05/hr/hub + data processingData processing fees
hcl
# AWS Transit Gateway
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Central transit hub"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  dns_support                     = "enable"
  auto_accept_shared_attachments  = "enable"

  tags = {
    Name = "central-tgw"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_a" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.vpc_a.id
  subnet_ids         = aws_subnet.vpc_a_private[*].id

  tags = {
    Name = "vpc-a-attachment"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_b" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = aws_vpc.vpc_b.id
  subnet_ids         = aws_subnet.vpc_b_private[*].id

  tags = {
    Name = "vpc-b-attachment"
  }
}

Cross-Cloud Connectivity

Connecting networks across different cloud providers requires VPN tunnels or dedicated interconnects. IPsec VPN is the most common approach: you create VPN gateways in each cloud and establish encrypted tunnels between them. For higher bandwidth and lower latency, use dedicated interconnects through a shared colocation facility.

hcl
# AWS to GCP VPN: AWS side
resource "aws_vpn_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "aws-to-gcp-vgw" }
}

resource "aws_customer_gateway" "gcp" {
  bgp_asn    = 65002
  ip_address = google_compute_ha_vpn_gateway.main.vpn_interfaces[0].ip_address
  type       = "ipsec.1"
  tags       = { Name = "gcp-cgw" }
}

resource "aws_vpn_connection" "gcp" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.gcp.id
  type                = "ipsec.1"
  static_routes_only  = false
  tags                = { Name = "aws-to-gcp-vpn" }
}

# GCP side
resource "google_compute_ha_vpn_gateway" "main" {
  name    = "gcp-to-aws-vpn"
  network = google_compute_network.main.id
  region  = "us-central1"
}

resource "google_compute_external_vpn_gateway" "aws" {
  name            = "aws-vpn-gateway"
  redundancy_type = "TWO_IPS_REDUNDANCY"

  interface {
    id         = 0
    ip_address = aws_vpn_connection.gcp.tunnel1_address
  }
  interface {
    id         = 1
    ip_address = aws_vpn_connection.gcp.tunnel2_address
  }
}

resource "google_compute_vpn_tunnel" "tunnel1" {
  name                  = "aws-tunnel-1"
  vpn_gateway           = google_compute_ha_vpn_gateway.main.id
  peer_external_gateway = google_compute_external_vpn_gateway.aws.id
  shared_secret         = aws_vpn_connection.gcp.tunnel1_preshared_key
  router                = google_compute_router.main.id
  vpn_gateway_interface = 0
  peer_external_gateway_interface = 0
}

IP Address Planning for Multi-Cloud

The most critical aspect of multi-cloud networking is IP address planning. Overlapping CIDR ranges make peering impossible and require NAT for communication, adding complexity and latency. Plan your IP allocation before building any infrastructure.

CloudRecommended CIDR RangeNetworks
AWS10.0.0.0/8 (10.0-10.63)10.0.0.0/16, 10.1.0.0/16, ...
Azure10.64.0.0/10 (10.64-10.127)10.64.0.0/16, 10.65.0.0/16, ...
GCP10.128.0.0/9 (10.128-10.255)10.128.0.0/16, 10.129.0.0/16, ...
On-premises172.16.0.0/12172.16.0.0/16, 172.17.0.0/16, ...

RFC 1918 Overlap Risk

Many organizations start with 10.0.0.0/16 in every cloud, which creates immediate conflicts when trying to connect networks. Establish an IP Address Management (IPAM) process early and assign non-overlapping ranges per cloud, region, and environment. AWS VPC IPAM, Azure IPAM, and GCP subnet allocation can help automate this.

Peering Model Comparison

FeatureAWSAzureGCP
ScopeRegional (per-VPC)Regional or GlobalGlobal (VPC is global)
TransitiveNoVia Virtual WAN/NVANo
Max peerings125 per VPC500 per VNet25 per network (adjustable)
Cross-accountYes (with acceptance)Yes (cross-subscription)Yes (cross-project)
DNS resolutionRoute 53 resolver rulesPrivate DNS zones with linksCloud DNS peering zones
Data cost (intra-region)FreeFreeFree

Use Terraform Modules

For multi-cloud networking, create reusable Terraform modules for each connectivity pattern (peering, VPN, transit). This ensures consistent configuration across clouds and environments. The terraform-google-modules/network,terraform-aws-modules/vpc, and Azure CAF modules provide community-maintained starting points.

Multi-Cloud Networking ComparisonAWS Transit Gateway Guide

Key Takeaways

  1. 1AWS VPC Peering is non-transitive with 125 peerings per VPC; use Transit Gateway for hub-and-spoke.
  2. 2Azure VNet Peering supports gateway transit for transitive routing through hub VNets.
  3. 3GCP VPC Network Peering is global since GCP VPCs span all regions.
  4. 4Cross-cloud connectivity requires IPsec VPN tunnels or dedicated interconnects.

Frequently Asked Questions

Can I peer VPCs across different cloud providers?
No. VPC peering is intra-cloud only. To connect networks across clouds, use IPsec VPN tunnels or dedicated interconnects through shared colocation facilities.
How should I plan IP addresses for multi-cloud?
Allocate non-overlapping CIDR ranges per cloud. For example: AWS 10.0-10.63.x.x, Azure 10.64-10.127.x.x, GCP 10.128-10.255.x.x. Establish an IPAM process before building infrastructure.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.