Every diagram in this series so far has shown one VPC. Real organizations rarely stay that small — you end up with separate environments (dev, staging, prod), separate teams with their own AWS accounts or GCP projects, sometimes a data platform that's deliberately isolated from everything else for compliance reasons. All of those networks eventually need to talk to each other, and how you connect them matters a lot more than it looks at first glance.
AWS: VPC Peering vs. Transit Gateway
VPC Peering connects two VPCs directly, using AWS's private backbone — no hourly charge, low latency, straightforward to set up. You request the connection, the other side accepts it, you update route tables on both ends, done.
The catch is the same one we flagged back in Part 2: peering isn't transitive. If VPC A peers with B, and B peers with C, A still cannot reach C — B doesn't relay traffic on A's behalf. Connect 4 VPCs with peering and you need 6 individual connections; get to a few dozen VPCs and you're maintaining a genuinely unmanageable mesh of point-to-point links and route table entries.
That's what 4 VPCs fully connected via peering looks like: 6 connections, and it only gets worse from there. This is exactly the problem Transit Gateway solves — a central hub that every VPC attaches to once. Attach 100 VPCs, and you have 100 attachments instead of thousands of pairwise connections, and — critically — routing between them is transitive through the hub.
Transit Gateway isn't free, though — it charges an hourly rate per attachment plus a per-gigabyte processing fee, and it adds a small routing hop of latency compared to peering's direct path. For a data platform specifically: if you're centralizing ingestion from many isolated source VPCs, or connecting a handful of stable environments (dev/staging/prod) that rarely change, peering is often genuinely fine. Once you're managing more than a handful of VPCs, need hybrid on-premises connectivity in the same place, or want centralized routing policy, Transit Gateway earns its cost.
One more peering limitation worth knowing before you design around it: CIDR blocks can't overlap. Two VPCs that both happen to use 10.0.0.0/16 simply cannot be peered — a real problem after a merger or when two teams picked the same "obvious" default range independently. Transit Gateway can at least contain the damage — overlapping attachments can be walled off into separate route table domains — but the two ranges still can't talk to each other, so it's containment, not a fix. The real solution is avoiding overlapping ranges from the start.
GCP: Shared VPC vs. Network Connectivity Center
GCP splits this same problem into two different tools, aimed at two different situations.
Shared VPC isn't primarily about connecting separate networks — it's about one team centrally managing a network that other teams' projects use directly. A "host project" owns the VPC, subnets, and firewall rules; other "service projects" get resources (VMs, GKE clusters, Dataproc jobs) attached directly into those shared subnets, as if they lived in the host project's network all along. There's no peering, no route exchange to configure — because there's really only one network underneath.
This is a genuinely common pattern for data platforms: a central platform team owns the Shared VPC (and its Cloud NAT, its Private Google Access settings, its firewall rules), while individual data and ML teams get their own projects — separate billing, separate IAM boundaries — without needing to reinvent network setup each time.
Network Connectivity Center (NCC), by contrast, is GCP's actual hub-and-spoke connectivity tool — the closer equivalent to Transit Gateway. It connects genuinely separate VPCs (plus on-premises VPN or Interconnect links) through a central hub, with automatic route exchange between spokes.
The rule of thumb GCP itself gives: use plain VPC peering for a simple two-network connection; reach for NCC once you're dealing with more than a handful of networks, need transitive routing between them, or want to fold in on-premises connectivity centrally. Don't reach for Shared VPC as a substitute hub-and-spoke tool — it was built for centralized ownership of one network across projects, not for connecting many independent networks together.
Quick Comparison
| AWS | GCP | Best for | |
|---|---|---|---|
| Direct, simple link | VPC Peering | VPC Peering | A few stable, long-lived VPC pairs |
| Centralized hub, many networks | Transit Gateway | Network Connectivity Center | Dozens of VPCs, hybrid on-prem, transitive routing |
| One network, many teams | — | Shared VPC | Centralized platform team, decentralized project ownership |
Bringing a Data Platform Example Together
A fairly typical shape for a mid-sized data platform: a central ingestion VPC (or Shared VPC on GCP) that owns the NAT/Cloud NAT setup and receives data from various sources, connected via Transit Gateway or NCC to separate processing VPCs per team or environment, each with their own 3-tier layout from Part 3. Isolation where it's needed, shared infrastructure where it isn't — and no team accidentally getting network access they were never supposed to have, because the hub enforces exactly which spokes can reach which.
What's Next
We've now covered the full shape of a multi-VPC data platform — but plenty of the security and cost decisions along the way have been mentioned only in passing: least-privilege network design, common misconfigurations that pass an initial review but fail an audit, and how to actually check a platform's network posture before something goes wrong. Part 6, the final piece of this series, pulls all of that together.
Top comments (0)