Business Challenge
Thirty posts asked who may act. This one starts a block asking where packets may go. The structural fact to get right first is the one that determines every address-planning decision afterwards: VPC networks, including their associated routes and firewall rules, are global resources, and subnets are regional resources. A network spans every region at once, and holds no addresses itself.
There is no network CIDR to choose. The network is a global container; the addresses live entirely in subnets, and the only constraint is uniqueness: each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block. Nothing requires them to be contiguous or drawn from a common supernet.
Correct approachPlan ranges per subnet, with whatever supernet discipline your own routing and on-premises connectivity need. That discipline is yours to impose; the platform does not require it.
You can grow but never shrink. After you create a subnet, the primary IPv4 range for the subnet can be expanded but not replaced or shrunk. Secondary ranges are more forgiving — you can remove and replace a secondary IPv4 address range only if no instances are using that range.
Correct approachSize primary ranges for the growth you expect and leave adjacent space free, because expansion is the only correction available.
They do not sit between anything. Rules are global resources, but rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM. There is no inline device at a subnet edge to hang inspection off.
Correct approachDesign observation at the instance, and reach for Packet Mirroring or a load balancer if you genuinely need a traffic-inspection point. Do not assume a subnet boundary is one.
That check will fail on a perfectly healthy network. Virtual gateways do not respond to ICMP traffic or decrement IP TTL headers, so the gateway answers no ping and never appears in a traceroute. The documentation says it outright: tools that ping the gateway IP address as a connectivity test must be configured so that they do not treat that silence as a fault.
Correct approachHealth-check a real endpoint you control. Treat traceroute output with a missing first hop as normal rather than as evidence.
Architecture
A Virtual Private Cloud (VPC) network is a virtual version of a physical network that is implemented inside of Google’s production network using Andromeda. The useful way to hold it is as two layers with a sharp division of responsibility.
| Scope | Resources | What that buys you |
|---|---|---|
| Global | The VPC network, its routes, its firewall rules — they are not associated with any particular region or zone | One rule set and one routing table cover every region; adding a region adds no policy surface |
| Regional | Subnets, and the IPv4 and IPv6 ranges they define | Addresses stay local to where the workload runs, and are chosen independently per region |
Two pieces of vocabulary, because both cause confusion in review. The terms subnet and subnetwork are synonymous, used interchangeably across the console, the CLI and the API. And more importantly: a subnet is not the same thing as a (VPC) network. They are separate resource types, with separate scopes and separate permissions.
The consequence worth internalising: there is no supernet
Because the network holds no range, subnet ranges are independent of one another. The documentation’s own worked example demonstrates it rather than merely allowing it: subnet1 is defined as 10.240.0.0/24 in the us-west1 region and subnet2 is defined as 192.168.1.0/24 in the us-east1 region. Two unrelated private ranges, from different RFC 1918 blocks, in one network, presented as the normal case.
That is genuinely freeing and quietly dangerous. Freeing, because you can give a new region whatever range is actually available in your wider address plan without renumbering anything. Dangerous, because nothing stops an estate accumulating a scatter of unrelated ranges that cannot be summarised into a handful of routes for on-premises connectivity. The platform enforces uniqueness; it does not enforce aggregability, and aggregability is what your routers will want later.
Range rules, including one asymmetry
- Bounds. The minimum primary or secondary range size is eight IPv4 addresses. In other words, the longest subnet mask that you can use is /29. At the other end, the shortest subnet mask that you can use is /4 — but additional validation blocks most ranges that large, and the advice is explicit: we recommend that you limit your maximum subnet size to /8.
- Growth is one-way. Primary ranges expand, never shrink or move.
- Reserved addresses are asymmetric. Google Cloud uses the first two and last two IPv4 addresses in each subnet primary IPv4 address range to host the subnet, while Google Cloud lets you use all addresses in secondary IPv4 ranges.
That last point is worth a moment because the usable-address arithmetic differs by range type. In a primary range four addresses go: the network address, the default gateway, the last address as broadcast, and the second-to-last, which is reserved by Google Cloud for potential future use. In a secondary range, none are reserved. So a /29 primary range yields four usable addresses, and a /29 secondary range yields eight — which matters most where secondary ranges carry the densest consumers, as they do for container networking.
Stack types and purposes, briefly
A subnet declares a stack type — IPv4-only, dual-stack, or IPv6-only — and a single VPC network can contain any combination of these subnets. It also declares a purpose. The default is a regular subnet, where this is the default subnet type and the purpose is displayed as None in the Google Cloud console, which is a small naming inconsistency worth knowing before you go looking for the word "regular" in the UI.
One purpose variant is worth flagging now because it solves a migration problem people otherwise design around: hybrid subnets, configured with overlapping CIDR routes allowed, which logically extend to an on-premises or source network, letting you migrate workloads to Google Cloud without needing to change IP addresses. Lifting a workload without renumbering it is usually the expensive part of a migration, and this is the mechanism for not doing that.
Why This Architecture Holds Up
The global scope is not a trivia item; it changes the shape of several things you would otherwise expect to repeat per region.
Because routes and firewall rules are properties of the network rather than of a region, adding a region to an existing network adds a subnet and nothing else. The policy surface does not grow: the same rules already apply, and instances in the new subnet can reach instances in existing subnets by internal address immediately, subject to those rules. For a platform team that is a real reduction in work, and it is the main practical argument for keeping a single network across regions rather than one per region.
The flip side is blast radius, and it is the thing to weigh deliberately. A firewall rule mistake is global by construction; there is no regional boundary to contain it. The same property that removes per-region duplication removes per-region isolation, so the isolation you want has to come from somewhere else — separate networks, or the project and folder boundaries from #60.
This is the detail that most changes how you design observation. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM. There is no inline appliance between two subnets, because there is no device at a subnet edge at all — the subnet is an address range and a region, not a hop. Anything that assumes a transit point to tap, filter or count at will not find one. Combined with the gateway not answering ICMP or decrementing TTL, a network that is working correctly produces exactly the symptoms — silent gateway, no intermediate hop, no inspection point — that in a physical network would mean something was broken.
Three constraints that are easier to learn now than later
No broadcast or multicast. VPC networks do not support broadcast or multicast addresses within the network. Software that discovers peers by broadcast will not work unmodified, and that includes a long tail of clustering and licensing agents.
Overlay networks are unsupported for help. Running your own overlay to get multicast or custom encapsulation is possible, and Cloud Customer Care does not provide configuration or troubleshooting assistance for overlay networks. That is a reasonable boundary, stated plainly, and worth knowing before the overlay becomes load-bearing.
Legacy networks are a dead end. Legacy networks can no longer be created and are not recommended for production because they lack the advanced features. If you inherit one, converting it is the path, not working around it.
One thing I am deferring
A new project normally starts with a default network that has a subnet in every region, and auto mode VPC networks always have a subnet in every region. Whether to keep that or build a custom-mode network with only the subnets you chose is the whole of tomorrow’s post, so I will leave it there rather than half-answer it here. For today the relevant point is only that the subnet-per-region behaviour is a property of a mode you can decline, not of VPC networks as such.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Planning the network range | There is none to plan | Only subnet ranges exist, and they need only be unique. |
| Keeping ranges summarisable | Impose your own supernet discipline | The platform enforces uniqueness, not aggregability. |
| Sizing a primary range | For expected growth, with adjacent space free | Primary ranges expand but never shrink or move. |
| Usable-address arithmetic | Subtract four for primary, nothing for secondary | Secondary ranges reserve no addresses. |
| Maximum subnet size | Cap at /8 | It is the documented recommendation despite /4 being the limit. |
| Traffic inspection points | Design them explicitly | Rules run on the VM; a subnet edge is not a hop. |
| Connectivity health checks | Target a real endpoint, not the gateway | The gateway answers no ICMP and decrements no TTL. |
| Regional isolation | Separate networks or projects | Firewall rules and routes are global, so a mistake is too. |
| Broadcast-dependent software | Replace the discovery mechanism | Broadcast and multicast are unsupported in the network. |
| Migrating without renumbering | A hybrid subnet | It extends logically to the source network. |
The one to look at today
List the subnet ranges in one network and ask whether they summarise. If they fall inside two or three supernets, your on-premises routing and future peering will be straightforward. If they are a scatter of unrelated blocks — which is entirely legal and exactly what the documentation’s own example shows — then you have a routing-table problem waiting rather than an addressing problem, and the cheapest moment to notice is before the next region is added.
Closing Thought
The design is coherent and, on balance, generous. A global network with regional subnets means one firewall policy and one routing table rather than a set per region, and adding a region is an addressing decision rather than a policy project. The absence of a network-level range removes a planning step that exists mostly to be regretted later. Both are good choices.
What this block will have to keep in view is that the model removes some familiar landmarks along with the duplication. There is no supernet to reason from, no device at a subnet edge, and no gateway that answers when you ask it whether it is there. None of that is a fault; all of it means the mental model from a physical network transfers imperfectly, and the places it fails are exactly the places where a working system looks broken. Thirty posts on IAM ended on the value of reading the page rather than the name. The first networking post suggests the same habit, for a different reason: here the names are accurate and it is the intuitions that need checking.
#62 takes the decision this post deferred: auto mode versus custom mode networks — what the default actually creates, and what it costs to keep.
Comments