Google Cloud VPC: Subnets, Routing, and the Global Network Model
Engineers coming to GCP from AWS or Azure hit one genuine surprise almost immediately: a GCP VPC is global, not regional. In AWS, a VPC lives in one region and you peer or transit-gateway your way between regions. In GCP, a single VPC spans every region on Earth by default — subnets within it are regional, but the VPC itself, its routing tables, and its firewall rules apply globally, without you provisioning any inter-region connectivity yourself. This isn’t a minor implementation detail; it changes how you think about network architecture from the first design decision.
Understanding this global model — along with subnet modes, routing behavior, and how firewall rules actually evaluate — is the foundation everything else in GCP networking builds on.
The Global VPC Model
┌─────────────────────────────────────────────────────────────┐│ VPC Network (global) ││ ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ Subnet │ │ Subnet │ │ Subnet │ ││ │ us-central1 │ │ europe-west1 │ │ asia-east1 │ ││ │ 10.0.1.0/24 │ │ 10.0.2.0/24 │ │ 10.0.3.0/24 │ ││ └──────────────┘ └──────────────┘ └──────────────┘ ││ ││ Single routing table, single firewall rule set, ││ applies across every subnet in every region │└─────────────────────────────────────────────────────────────┘A VM in the us-central1 subnet can communicate with a VM in the asia-east1 subnet using their internal IPs, over Google’s private backbone network, without any VPN, peering connection, or transit gateway — because they’re in the same VPC, and the VPC’s scope is the entire network, not a single region. This is a meaningfully simpler mental model than the regional-VPC-plus-peering-mesh most other clouds require for multi-region architectures.
Auto Mode vs Custom Mode Subnets
# Custom mode — you define every subnet explicitly (recommended for production)gcloud compute networks create my-vpc \ --subnet-mode=custom
gcloud compute networks subnets create app-subnet-us \ --network=my-vpc \ --region=us-central1 \ --range=10.0.1.0/24
gcloud compute networks subnets create app-subnet-eu \ --network=my-vpc \ --region=europe-west1 \ --range=10.0.2.0/24Auto mode creates one subnet per GCP region automatically, using a predetermined IP range scheme — convenient for quick experimentation, genuinely risky for production because you don’t control the IP ranges, and a growing organization frequently needs custom, non-overlapping ranges to support VPN, peering, or on-prem interconnection later. Custom mode requires you to explicitly create each subnet with a deliberately chosen range, which is more upfront work and the correct default for anything beyond a sandbox — retrofitting custom IP ranges onto an auto-mode network already in production use is a genuinely painful migration.
Routing: How Traffic Actually Finds Its Way
Every VPC has an implied default route sending traffic destined outside the VPC’s known ranges toward the internet gateway, plus subnet routes automatically created for each subnet’s range. Custom static routes and dynamic routes (via Cloud Router, using BGP) extend this for hybrid connectivity:
# A static route sending traffic for an on-prem range through a VPN tunnelgcloud compute routes create to-onprem \ --network=my-vpc \ --destination-range=192.168.0.0/16 \ --next-hop-vpn-tunnel=onprem-tunnel \ --next-hop-vpn-tunnel-region=us-central1Routes have priority values, and the most specific matching route wins regardless of priority — this longest-prefix-match behavior is standard networking logic but worth stating explicitly, since a common debugging mistake is assuming a lower-priority-number route always wins when actually a more specific destination range takes precedence first.
Firewall Rules: Implied Deny, Explicit Allow
GCP VPC firewall rules default to implicit deny for ingress and implicit allow for egress — nothing reaches a VM unless a rule explicitly permits it.
# Allow SSH only from a specific IP range, tagged to specific instancesgcloud compute firewall-rules create allow-ssh-from-office \ --network=my-vpc \ --direction=INGRESS \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=203.0.113.0/24 \ --target-tags=ssh-allowed
# Allow internal traffic between subnets on the same VPCgcloud compute firewall-rules create allow-internal \ --network=my-vpc \ --direction=INGRESS \ --action=ALLOW \ --rules=tcp,udp,icmp \ --source-ranges=10.0.0.0/16Firewall rules apply at the VPC level (not per-subnet) and use target tags or service accounts to scope which instances a rule actually affects — this network-wide-but-instance-scoped model is another consequence of the global VPC design, and it means a well-organized tagging or service-account scheme is what actually keeps firewall rules manageable as an environment grows past a handful of VMs.
Subnet IP Range Planning: The Decision That’s Hard to Undo
Before creating custom mode subnets, it’s worth sketching the full address space plan across every region and environment you expect to need — not just the ones you’re deploying today. A common regret is allocating a /24 per subnet without considering that a future VPN or Interconnect connection to on-prem infrastructure will need its own non-overlapping range, or that an acquired company’s existing network might collide with ranges chosen without that possibility in mind. Reserving generous, deliberately spaced ranges (leaving gaps between allocated blocks for future subnets) costs nothing upfront and saves a genuinely painful re-addressing exercise later.
How Firewall Rule Evaluation Actually Works
Firewall rules have a priority (lower number evaluates first) and each rule is either allow or deny — understanding the actual evaluation order matters because a common assumption (“deny rules always win”) is wrong.
The key detail: it’s whichever rule matches first in priority order, not “any deny rule anywhere overrides any allow rule.” A deny rule with priority 2000 does nothing to stop traffic that an allow rule with priority 1000 already matched and permitted, because evaluation stops at the first match. This trips up engineers who assume firewall rules behave like some other systems where the most restrictive matching rule always wins regardless of order — in GCP VPC, order is priority, and priority determines the winner.
Shared VPC: Centralizing Network Administration
For organizations with multiple teams and projects that need to share network infrastructure without each team managing its own isolated VPC, Shared VPC lets a central “host” project own the VPC and subnets, while individual “service” projects attach and deploy resources into those shared subnets.
Host Project (network team owns this) └── Shared VPC ├── Subnet A ──► Service Project 1 (team A's VMs) └── Subnet B ──► Service Project 2 (team B's VMs)This is the standard pattern for larger organizations — network architecture and IP address management stay centralized with a platform or network team, while individual application teams get project-level autonomy for everything else (their own IAM, their own billing visibility, their own resource lifecycle) without needing network admin privileges they don’t need and shouldn’t have.
Real-World Use Case: Multi-Region Application Without a VPN Mesh
A company running an application with compute resources in both us-central1 and europe-west1 for latency and redundancy reasons benefits directly from the global VPC model — resources in both regions live in the same VPC, communicate over internal IPs across Google’s backbone, and share one consistent firewall rule set, with no VPN tunnels or peering connections needed between the two regions. The same architecture on a cloud with regional-only VPCs would require explicit inter-region connectivity setup and a firewall policy synchronized (manually or via automation) across two separate network constructs — genuinely more operational surface area for the same end result.
Best Practices
- Always use custom mode subnets in production, choosing IP ranges deliberately with enough headroom for growth and non-overlap with any networks you might later connect to (on-prem, another cloud, an acquired company’s network).
- Use Shared VPC for any organization with more than a couple of teams needing network resources — centralizing IP address management early avoids painful re-addressing later.
- Scope firewall rules with tags or service accounts, never broad source ranges applied to “all instances.” A rule with no target scope applies to every VM in the VPC, which is rarely actually the intent.
- Reserve non-overlapping IP ranges deliberately across your entire address space plan, including ranges you might need for future VPN or Interconnect connectivity to on-prem — this is much easier to plan upfront than to fix after the fact.
- Document firewall rule priorities and their intent, especially once a network has more than a handful of rules — the “first match wins” evaluation model means rule ordering itself carries meaning that isn’t obvious from reading any single rule in isolation.
Common Mistakes
Starting with auto mode and discovering the IP range constraints only once production traffic depends on them. The migration path off auto mode is genuinely disruptive; choosing custom mode from the start avoids the problem entirely.
Treating firewall rules as a substitute for IAM. Network-level access control and identity-based access control solve different problems — a firewall rule permitting traffic from a range doesn’t mean every principal on that range should have equal access to what’s behind it.
Assuming subnet IP ranges can be resized freely later. Expanding a subnet’s range is possible under specific conditions but constrained — under-provisioning subnet size early is a common growth-pain source that’s avoidable with more generous initial CIDR allocation than seems necessary at launch.
Overlooking that firewall rule priority, not creation order, determines evaluation sequence. A rule created last but assigned a lower priority number evaluates before one created first with a higher number — reviewing actual priority values, not the order rules appear in a list, is the only reliable way to reason about behavior.
Frequently Asked Questions
Can a VPC span multiple GCP projects? Yes, via Shared VPC — a single VPC hosted in one project can be used by resources in multiple other projects, which is the standard pattern for centralized network administration across teams.
How is GCP VPC different from a traditional on-prem network? Conceptually similar (subnets, routing, firewall rules) but implemented on Google’s software-defined network layer rather than physical switches and routers — which is what enables the global-by-default behavior that has no clean physical-network equivalent.
Does traffic between VMs in the same VPC but different regions leave Google’s network? No — it travels over Google’s private backbone between regions, not the public internet, which is both faster and more secure than routing inter-region traffic externally.
What’s the difference between VPC Peering and Shared VPC? Peering connects two separate, independently-owned VPCs so resources in each can communicate; Shared VPC is one VPC used by multiple projects under centralized administration. Peering is for connecting distinct networks; Shared VPC is for one network with distributed usage.
Do firewall rules apply per subnet or across the whole VPC? Rules apply at the VPC level, scoped to specific instances via target tags or service accounts, not automatically confined to a single subnet. A rule without a target scope applies network-wide, which is a common source of unintentionally broad access.
Can I connect a GCP VPC directly to an on-prem data center? Yes, through Cloud VPN (over the public internet, encrypted) or Cloud Interconnect (a dedicated private connection) — both extend the VPC’s routing to include on-prem ranges, letting resources on both sides communicate using internal addressing.
Summary
The global-by-default VPC model is the single most important conceptual difference to internalize when architecting on GCP — it removes an entire category of inter-region connectivity work other clouds require, at the cost of needing to think about IP address planning across your entire global footprint from the start rather than region by region. Choosing custom mode subnets, planning IP ranges deliberately, and adopting Shared VPC once more than one team needs network resources are the three decisions that determine whether a GCP network architecture stays manageable as it scales, or becomes the kind of tangled configuration nobody on the team wants to be the one to touch.