VPC/VNet/VCN Peering Across Clouds
Compare VPC Peering across AWS, Azure, GCP: peering models, transit routing, cross-cloud VPN, and IP planning.
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
| Limitation | Impact | Workaround |
|---|---|---|
| Non-transitive | VPC A peered to B, B to C: A cannot reach C | Use Transit Gateway |
| No overlapping CIDRs | Peered VPCs must have non-overlapping IP ranges | Plan CIDR allocation carefully |
| No edge-to-edge routing | Cannot route through a peered VPC's VPN or Direct Connect | Use Transit Gateway |
| 125 peerings per VPC | Hard limit (not adjustable) | Use Transit Gateway for many-to-many |
# 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-2Azure 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.
# 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 tableGCP 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.
# 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.
| Feature | AWS Transit Gateway | Azure Virtual WAN | GCP Network Connectivity Center |
|---|---|---|---|
| Model | Hub with VPC attachments | Hub-spoke with auto-routing | Hub with spokes (hybrid focus) |
| Max connections | 5,000 VPCs per TGW | Thousands of VNets | Varies by spoke type |
| Cross-region | TGW peering (inter-region) | Built-in global routing | Global by default (GCP VPC) |
| Cost | $0.05/hr + data processing | $0.05/hr/hub + data processing | Data processing fees |
# 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.
# 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.
| Cloud | Recommended CIDR Range | Networks |
|---|---|---|
| AWS | 10.0.0.0/8 (10.0-10.63) | 10.0.0.0/16, 10.1.0.0/16, ... |
| Azure | 10.64.0.0/10 (10.64-10.127) | 10.64.0.0/16, 10.65.0.0/16, ... |
| GCP | 10.128.0.0/9 (10.128-10.255) | 10.128.0.0/16, 10.129.0.0/16, ... |
| On-premises | 172.16.0.0/12 | 172.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
| Feature | AWS | Azure | GCP |
|---|---|---|---|
| Scope | Regional (per-VPC) | Regional or Global | Global (VPC is global) |
| Transitive | No | Via Virtual WAN/NVA | No |
| Max peerings | 125 per VPC | 500 per VNet | 25 per network (adjustable) |
| Cross-account | Yes (with acceptance) | Yes (cross-subscription) | Yes (cross-project) |
| DNS resolution | Route 53 resolver rules | Private DNS zones with links | Cloud DNS peering zones |
| Data cost (intra-region) | Free | Free | Free |
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.
Key Takeaways
- 1AWS VPC Peering is non-transitive with 125 peerings per VPC; use Transit Gateway for hub-and-spoke.
- 2Azure VNet Peering supports gateway transit for transitive routing through hub VNets.
- 3GCP VPC Network Peering is global since GCP VPCs span all regions.
- 4Cross-cloud connectivity requires IPsec VPN tunnels or dedicated interconnects.
Frequently Asked Questions
Can I peer VPCs across different cloud providers?
How should I plan IP addresses for multi-cloud?
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.