The Mental Model That Finally Made GCP Networking Click
I spent my first year on GCP drawing the wrong mental model. I kept mapping AWS concepts onto Google’s network, and it kept being subtly wrong in ways that were hard to debug.
The breakthrough was realizing that GCP’s VPC is global by default, and that changes everything downstream.
The AWS mental model (and why it fails you on GCP)
In AWS, a VPC is regional. You create a VPC in us-east-1, and that VPC only exists there. If you want resources in eu-west-1, you create another VPC. Connecting them requires VPC peering, Transit Gateway, or some other explicit glue.
The mental model is: VPC = region.
If you carry this mental model into GCP, you will design unnecessarily complex architectures and be confused by behavior that is actually working correctly.
GCP’s actual model
In GCP, a VPC is a global resource. A single VPC spans all regions. What are regional are the subnets within that VPC.
Think of it like this:
- AWS VPC = a datacenter building (one location, self-contained)
- GCP VPC = a campus network (one logical network, multiple physical locations connected by your own fiber)
Google owns the physical network between regions. When you create a VPC and have subnets in us-central1 and europe-west1, traffic between those subnets travels over Google’s internal backbone — not the public internet.
This matters. A lot.
What this actually means for you
Cross-region traffic is cheap and fast. You don’t need Transit Gateway equivalents. A VM in Iowa can talk to a VM in Belgium on the same RFC-1918 subnet space, on Google’s private network.
Firewall rules are global. A firewall rule applied to your VPC applies everywhere. No more “oh I forgot to add that rule in the us-west region.”
Shared VPCs are a superpower. You can share a single VPC across multiple GCP projects. One networking team manages the VPC; application teams deploy their workloads into it. This is the cleanest org-level networking pattern I’ve seen in any cloud.
Shared VPC is called “XPN” internally at Google (Cross-Project Networking). If you see that term in documentation, that’s what it means.
The one thing that still trips people up
Even though the VPC is global, Cloud Router and NAT are regional. This is the one place where regional boundaries sneak back in.
If you have private VMs (no public IP) in multiple regions that need outbound internet access, you need a Cloud Router + Cloud NAT per region. I’ve seen this catch people who assume the VPC’s global nature extends to all its components.
It doesn’t. Regional components are regional. Global components are global. Learn which is which and you’ll stop being surprised.
Further reading
If you want to go deeper, the GCP VPC documentation is actually quite good:
The mental model shift takes about a day to really sink in. After that, GCP networking starts feeling elegant rather than alien. It is genuinely elegant — you just have to meet it on its own terms.