Overview and What You Will Learn
In this lab, you will create a VPC Network Peering connection between two VPCs and understand its non-transitive nature directly, then compare it conceptually against Cloud VPN's genuinely different use case of connecting to an on-premises network rather than another GCP VPC.
Why This Matters in Production
A team peers VPC A with VPC B, and separately peers VPC B with VPC C, then is confused when resources in VPC A cannot reach resources in VPC C - despite both being connected to VPC B. VPC Network Peering is explicitly non-transitive, the same rule that applies in AWS and Azure's peering models, and assuming otherwise leads directly to this exact confusing troubleshooting session.
Core Principles
Cloud VPN and VPC Network Peering solve genuinely different connectivity problems, distinguished by what's on the other end of the connection.
+------------------------------------------+| Cloud VPN || Connects an on-premises network to a GCP || VPC over an encrypted tunnel || Traffic travels over the public internet || (encrypted), unless paired with || Interconnect for a dedicated path |+------------------------------------------+| VPC Network Peering || Connects two separate VPCs directly || (potentially in different projects or || organizations) || Traffic never touches the public internet || Explicitly non-transitive |+------------------------------------------+Detailed Step-by-Step Practical Lab
- Create a project with two separate VPCs to demonstrate peering:
gcloud projects create gcp-peering-lab-2026 --name="Peering Lab"gcloud config set project gcp-peering-lab-2026gcloud services enable compute.googleapis.com gcloud compute networks create vpc-prod --subnet-mode=customgcloud compute networks subnets create subnet-prod \ --network=vpc-prod --region=asia-south1 --range=10.0.1.0/24 gcloud compute networks create vpc-analytics --subnet-mode=customgcloud compute networks subnets create subnet-analytics \ --network=vpc-analytics --region=asia-south1 --range=10.1.1.0/24- Create the peering connection from the first VPC's side:
gcloud compute networks peerings create peering-prod-to-analytics \ --network=vpc-prod \ --peer-network=vpc-analytics- Create the corresponding peering connection from the second VPC's side - peering must be established from both sides to become active:
gcloud compute networks peerings create peering-analytics-to-prod \ --network=vpc-analytics \ --peer-network=vpc-prod- Confirm both peering connections are active:
gcloud compute networks peerings list --network=vpc-prodgcloud compute networks peerings list --network=vpc-analytics- Create a third VPC and peer it only with
vpc-analytics, to demonstrate the non-transitive rule directly:
gcloud compute networks create vpc-reporting --subnet-mode=customgcloud compute networks subnets create subnet-reporting \ --network=vpc-reporting --region=asia-south1 --range=10.2.1.0/24 gcloud compute networks peerings create peering-reporting-to-analytics \ --network=vpc-reporting \ --peer-network=vpc-analytics gcloud compute networks peerings create peering-analytics-to-reporting \ --network=vpc-analytics \ --peer-network=vpc-reportingConfirm
vpc-prodandvpc-reportinghave no direct connectivity, despite both being peered withvpc-analytics- this is the non-transitive rule in action, and would require its own direct peering connection betweenvpc-prodandvpc-reportingto actually communicate.Cloud VPN, by contrast, is set up for connecting to a genuinely external, on-premises network rather than another GCP VPC - conceptually, this requires a Cloud Router, a VPN Gateway, and a Tunnel resource pointing at the on-premises device's public IP, a distinct workflow from VPC Peering shown here.
Clean up:
gcloud compute networks peerings delete peering-prod-to-analytics --network=vpc-prod --quietgcloud compute networks peerings delete peering-analytics-to-prod --network=vpc-analytics --quietgcloud compute networks peerings delete peering-reporting-to-analytics --network=vpc-reporting --quietgcloud compute networks peerings delete peering-analytics-to-reporting --network=vpc-analytics --quietgcloud compute networks subnets delete subnet-prod --region=asia-south1 --quietgcloud compute networks subnets delete subnet-analytics --region=asia-south1 --quietgcloud compute networks subnets delete subnet-reporting --region=asia-south1 --quietgcloud compute networks delete vpc-prod vpc-analytics vpc-reporting --quietgcloud projects delete gcp-peering-lab-2026 --quietProduction Best Practices & Common Pitfalls
Common MistakeAssuming VPC Network Peering is transitive - that if VPC A peers with VPC B, and VPC B peers with VPC C, then A can automatically reach C. Peering in GCP (like in AWS and Azure) is explicitly non-transitive; A and C need their own direct peering connection to communicate, regardless of B's relationship to both.
TipFor connectivity patterns needing many-to-many VPC communication - more than a simple pair or two - consider Network Connectivity Center instead of building an increasingly complex mesh of individual peering connections, the same architectural lesson that applies to Transit Gateway in AWS or Azure.
- Peering must be established from both sides to become active - creating the peering resource on only one VPC leaves the connection in an inactive, waiting state until the other side's matching peering resource is also created.
- IP address ranges must not overlap between peered VPCs. Two VPCs both using
10.0.0.0/8cannot be peered together - this is exactly why deliberate, non-overlapping CIDR planning across an organization's VPCs matters before peering becomes a real, live requirement.
Quick Reference & Troubleshooting Commands
| Command | Description |
|---|---|
gcloud compute networks peerings create |
Create a peering connection from one VPC's side |
gcloud compute networks peerings list --network= |
List peering connections for a specific VPC |
gcloud compute networks peerings delete |
Remove a peering connection |
gcloud compute vpn-gateways create |
Create a Cloud VPN gateway for on-premises connectivity |