GCP Architecture Series #63 — Subnet Design and Primary IP Ranges

Business Challenge

The last two posts settled what a VPC network is and which mode to create it in. Custom mode, the recommendation, leaves you holding the thing auto mode was doing on your behalf: an addressing plan. That plan looks like arithmetic, and the arithmetic is the easy part. What makes subnet design worth its own post is that two habits carried over from physical networking are actively unhelpful here, and the documentation contradicts both.

The first habit is planning inside RFC 1918 because that is what private addressing means. It is not the limit here. The second is cutting many small subnets to separate applications, which is how on-premises networks are built and is explicitly not the recommendation: group applications into fewer subnets with larger address ranges. Both habits produce a design that works and then runs out of room, which is the expensive failure, because of the third thing this post is about — most of what you decide about a subnet cannot be changed afterwards.

Architecture

A subnet is four decisions and one of them is adjustable. Taken in the order the platform makes them permanent, the design becomes much easier to get right.

The palette, in full

A subnet range is a regional internal address range — primary and secondary IPv4 address ranges are regional internal IPv4 addresses — and the set of blocks you may draw it from is wider than most planning documents assume.

Three traps in that palette

The extra space is real, and each of the two most useful additions carries a condition that is easy to discover late.

Class E is the largest single block on offer and the documentation attaches a warning rather than a restriction: so verify that your OS supports it before creating subnets that use this range. The platform will let you build the subnet; whether the guest operating system will accept an address from it is a separate question, and the answer varies. That makes it a range to pilot on the exact images you run, not one to adopt from a planning spreadsheet.

Privately used public addresses behave differently across peering, in a way that will look like a broken peer rather than a design choice. Google Cloud does not announce these routes to the internet and does not route traffic from the internet to them, which is the behaviour you want. But for VPC Network Peering, subnet routes for public IP addresses are not automatically exchanged: the subnet routes are automatically exported by default, but peer networks must be explicitly configured to import them in order to use them. Everything else about the peering works, and that one range is simply unreachable until somebody sets the import.

And one block to stay out of regardless of mode: avoid using IPv4 addresses from the 10.128.0.0/9 block for a subnet's primary or secondary IPv4 ranges. That is the auto mode block from the previous post, and keeping clear of it is what stops an automatically created subnet from landing on top of a range you chose.

Size: the bounds, and the recommendation inside them

The minimum primary or secondary range size is eight IPv4 addresses, so the longest subnet mask that you can use is /29. At the other end, the shortest subnet mask that you can use is /4, with a caveat that makes the headline number misleading: however, for most /4 IP address ranges, additional validations prevent you from creating a subnet that is this large. The practical ceiling is the recommendation — we recommend that you limit your maximum subnet size to /8.

The floor is tighter than it reads. Google Cloud uses the first two and last two IPv4 addresses in each subnet primary IPv4 address range to host the subnet, so a /29 yields four addresses you can actually use. That overhead is fixed per subnet rather than proportional, which is a second, quieter argument for fewer and larger subnets: every boundary you draw costs four addresses and gains you nothing in routing. Post #66 takes those reserved addresses properly.

The purposes, which are chosen once

Every subnet is created with a purpose, and the default is the one you will use almost always: this is the default subnet type, with a presentation quirk worth knowing before you go looking for it — the purpose is displayed as None in the Google Cloud console. A subnet showing no purpose is a regular subnet, not a misconfigured one.

The specialised purposes — Private Service Connect, proxy-only subnets for Envoy-based load balancers, Private NAT, peer migration — each belong to a feature this series has not reached yet, and each is a reservation rather than a place to put VMs. The one worth flagging now is the hybrid subnet, because it solves a migration problem that addressing alone cannot: hybrid Subnets logically extend to an on-premises or source network, letting you migrate workloads to Google Cloud without needing to change IP addresses. Unusually for subnet properties, it is not a one-way door — you can enable or disable hybrid routing for a subnet at any time.

Why This Architecture Holds Up

If subnet count does not affect routing and does not carry identity, the obvious question is why subnets exist at all beyond being a unit of address allocation. The documentation gives a precise answer, and it is the only sound reason to add one.

This is a genuinely useful test, because it is checkable. Before adding a subnet, name which of those settings needs to differ inside it. If the answer is none, the subnet is decoration — it costs four addresses, a name you can never change, and a row in every diagram, and it buys nothing the platform will act on. If the answer is "flow logs at a different sampling rate for this tier" or "these workloads need Cloud NAT and those must not have it", the split is doing real work.

There is a second, administrative reason that sits alongside it rather than contradicting it. Subnets are an IAM boundary in Shared VPC: the guidance is to grant the network user role at the subnet level. So a subnet can also be the unit at which you delegate use of address space to a team — which is a permissions decision, and reaches back to the thirty posts before this block rather than forward.

Uniqueness, overlap, and the peer you have not added yet

Within a network the rule is simple: each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block. The previous post established there is no supernet to fit inside, so uniqueness is the whole constraint.

The constraint that catches people reaches further than the network. You cannot create ranges overlapping any primary or secondary range of another subnet in the same network, or any IPv4 ranges of subnets in peered networks, and this is enforced rather than advised — Google Cloud prevents the creation of overlapping subnet ranges in these scenarios. Two more boundaries work the same way: subnet IPv4 ranges cannot conflict with destinations for static routes, and the reason sits underneath all of it, which is that subnet routes, and therefore subnet IP ranges, must have the most specific IP ranges by definition.

Read forward, that means today's addressing choices decide which networks you will be allowed to peer with later. A range that merely looks untidy now is not a problem; a range that duplicates something in a network you will want to reach in a year is one, and it will present as a refusal at peering time rather than as a warning at creation time.

Naming, since it is permanent

Names are regionally scoped rather than globally unique: within a project, subnets in the same region must have unique names, so the same name may legitimately recur in different regions — which is what makes a region-agnostic convention like prod-app workable across a global network. One collision rule to know: a subnet cannot have the same name as a VPC network unless it is a member of that network. And since the name cannot be changed, the convention has to be decided before the first subnet rather than after the tenth.

Key Architecture Decisions

Ordering these by reversibility rather than by the sequence the console asks for them makes the weight land in the right places.

The one to look at today

Take the subnets in one region and, for each, write down which of the four per-subnet features differs from its neighbour. Subnets with no differing setting are candidates for having been one subnet — you cannot merge them now, but the count tells you whether the next environment should be built the same way. Then check the smallest range against its current occupancy, because that is where the expansion-only rule will first become a problem, and the cheapest moment to widen a range is before anything depends on the addresses next to it.

Closing Thought

What strikes me assembling this is how much of conventional subnetting was carrying information rather than doing work. In a physical network the mask is load-bearing: it bounds a broadcast domain, it is where a routing decision happens, and the address itself is a usable proxy for what a machine is. Encoding the organisation into the addressing was not a stylistic choice, it was how the network functioned.

Here the fabric already provides full reachability, routing does not consult the subnet count, and identity lives in service accounts and tags. So the address has stopped meaning anything and a subnet has become an allocation unit with four settings attached. The design question changes shape accordingly: not how finely to divide, but how few boundaries you can get away with and how much room to leave inside each one. The habit worth carrying forward from the last three posts is the same each time — the names are familiar, the mechanisms underneath them are not, and it is the intuitions rather than the terminology that need rechecking.

Official Google Cloud Reference

• Subnets
• Best practices and reference architectures for VPC design
• VPC networks
• Create and modify VPC networks
• VPC quotas and limits
• Alias IP ranges