VPC — a global network with regional subnets, the two subnet modes, the implied firewall rules, and non-transitive peering
The networking fact that most changes a cross-cloud design: a Google Cloud VPC network is a global resource and only its subnets are regional. Plus auto against custom subnet mode, the implied deny on ingress and allow on egress, the default network's own rules, non-transitive peering, and Shared VPC in one line.
markdownreferencev1NRQV-H34Ystage: designtrust: officialfamily: networkingservice: vpcinterface: anyVPCglobal networkregional subnetauto modecustom modefirewall rulesimplied deny ingressimplied allow egressdefault-allow-internalVPC peeringnon-transitiveshared VPC10.128.0.0/9
VPC
1. The fact to internalise first
VPC networks are "global resources"; "subnets are regional resources."
Nothing else in Google Cloud networking makes sense until that is settled, and it is the single biggest structural difference from AWS and Azure, where the network object itself is regional. Consequences:
- one VPC network can span every region, with one subnet per region inside it;
- routing between two regions' subnets in the same VPC is internal by default — there is no peering,
gateway or transit object between them;
- a multi-region Google Cloud estate often has one network where the same estate on AWS or Azure has one
per region.
For a migration estimate this is a re-modelling, not a count conversion. guides/parity/networking.md §2
sets out what to do with a per-region network inventory arriving from either of the other clouds.
2. Two subnet modes
| Mode | What it does |
|---|---|
| auto mode | creates one subnet per region automatically, from predefined IPv4 ranges within 10.128.0.0/9 |
| custom mode | you create every subnet, choosing its range and region |
Use custom mode for anything you will connect to something else. Auto mode's predefined ranges are the
same predefined ranges everyone else's auto-mode network has, which is how two networks end up unable to peer.
The 10.128.0.0/9 range is also a real constraint on an on-premises address plan.
3. Firewall rules and the two implied rules
Rules apply to "packets sent to and from VM instances". The implied defaults:
| Direction | Implied rule |
|---|---|
| ingress | implied deny |
| egress | implied allow |
So a new network drops unsolicited inbound traffic and permits all outbound. Egress is open until you close it — that is the opposite of some on-premises postures and it is where data-exfiltration controls have to be added deliberately (see also VPC Service Controls, not covered in this release).
The default network additionally ships default-allow-internal, which permits instance-to-instance
traffic. A hardened design does not keep the default network.
4. Peering is not transitive
VPC Network Peering connects exactly two networks. A peered to B and B peered to C does not give A to C.
The hub-and-spoke topology that an engineer draws by habit therefore does not route on peering alone, and the
answers are Network Connectivity Center, a routing appliance, or
Private Service Connect (reference/networking/private-service-connect.md) for service access
specifically.
This is the commonest Google Cloud networking design error, and it is also true of AWS VPC peering — so it transfers as a shared property rather than a surprise, unless the source design used an AWS Transit Gateway or an Azure Virtual WAN, in which case there is a real gap to fill.
5. Shared VPC, in one line
The network lives in a host project, and authorized principals in other service projects create resources using its subnets. One network team, many application projects, no peering.
That is the shape most Google Cloud landing zones use, and it is the one that makes the global-VPC property pay: a single Shared VPC can serve every project in an organization, in every region.
Next: reference/networking/cloud-load-balancing.md, reference/networking/cloud-nat.md,
reference/networking/errors.md.