VPC Peering vs Cloud VPN: Connecting Networks the Right Way on GCP

Two GCP networking primitives get reached for interchangeably by engineers who haven’t hit their differences yet — VPC Peering and Cloud VPN — and picking wrong isn’t usually catastrophic, but it does mean re-architecting connectivity later once the actual constraint (transitivity, encryption overhead, or on-prem reachability) becomes a real problem instead of a theoretical one. They solve genuinely different connectivity problems: Peering connects two VPCs (typically both on GCP) as if they were one network for routing purposes, without encryption or a gateway in the path; VPN establishes an encrypted tunnel, typically between GCP and somewhere that isn’t GCP-native networking, like an on-prem data center or another cloud.

Getting this choice right the first time avoids a genuinely annoying migration later, so it’s worth understanding both mechanisms’ actual constraints before defaulting to whichever one you’ve used before.

VPC Peering: Two Networks, One Routing Domain

# Peering must be configured from both sides
gcloud compute networks peerings create peer-to-partner \
  --network=my-vpc \
  --peer-network=partner-vpc \
  --peer-project=partner-project

gcloud compute networks peerings create peer-to-us \
  --network=partner-vpc \
  --project=partner-project \
  --peer-network=my-vpc \
  --peer-project=my-project

Once established, VMs in either VPC can reach each other using internal IPs directly, over Google’s internal network — no VPN gateway, no encryption overhead, no bandwidth cap beyond what the underlying network supports. The connection is genuinely fast because it’s not actually “connecting” two separate networks through a gateway at all; it’s extending route visibility so each side’s router knows about the other’s subnets.

The Critical Constraint: Peering Is Not Transitive

This is the single most important thing to understand about VPC Peering, and it catches nearly everyone the first time they design a multi-VPC architecture:

VPC A peered with VPC B, and VPC B peered with VPC C, does not mean VPC A can reach VPC C. Each peering relationship is strictly point-to-point — if you need A and C to communicate, they need their own direct peering connection, or you need a different architecture entirely (a hub VPC that both A and C route through via VPN or Interconnect rather than peering, since VPN-based hub-and-spoke doesn’t have this transitivity limitation). Teams that don’t know this constraint upfront design a “peer everything to a central hub VPC” architecture assuming spoke-to-spoke traffic will just work through the hub, and then discover it doesn’t the first time they actually test cross-spoke connectivity.

Cloud VPN: Encrypted Tunnels Over the Public Internet

# HA VPN — the recommended, redundant VPN option
gcloud compute vpn-gateways create my-ha-vpn-gateway \
  --network=my-vpc \
  --region=us-central1

gcloud compute external-vpn-gateways create onprem-gateway \
  --interfaces=0=203.0.113.1

gcloud compute vpn-tunnels create tunnel-1 \
  --peer-external-gateway=onprem-gateway \
  --peer-external-gateway-interface=0 \
  --region=us-central1 \
  --ike-version=2 \
  --shared-secret=REPLACE_WITH_STRONG_SECRET \
  --router=my-cloud-router \
  --vpn-gateway=my-ha-vpn-gateway \
  --interface=0

HA VPN (High Availability VPN) is Google’s current recommended VPN configuration, using two interfaces on the gateway to provide a documented 99.99% availability SLA when configured correctly with redundant peer connections — a meaningful improvement over the older Classic VPN, which lacked the same redundancy guarantees. Traffic through Cloud VPN is encrypted (IPsec) and routed over the public internet, which means both genuine security (the encryption) and a real throughput ceiling (each tunnel caps around 3 Gbps, and public internet routing is inherently less predictable than a dedicated connection).

For workloads needing more than a single tunnel’s throughput, Cloud VPN supports multiple tunnels between the same two endpoints with traffic distributed across them via equal-cost multi-path routing — a reasonable, incremental way to scale VPN throughput before concluding that Interconnect’s dedicated bandwidth and higher upfront commitment is genuinely necessary for the workload in question.

When Each Actually Fits

