VPC
A VPC is a global resource. Its subnets are regional and hold the IP ranges. A VM lives in one subnet, so it lives in one region.
VPC (global) → Subnets (regional) → VMs (zonal)
VPC structure
Network types
GCP has three kinds of VPC network. Default is just an auto-mode network created for you; use custom for anything real, auto only for quick demos.
Custom-mode VPCs support IPv6; a dual-stack VM gets both an IPv4 and an IPv6 address.
The pool 10.128.0.0/9 is the whole block auto-mode draws from; each region's subnet is a /20 slice of it (e.g. 10.128.0.0/20, 10.132.0.0/20, …), assigned for you. Because every auto-mode network uses this same 10.128.0.0/9, it collides with on-prem or peer VPCs on the same range. Custom mode exists so you pick your own ranges and avoid the overlap.
You can expand a subnet's primary range (widen the CIDR, e.g. /24 → /20) with no downtime - existing VMs keep running. The rules:
- Cannot overlap another subnet (or a peered network's range).
- IP range must be a unique, valid CIDR block.
- The new range must contain the old one (fall within valid IP ranges).
- Can expand but not shrink.
- Auto mode subnets can be expanded from
/20up to/16. - Avoid oversized subnets - a large range wastes address space and constrains future expansion/peering. Plan ranges to avoid overlap up front.
- Auto-mode block:
10.128.0.0/9 - Every subnet silently reserves 4 IPs in each primary range (network, default gateway, and 2 reserved).
- Default quota is 15 VPC networks per project (requestable). Peerings and routes are also per-project quotas - request increases, don't design around defaults.
Subnetworks cross zones
A subnet is regional, not zonal. Its single IP range covers every zone in the region, so VMs in different zones (Zone A, Zone B) both draw internal IPs from the same subnet.
Notice the VMs start at .2, not .0. Every subnet reserves 4 IP addresses from its primary range (network, gateway, second-to-last, broadcast), so .2 and .3 are the first usable ones - which is why the two VMs land there. See which 4 addresses + usable-host math.
Routes
Every VPC gets system-generated routes: one to the default internet gateway (0.0.0.0/0) and one for every subnet. You add custom static routes (e.g. next-hop to a NAT/VPN appliance) or let Cloud Router inject dynamic routes via BGP.
Network isolation
Each VPC is an isolated system. What decides connectivity is the network, not the region.
The diagram lays out a project as a grid: five networks (columns) across many regions (rows), with four VMs - A, B, C, D - dropped into cells. It shows the one rule that matters: VMs on the same network reach each other over internal IPs regardless of region, while VMs on different networks must fall back to external IPs even if they sit in the same region.
- A and B are both in Network #1, so they talk over internal IPs even though they are in different regions.
- C and D are in different networks, so they must use external IPs even though they are in the same region.
When C and D fall back to external IPs, the traffic doesn't actually leave onto the public internet - it stays on Google's backbone. "External" here means the only address they can use to find each other is public, not that packets are exposed. Put both VMs on the same network (or peer the networks) to use internal IPs instead.
Connectivity
Two VPCs are isolated - a VM in one cannot reach a VM in another over its internal IP, even in the same region (they can only find each other via external IPs). There are exactly three ways to unblock internal-IP reachability:
- Shared VPC - service projects share one host project's network.
- VPC Peering - connect two independent VPCs (any org); non-transitive.
- Cloud VPN / Interconnect - tunnel to on-prem or another cloud/org.
Shared VPC and VPC Peering keep traffic inside Google Cloud and are easy to confuse; Cloud VPN / Interconnect is the tunnel you reach for when one side isn't a Google Cloud VPC. The two intra-cloud options compare directly:
| Shared VPC | VPC Peering | |
|---|---|---|
| Scope | Within one organization | Any two VPCs (even different orgs) |
| Model | Host project owns the network, service projects attach and use its subnets | Two VPCs stay separate, exchange routes |
| Admin | Central network team controls subnets/firewall | Each side administers its own VPC |
| Billing | Per service project | Per VPC |
The sharpest difference is the admin model. Shared VPC is centralized - security and network policy live in one designated VPC under a Shared VPC Admin. Peering is decentralized - each VPC stays under its own admin group with its own global firewall and routing tables.
Shared VPC
A host project owns one or more Shared VPC networks; you attach service projects to it, and eligible resources in those service projects place their instances directly into the host's subnets. Org admins delegate day-to-day work (creating/managing instances) to Service Project Admins while keeping central control of subnets, routes, and firewalls in the host project.
A project that participates is either a host project or a service project. One that participates in neither is a standalone project, and an unshared network living in a standalone (or service) project is a standalone VPC network - it shares nothing with anyone.
VPC Peering
VPC Peering gives private RFC 1918 connectivity between two VPCs whether they sit in the same or different organizations. Each network keeps its own firewall rules and routing tables. Both sides must peer: the producer admin peers producer→consumer and the consumer admin peers consumer→producer; only when both connections exist does the session go Active and routes get exchanged.
Shared VPC is the only option for centralizing a network within one org across projects. VPC Peering is the only option for the other two extremes: connecting VPCs in different organizations, or connecting two VPCs in the same project. The networks don't have to be in the same project - but with peering they can be.
If A peers with B and B peers with C, A cannot reach C. There is no transitive routing. You must create a direct A↔C peering (full mesh) or use a hub design with Shared VPC / an appliance. This is a favorite exam trap.
- Peering is non-transitive.
- Peered VPCs must have non-overlapping subnet ranges.
- Both sides must create the peering - it activates only when both are configured.
- Internal traffic stays on Google's network (no public IPs, no egress internet charges between peers).
Historically you'd bridge two VPCs with external IPs or a VPN. VPC Peering avoids all three of their drawbacks - the added network latency, the security exposure of public addressing, and the cost of egress/VPN - because peered traffic stays private on Google's network.
Cloud VPN / Interconnect
The third path bridges a VPC to on-prem, another cloud, or another organization - an encrypted tunnel over the internet (Cloud VPN) or a private physical link (Dedicated / Partner Interconnect). It's the only option when one side isn't a Google Cloud VPC. Covered in depth under Hybrid connectivity.