In the world of traditional networking, a network is a physical thing. You buy cables, plug them into switches, and pray that spanning-tree doesn’t ruin your Monday. In Google Cloud, there are no cables. There are no switches you can SSH into. The entire network is a software-defined abstraction running on top of one of the most advanced physical infrastructures on the planet—Google’s own backbone. At the heart of this abstraction sits the Virtual Private Cloud (VPC), and understanding how it works is the single most important foundation for the Professional Cloud Network Engineer exam.
A VPC in Google Cloud is a global resource. This is the first thing that trips up anyone coming from AWS or Azure, where a VPC is locked to a single region. In Google Cloud, a single VPC can span every region on earth simultaneously. You create one VPC, and it exists everywhere. The subnets inside it, however, are regional. This means you define an IP range like 10.1.0.0/24 and assign it to us-central1, and another range like 10.2.0.0/24 to europe-west1. Both subnets live inside the same global VPC, and VMs in Iowa can talk to VMs in the Netherlands without any peering, VPN, or special configuration. The global VPC is the defining characteristic of Google Cloud networking.
The Two Modes: Auto vs. Custom
When you create a VPC, Google asks you to pick a mode. This choice has permanent consequences.
Auto Mode: The “Convenient” Trap
An Auto Mode VPC is effectively a clone of the “Default” VPC that Google provides in every new project. It is designed for speed over strategy.
- Google creates one subnet in every single region automatically.
- Every Auto Mode VPC uses the exact same CIDR blocks, starting at
10.128.0.0/20. - You don’t have to specify IP ranges or subnet locations.
The problem? Because every Auto Mode VPC uses identical CIDRs, you cannot peer them. If you try to connect Project A’s VPC to Project B’s VPC, they will collide. This is what I call the “Illegal Reality” of Auto Mode—it looks convenient until you try to build anything beyond a single project.
Custom Mode: The Only Sane Choice
In a Custom Mode VPC, you start with a blank canvas. You only build what you need, where you need it. This is the production standard for three reasons:
- Zero Overlap: You pick your own CIDRs, ensuring no conflict with on-premises or other cloud providers.
- Lean Infrastructure: No subnets in regions you’ll never use. Cleaner routing tables.
- Security: You control the IP boundaries from the start, reducing the blast radius of a misconfiguration.
How Routing Actually Works
Every VPC has an invisible routing table. When a packet is born inside a VM, the hypervisor intercepts it and consults this table. The rules are simple but critical:
1. Specificity Wins
If you have a route for 10.2.0.0/24 and another for 10.2.0.0/16, a packet destined for 10.2.0.5 will always take the /24 route. The more specific mask always wins, regardless of priority.
2. Priority is the Tiebreaker
If two routes have the same specificity (e.g., both are /24), the one with the lower priority number wins. Priority 100 beats Priority 1000.
3. System Routes vs. Custom Routes
Google creates “system routes” automatically (like the default gateway 0.0.0.0/0 to the internet). You can create “custom routes” to override them—for example, sending all traffic through a firewall appliance.
VPC Peering and the Transitivity Problem
VPC Peering allows two separate VPCs to exchange traffic directly using internal IPs, without going through the public internet. It sounds perfect until you encounter the fundamental law of GCP peering: Peering is non-transitive.
Imagine three VPCs: A, B, and C. You peer A with B, and B with C. Can A talk to C? No. VPC B does not act as a router between A and C. Each peering relationship is a direct, isolated link.
This is why Shared VPC exists. Instead of peering many VPCs together (and dealing with transitivity), you create a single “Host Project” VPC and attach “Service Projects” to it. All service projects share the same network—one routing table, one set of firewall rules, centralized control. This is the enterprise standard for multi-team organizations.
Putting it Together: A Pro-Engineer View
Imagine you are designing the network for a multi-national company. The development team is in India, the production servers are in Iowa, and the analytics pipeline runs in the Netherlands. With a single Custom Mode VPC, you create three subnets—one per region—with non-overlapping CIDRs. Traffic flows freely between them over Google’s backbone. You never touch a cable, configure a BGP session, or worry about inter-region latency beyond physics. That is the power of the global VPC—it is not just a network, it is a programmable, planet-spanning fabric.