┌───────────────────────────┬──────────────────────────────────┐
│ Scenario                     │ Right tool                          │
├───────────────────────────┼──────────────────────────────────┤
│ Two GCP VPCs (yours or a      │ VPC Peering — fast, no encryption   │
│ partner's) needing internal   │ overhead, no bandwidth VPN caps      │
│ IP connectivity                │                                     │
│ GCP to on-prem data center     │ Cloud VPN (for moderate bandwidth)  │
│                                │ or Interconnect (for high bandwidth,│
│                                │ dedicated connectivity)              │
│ GCP to another cloud provider  │ Cloud VPN — since Peering only      │
│ (AWS, Azure)                   │ works between GCP VPCs               │
│ Multiple VPCs needing          │ Neither directly — needs a hub      │
│ transitive any-to-any          │ architecture via VPN/Interconnect,   │
│ connectivity                    │ or Network Connectivity Center       │
└───────────────────────────┴──────────────────────────────────┘

The last row is worth calling out specifically: for genuinely complex multi-VPC topologies needing transitive connectivity, Network Connectivity Center is GCP’s purpose-built hub-and-spoke solution, designed specifically to avoid the non-transitivity limitation that makes pure VPC Peering unsuitable for hub-and-spoke architectures beyond a small, simple topology.

Peering vs Shared VPC: A Different Comparison Worth Making Too

Peering gets compared to VPN constantly, but it’s worth a separate comparison against Shared VPC too, since both connect resources across project boundaries and get confused with each other almost as often.

┌───────────────────────┬────────────────────────────────────────┐
│ Aspect                  │ VPC Peering vs Shared VPC                  │
├───────────────────────┼────────────────────────────────────────┤
│ Network ownership        │ Peering: two separate, independently-     │
│                          │ owned VPCs. Shared VPC: one VPC, centrally│
│                          │ owned, used by multiple projects           │
│ Administrative control   │ Peering: each side manages its own VPC     │
│                          │ independently. Shared VPC: one team (the   │
│                          │ host project owner) controls the network   │
│ Best fit                 │ Peering: connecting genuinely separate     │
│                          │ organizations or independently-managed     │
│                          │ teams. Shared VPC: one organization         │
│                          │ wanting centralized network administration │
│                          │ with distributed project usage              │
└───────────────────────┴────────────────────────────────────────┘

The practical decision test: if the two sides should remain administratively independent — different teams, different companies, different security postures — Peering is the right model, since each side keeps full control over its own network. If it’s genuinely one organization that wants centralized IP address and firewall management with individual teams only needing project-level autonomy for everything else, Shared VPC is almost always the better fit, since it avoids the non-transitivity headaches entirely by not needing multiple VPCs to begin with.

Real-World Use Case: Multi-Team SaaS Marketplace Integration

A company building a marketplace platform where partner companies each run their own GCP project and need low-latency access to a shared backend service is a natural Peering use case — rather than routing partner traffic over the public internet with VPN overhead, peering each partner’s VPC to the platform’s shared services VPC gives fast, private internal-IP connectivity. The non-transitivity constraint is actually a feature here, not a limitation: partner A’s VPC being peered to the shared platform VPC doesn’t give partner A any path to partner B’s VPC, which is exactly the isolation a multi-tenant marketplace needs between competing or unrelated partners.

Real-World Use Case: Hybrid Cloud Disaster Recovery

A company running primary infrastructure on GCP with a disaster-recovery environment on AWS needs connectivity between the two clouds — VPC Peering doesn’t apply here at all, since it’s GCP-to-GCP only. Cloud VPN (HA VPN configured with redundant tunnels) is the standard pattern for this kind of cross-cloud connectivity, providing encrypted, reasonably reliable connectivity for replication traffic and failover coordination between the two environments without requiring a dedicated physical circuit, which would be hard to justify for a DR environment that’s mostly idle.

Best Practices

• Design around Peering’s non-transitivity from the start, not as an afterthought discovered during testing — if transitive connectivity is a real requirement, choose Network Connectivity Center or a VPN/Interconnect hub architecture from the beginning.
• Always use HA VPN over Classic VPN for anything new — the availability guarantee and redundancy model are meaningfully better, and Classic VPN is effectively legacy at this point.
• Watch for overlapping IP ranges before peering. Peering fails outright if the two VPCs have overlapping subnet ranges, which is a strong argument for deliberate, non-overlapping IP address planning across your entire organization from the start.
• Use Cloud Router with BGP for VPN route management, rather than static routes, for the same operational reasons that apply to Interconnect — automatic route propagation as subnets change.
• Treat both peering deletions and VPN tunnel changes as disruptive operations requiring change management, not routine configuration edits — active traffic can depend on either, and removing them abruptly is a real outage risk.

Common Mistakes

Assuming peering is transitive and designing a hub-and-spoke architecture around that assumption. This is consistently the most common VPC Peering mistake, and it’s discovered late, during actual connectivity testing, rather than during design review.

Choosing VPN when Interconnect’s bandwidth or reliability characteristics were actually needed. VPN’s throughput ceiling and public-internet routing variability make it a poor fit for high-volume, latency-sensitive hybrid traffic — a mismatch that shows up as intermittent performance problems rather than an outright failure.

Not checking for IP range overlap before attempting to peer two VPCs. This fails the peering setup outright, and untangling overlapping ranges after the fact (re-addressing an entire VPC) is a genuinely painful retrofit compared to planning non-overlapping ranges from the start.

Frequently Asked Questions

Can I peer a GCP VPC with an AWS VPC? No — VPC Peering is a GCP-native construct that only connects GCP VPCs to each other. Cross-cloud connectivity requires VPN or a dedicated interconnection service.

Does VPC Peering cost extra beyond standard network egress? Peering itself doesn’t have a separate line-item cost, but standard inter-region or inter-network egress pricing still applies to traffic crossing the peering connection, depending on the specific traffic pattern.

How many VPCs can be peered to a single VPC? There’s a documented per-VPC peering connection limit (which can typically be increased via quota request), but the practical constraint most teams hit first is the non-transitivity limitation itself, not the raw connection count.

Is Cloud VPN suitable for latency-sensitive real-time applications? Generally not ideal — because it routes over the public internet, latency and jitter are less predictable than a dedicated Interconnect connection. For latency-sensitive hybrid traffic, Interconnect is the better-suited option where the volume justifies it.

Can I use both Peering and Shared VPC in the same organization? Yes — they’re not mutually exclusive, and larger organizations commonly use Shared VPC for internal team network administration while using Peering separately to connect to partner organizations or acquired companies’ independently-managed networks, layering both patterns where each genuinely fits.

What happens to existing connections if a peering relationship is deleted? Deleting a peering connection immediately removes route visibility between the two VPCs — existing connections relying on those routes will fail, so this should be treated as a disruptive change requiring the same care as removing a firewall rule that active traffic depends on.

A Final Note on Documentation

Whichever mechanism you choose, document the actual reason behind it — not just “we peered these VPCs” but why, and what alternative was considered and rejected. Connectivity decisions made for good reasons at the time (a partner integration, a specific bandwidth requirement) tend to outlive the people who made them, and a future engineer inheriting an unexplained peering connection or VPN tunnel has no way to know whether it’s safe to remove during a cleanup, or whether it’s silently load-bearing for something they can’t see from the configuration alone.

Summary

VPC Peering and Cloud VPN aren’t competing solutions to the same problem — they solve genuinely different connectivity needs, and the choice mostly falls out naturally once you’re clear on whether you’re connecting two GCP VPCs (peering) or reaching something outside GCP-native networking entirely (VPN, or Interconnect for higher bandwidth). The one constraint worth internalizing before any architecture diagram gets drawn is Peering’s non-transitivity — it shapes whether a simple mesh of peering connections will actually work for your topology, or whether you need a purpose-built hub architecture from the very first design decision — a distinction far cheaper to get right on a whiteboard early in the design process than to discover the hard way during a live connectivity test.