VPC Network Peering
A direct connection between two separate VPCs, potentially in different Projects or Organizations, with traffic never touching the public internet. Peering must be established from both sides to become active, and is explicitly non-transitive - if VPC A peers with B, and B peers with C, A cannot reach C without its own direct peering connection to C.
Frequently Asked Questions
Why is VPC Network Peering's non-transitivity such a common design trap?
Engineers coming from traditional networking often expect transitive routing — if A trusts B and B trusts C, surely A can reach C. GCP peering explicitly does not work that way for isolation reasons: each peering relationship is a distinct point-to-point trust, so a hub-and-spoke topology where a central VPC peers with several others does NOT let those spoke VPCs talk to each other. Reaching that requires either a direct peering connection between the spokes or routing through a different mechanism like Network Connectivity Center.
What operational gotcha catches teams off guard after setting up peering?
Peering must be actively accepted from both VPCs (`gcloud compute networks peerings create` on each side) — creating it from only one side leaves the connection in an inactive state with no traffic flowing, and there's no automatic notification prompting the other side to complete it. Also, exported custom routes and firewall rules aren't inherited automatically; each VPC must separately allow ingress from the peer's IP ranges, which people frequently forget, leading to a 'peering active but connection times out' scenario.