Business Challenge
Three posts have now deferred something to this one. #61 noted the asymmetry, #63 called the primary range the only forgiving decision in a subnet, and #64 contrasted it with secondary ranges, which can be taken back. The rule itself is one line: the primary IPv4 range for the subnet can be expanded but not replaced or shrunk.
So expansion is the escape valve, and the obvious reading is that it makes under-sizing survivable. It does, and the operation is better behaved than you would expect — during expansion, traffic within the subnet is not interrupted. What makes it worth a post is that the risk is not in the operation. It is in two things the operation does not do, one of which is a security gap and neither of which produces an error.
They do not. The documentation is explicit: if you have VPC firewall rules or firewall policy rules that use the original IPv4 address range as a source or destination, add additional firewall rules to apply the same rules to the extended range. A rule written against 10.1.0.0/24 does not begin matching 10.1.1.0/24 because the subnet is now a /23. The subnet grows; the policy stays exactly where it was.
Treat an expansion as a two-part change: widen the range, then widen every rule that named the old one, in the same change. The failure mode is the worst shape available — an allow rule that no longer covers the new addresses breaks traffic loudly and gets fixed, while a deny rule that no longer covers them fails open and silently.
There is no back. Expanding the primary IPv4 range of a subnet cannot be undone, and you cannot shrink the primary IPv4 range of a subnet. The addresses the range grew into belong to it from then on, and because each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block, every address it absorbed is an address no other subnet in the network can ever use.
Correct approachFollow the documented advice, which is the opposite of the usual instinct: expand primary IPv4 ranges conservatively; you can always expand them again. One generous expansion feels efficient and is the more expensive choice, because it claims adjacent space you have not yet decided how to use.
Two exceptions. You can't expand subnets that are used exclusively for load balancer proxies — a proxy-only subnet is sized once and that is final. And a subnet that auto mode created carries a ceiling: the broadest prefix (subnet mask) you can use is /16, which applies to such a subnet in an auto mode network or in a custom mode VPC network that was previously an auto mode VPC network, because anything broader would conflict with the primary IPv4 ranges of the other automatically created subnets.
Correct approach
Check the subnet's purpose and its provenance before planning capacity around expansion. For proxy-only subnets, size at creation with the growth already in it. For anything inherited from auto mode, treat /16 as the hard limit it is — the mode decision from #62 is still binding three posts later.
Architecture
Mechanically this is the simplest operation in the block. You are moving one number in one direction.
You can expand the primary IPv4 range of an existing subnet by modifying its subnet mask, setting the prefix length to a smaller number. In the console you enter a new, broader CIDR block in the IP address range field; on the command line you use the subnets expand-ip-range command, which takes the new prefix length rather than a new CIDR — a small design detail that makes the one-directional nature of the operation explicit in the interface. There is no shrink command because there is no shrink.
The runtime behaviour is unalarming. Expanding the primary IPv4 range of a subnet can take several minutes to complete, and traffic is not interrupted while it does. That is genuinely reassuring and it is also what makes the gap below easy to miss: nothing about running the operation suggests that work remains afterwards.
What the expansion must satisfy
The proposed range must follow the rules listed in the IPv4 subnet range limitations — the same set #63 covered, which now function as a list of reasons an expansion can be refused rather than reasons a creation can be. The ones that bite on expansion specifically are the collision rules, because a growing range moves into space it did not previously touch.
| Constraint | Why it matters more on expansion than on creation |
|---|---|
| Any primary or secondary range of another subnet in the same network, or any IPv4 ranges of subnets in peered networks. | At creation you pick a free block. On expansion the direction is forced — you grow into whatever is adjacent, and a neighbour there blocks you. |
| Google Cloud prevents the creation of overlapping subnet ranges in these scenarios. | You get a refusal, not a conflict. Good, but it means the expansion you planned may simply be unavailable. |
| Subnet IPv4 ranges cannot conflict with destinations for static routes. | A static route added since the subnet was created can block its growth, from outside the addressing plan. |
| The shortest subnet mask that you can use is /4, with we recommend that you limit your maximum subnet size to /8. | The real ceiling is advisory, not the headline number — and /16 for anything auto mode created. |
| Subnet routes, and therefore subnet IP ranges, must have the most specific IP ranges by definition. | The subnet route widens with the range, which is how the new addresses become reachable without any route work. |
The first row is the one that reframes the whole operation. Expansion is not allocation from a pool; it is annexation of the adjacent block. Which neighbours exist, in this network and in every network peered to it, decides whether the expansion is even possible — and that set grows over time without reference to your plan.
Why This Architecture Holds Up
The documentation states the general case before listing instances of it: if you expand the primary IPv4 range of a subnet, you might need to modify other configurations that are assuming this IP address range. "Might need to" is doing a lot of work in that sentence. Two specific cases follow, and the first is a security control.
If you have VPC firewall rules or firewall policy rules that use the original IPv4 address range as a source or destination, add additional firewall rules to apply the same rules to the extended range. Note what is being asked: not edit the rules, add rules. The original rule keeps matching the original range, and the addresses added by the expansion match nothing it says.
This is the same class of problem #64 ended on, arriving from a different direction. There the gap was that alias ranges are excluded from source tag matching; here it is that a range reference does not track the range it was copied from. In both cases the artifact you would inspect looks correct: the rule is valid, the CIDR it names is real, and it governs exactly what it governed yesterday. What changed is the set of addresses that exists.
The asymmetry of consequences is what makes it worth planning around rather than remembering. An allow rule that has not been widened produces unreachable workloads on the new addresses — disruptive, obvious, fixed within the hour. A deny rule that has not been widened produces new addresses that are not denied. Nothing breaks, nothing alerts, and the subnet is quietly more permissive than its documented policy.
The second case is narrower but worth naming because it is easy to be caught by: if a Google Kubernetes Engine cluster uses the subnet, you must add the expanded IP range to the control plane authorized networks list. Expanding the range the nodes live in does not authorise the new part of it to reach the control plane.
Why "conservatively" is the right advice, and why it feels wrong
The sentence that deserves the most thought is the one that sounds like boilerplate: expand primary IPv4 ranges conservatively; you can always expand them again. Every instinct trained on irreversible operations says the opposite — if you only get one shot, take a big one. The advice inverts that, and it is correct, because of what the previous section established.
Expansion consumes adjacent space permanently. The addresses absorbed become unavailable to every other subnet in the network and incompatible with any peered network that uses them. So the cost of over-expanding is not paid in the expanded subnet, which is fine; it is paid by future subnets and future peers, which do not exist yet and therefore cannot object. Under-expanding costs one more operation later — an operation that is repeatable, non-disruptive and takes minutes. The asymmetry runs entirely one way.
That resolves what looks like a contradiction with #63, which argued for oversizing the range deliberately. Both are right, and the difference is when. At creation, space is unclaimed: a generous range costs nothing because nothing is adjacent to it yet and you are choosing where to put it. At expansion, space is contested: the direction is forced and the neighbours are real. Generosity is free before and expensive afterwards.
Consider IPv4 address space in any networks to which your VPC network is or will be connected before you expand a subnet and its primary IPv4 range. That is the only forward-looking instruction in the procedure, and the phrase or will be is the whole point — the overlap that stops a peering in a year is created by an expansion today, and the expansion will succeed.
The size floor, and what an expansion is actually buying
One piece of arithmetic worth having explicit, because it is the thing people are usually trying to fix. The minimum primary or secondary range size is eight IPv4 addresses, so the longest subnet mask that you can use is /29; and Google Cloud uses the first two and last two IPv4 addresses in each subnet primary IPv4 address range to host the subnet. That overhead is four addresses per subnet, fixed, and it does not grow when the range does.
So expanding a /24 to a /23 takes usable addresses from 252 to 508 — the 256 new addresses arrive whole, because the four reserved ones were already paid for. Expansion is the one operation in this area with no marginal overhead, which is a genuine argument for doing it rather than adding a second subnet to the same workload. #66 takes those four reserved addresses on their own terms.
Key Architecture Decisions
| Situation | Decision | Because |
|---|---|---|
| Subnet is running out of addresses | Expand by one step, not to the limit | Repeatable and non-disruptive; over-expanding permanently claims the neighbours' space. |
| Any expansion at all | Widen the firewall rules in the same change | Rules do not follow the range, and a stale deny rule fails open. |
| Subnet hosts a GKE cluster | Add the new range to control plane authorized networks | Authorisation is by range and does not widen either. |
| Proxy-only subnet | Size correctly at creation | It cannot be expanded at all. |
| Subnet came from auto mode | Plan within /16 |
Broader collides with the other automatically created subnets. |
| Peering or hybrid connectivity is possible later | Check the other side before expanding | The expansion succeeds now and forecloses the peering later. |
| Growth is uncertain and the workload is new | Size generously at creation instead | Space is unclaimed before anything is adjacent to it. |
The one to look at today
Take any subnet that has been expanded and compare its current range against every firewall rule and firewall policy rule that names a CIDR. If a rule still carries the pre-expansion prefix, you have found the gap — and the ones to look at first are the deny rules, because the allow rules would already have complained. Then, separately, list the ranges immediately adjacent to your largest subnets and ask what they are reserved for, because that is the space the next expansion will take whether or not anyone decided it should.
Closing Thought
The interesting thing about this operation is how far the risk sits from where the warnings are. The caution in the documentation is about irreversibility, and irreversibility is real but manageable — you cannot shrink a range, and almost nobody needs to. The expensive consequences are elsewhere: in the adjacent space you claimed from subnets and peers that did not exist yet, and in the firewall rules that kept doing precisely what they said while the thing they described changed underneath them.
Both have the same shape, and it is the shape this whole block keeps producing. The platform does one thing cleanly and completely, and the surrounding configuration that referenced the old state is left for you. #62's conversion preserved every subnet and left every implicit command to be rewritten. #64's secondary range gave a policy surface and excluded it from source-tag matching. Here the range widens with no interruption and the rules governing it do not move. None of these is a defect, all are documented in a sentence, and every one of them is invisible in the resource you would think to check. Five posts in, the habit that keeps paying is to ask not what the operation does but what still points at what it used to be.
#66 takes the four addresses this post kept deferring: the addresses reserved in every subnet — which ones, why, and the one range where none are reserved at all.
Comments