VPC Networking

GCP Fundamentals

Chapter 5 · VPC Networking

AWS Fundamentals Chapter 5 built a VPC scoped to one Region, with subnets each bound to one AZ. Azure Fundamentals Chapter 5 loosened that one notch — a VNet's own subnets span every AZ within a Region. GCP goes a full step further still, and this chapter's own real structural difference is the biggest of the entire three-course arc.

A Real, Major Structural Leap: The VPC Itself Is Global

Genuinely Beyond What AWS or Azure Offer

A GCP VPC network — including its own routes and firewall rules — is a real, global resource, not tied to any particular region or zone at all. Only subnets are regional. This is a genuinely bigger structural difference than even Azure's own subnet-spans-all-AZs model: a single GCP VPC can span every real region on the planet at once, with regional subnets created inside it wherever actually needed — never multiple separate VPCs peered together just to cover more than one region, the way a real multi-region AWS or Azure architecture typically requires.

One real, practical consequence: firewall rules and routes, both attached to the VPC itself, automatically apply consistently everywhere that VPC has subnets — a single global ruleset, not one per region.

Auto Mode vs. Custom Mode

Auto mode — GCP automatically creates one real subnet per region, using predefined ranges inside 10.128.0.0/9, and automatically provisions a new subnet whenever Google Cloud adds a region.
Custom mode — you create every subnet manually, choosing exactly which regions get one and what IP range each uses.

Google's Own Real Recommendation

Google's own real documentation recommends custom mode for production specifically — auto mode's automatic subnet creation as new regions launch can silently create IP ranges that conflict with your own deliberate network planning, without any explicit action on your part.

Global Routes

Because the VPC itself is global, its own real routes are too — a route created once applies across the entire network, in every region the VPC has a subnet in, rather than needing to be duplicated per region the way an AWS route table must be attached separately to each subnet.

Cloud NAT

Cloud NAT gives private instances real outbound-only internet access, without any instance needing its own external IP — the same real capability as an AWS or Azure NAT Gateway. Its own real configuration model is genuinely simple: you configure a NAT gateway on a Cloud Router (which supplies the real control plane), specifying which subnets it serves — no separate route table entry is required at all, matching Azure's own simpler no-route-table NAT Gateway attachment (Chapter 5 of Azure Fundamentals) rather than AWS's own explicit route table requirement.

Firewall Rules, Revisited

Chapter 3 already introduced GCP's own real firewall model: rules defined at the network level, enforced per-instance via network tags or service accounts. Now that this chapter has established the VPC's own real global scope, the full picture is clear: a single set of firewall rules, attached to one global VPC, governs traffic consistently across every region that VPC touches — genuinely different from both AWS (per-instance security groups plus per-subnet NACLs, each scoped to one Region's own VPC) and Azure (one stateful NSG type, but still scoped to one Region's own VNet).

Three Real Network Models, Compared

Property	AWS VPC	Azure VNet	GCP VPC Network
VPC/network scope	One Region	One Region	Global — every region at once
Subnet scope	One specific AZ	All AZs in the Region	One specific Region
Firewall scope	Per-VPC (one Region)	Per-VNet (one Region)	Per-VPC (global)
NAT attachment	Requires a route table entry	No route table entry needed	No route table entry needed (Cloud Router-based)
Multi-region networking	Multiple VPCs, peered/connected manually	Multiple VNets, peered manually	One VPC, naturally spanning regions

Hands-On Exercises

Exercise 1

A team with prior AWS and Azure experience creates three separate VPC networks in GCP - one for each of three regions they plan to deploy into - expecting this to be necessary the way it was for their own AWS/Azure architectures. Explain, in your own words, why this is genuinely unnecessary on GCP.

📄 View solution

Exercise 2

A production team uses an Auto mode VPC network, and months later, Google adds a new real region their organization has no plans to ever deploy into. Explain, in your own words, what real, automatic consequence this has for their network, and why Custom mode would have avoided it.

📄 View solution

Exercise 3

A team updates one firewall rule on their single GCP VPC network, which has subnets in four different regions. Explain, in your own words, whether they need to repeat that same update three more times for the other regions, and why - contrasting this with how the equivalent update would work on AWS.

📄 View solution

Chapter 5 Quick Reference

Real, major structural leap: a GCP VPC network is global — only subnets are regional, genuinely unlike AWS's or Azure's own per-region network scope
Auto mode (one subnet per region, automatic) vs. Custom mode (manual, Google's own recommendation for production)
Real global routes and firewall rules — one ruleset applies consistently across every region the VPC touches
Cloud NAT — configured on a Cloud Router, no route table entry needed, matching Azure's own simplicity over AWS's explicit requirement
Full three-way firewall recap: AWS's split security-group/NACL model, Azure's single-but-regional NSG, GCP's single-and-global network-level rules