Business Challenge
The previous post left subnets as allocation units with four settings attached, and noted that a subnet boundary no longer carries routing or identity. This post takes the second range a subnet can hold, and it starts with a sentence that removes the reason most people think they need one. Use of alias IP ranges does not require secondary subnet ranges. These secondary subnet ranges merely provide an organizational tool.
That is the documentation, unhedged. Alias IP ranges work perfectly well out of the primary range — you can also allocate alias IP ranges from that primary range, or you can add a secondary range to the subnet and allocate alias IP ranges from the secondary range. So a secondary range is a choice, not a dependency, and the useful question is what the organisation buys. It buys exactly one thing, that thing is genuinely valuable, and there is a documented gap that can stop it working while looking as though it does.
You do not. Alias ranges come from the primary CIDR range or from a secondary CIDR range of that same subnet, and the only hard scoping rule is that both must belong to one subnet: the primary IP address and the alias IP range of the interface must be allocated from CIDR ranges configured as part of the same subnet. Starting without a secondary range is a legitimate design, not a shortcut.
Correct approachDecide the secondary range on the basis of whether you want a separate address space to write firewall rules against. If you do not, allocate aliases from the primary range and carry one range instead of two. If you do, the next two cards are the ones that matter.
They do not. Alias traffic is filtered as a destination perfectly well — all ingress or egress traffic, including traffic for Alias IP ranges, is evaluated by a VPC firewall rule for a matching target tag or target service account. But in the other direction there is an exclusion: alias IP ranges are not included when you specify sources for an ingress firewall rule using source tags or source service accounts. A rule admitting traffic from a tagged set of VMs does not admit the alias traffic those VMs send.
Correct approachWhere alias traffic is the source, write the rule with source IP ranges — which the separate secondary range makes clean, and which is the strongest practical argument for having one. The failure mode is quiet: the rule exists, reads correctly, matches the VMs, and never matches the pods.
That is not available. You can't reserve an internal IP address from a secondary subnet range. The documented route to a reserved alias address goes the other way: you can reserve an internal IP address from a primary subnet range and use it as a /32 alias IP range.
Correct approachNotice what that does to the design before relying on it. The reason for the secondary range was to hold service addresses apart from infrastructure addresses; a reserved service address has to come out of the infrastructure range, so it sits on the wrong side of the boundary and the firewall rules written against the secondary range will not cover it. Plan reserved addresses as a deliberate exception, with their own rule, rather than discovering the asymmetry when the first one is needed.
Architecture
There are two separate mechanisms here and they are easy to conflate. Alias IP is a way of giving one network interface many internal addresses. A secondary range is a way of drawing those addresses from a different block. The first is the feature; the second is a filing decision about the first.
What alias IP is for
The purpose is density on one interface: you can configure multiple internal IP addresses, representing containers or applications hosted in a VM, without having to define a separate network interface. The documentation's worked example makes the shape concrete — a primary range of 10.1.0.0/16 with a secondary CIDR range 10.2.0.0/20 is configured as part of a subnet, the VM taking its own address from the primary range and a /24 alias range from the secondary for the containers it hosts.
Three things come with it that are worth more than the addressing convenience. The platform handles routing: Google Cloud automatically installs Virtual Private Cloud (VPC) network routes for primary and alias IP ranges for the subnet of the primary network interface, so your container orchestrator does not need to specify VPC network connectivity for these routes. The ranges are reachable without any route work of yours — alias IP ranges are routable within the Google Cloud virtual network without requiring additional routes, and you do not have to add a route for every IP alias and you do not have to take route quotas into account. And they reach further than the VPC: alias IP addresses can be announced by Cloud Router to an on-premises network connected via VPN or Interconnect.
Alias IP keeps a guarantee the obvious alternative has to give up. With alias ranges configured, anti-spoofing checks are performed against traffic, ensuring that traffic exiting VMs uses VM IP addresses and pod IP addresses as source addresses, and those checks verify that VMs do not send traffic with arbitrary source IP addresses. Google states the comparison directly: use of static routes for container networking would be a less secure approach compared to IP aliasing because it would require anti-spoofing checks to be disabled on container host VMs — and anti-spoofing checks are disabled when IP forwarding is enabled. The choice is not between two routing styles. It is between keeping source-address validation and switching it off fleet-wide.
What the secondary range adds
Given that aliases work from the primary range, the documented benefit of a second one is a single idea with a single consequence. By allocating from a range separate from the range used for primary IP addresses, you can separate infrastructure (VMs) from services (containers), and therefore you can set up firewall controls for VM alias IP addresses separately from the firewall controls for a VM and its own primary address.
That lands precisely on the gap the previous post identified. #63 established that a subnet boundary carries no routing and no identity, so splitting subnets to express policy writes the policy in a medium that does not enforce it. A secondary range is the exception: firewall rules do match on IP ranges, so a separate block genuinely is a policy surface. The pattern the documentation builds from it is a routing asymmetry — container addresses reachable over a VPN while VM primary addresses are not — implemented as two firewall rules, one denying the primary range and one permitting the secondary. With Cloud Router in place, if Cloud Router is configured, it will automatically advertise the secondary subnet range 172.16.0.0/20.
So the honest summary of a secondary range is: no new capability, one new boundary. Whether that is worth a second block depends entirely on whether you intend to write rules against it.
The constraints on where an alias range may come from
The scoping rules are tighter than they first appear, and they constrain the subnet design from #63 rather than the alias configuration.
| Rule | Consequence for design |
|---|---|
| The primary IP address must be allocated from the CIDR primary range. | The VM address is never an alias; the two roles are fixed. |
| The alias IP must be from the same subnet resource that provides the IP address for the primary network interface. | You cannot borrow a range from a neighbouring subnet. Service address space has to be attached to the subnet the VMs live in. |
| Alias IP ranges are optional and they are not automatically added. | Nothing appears by default; the instance template or create call has to ask. |
| An alias IP range can be fully specified or auto-allocated by specifying the netmask. | You can hand the allocation to the platform, which is what makes fleet-wide templates practical. |
| Because all subnets in a VPC network share a single default gateway, all alias IP addresses within an interface share the same default gateway as the primary IP address. | No per-range gateway, so no per-range routing inside the guest. |
| Alias IP addresses can be configured in the VM OS, which is typically Linux or Windows, manually or by using scripts. | The platform routes to the range; making the guest use it is still your job. |
The second row is the one that reaches backwards. A secondary range belongs to a subnet, and aliases must come from the subnet hosting the interface — so the decision about which workloads share a subnet, taken under #63's "fewer subnets, larger ranges" guidance, also decides which workloads can share a service address space. That is a per-subnet feature in exactly the sense #63 described, and it belongs on the list of reasons to draw a subnet boundary.
Mode and the default, again
Auto mode narrows this too: the automatically-created subnets in auto mode VPC networks each have a primary CIDR range, but no secondary range. You can add one, or add a subnet of your own as long as none of its ranges overlap with 10.128.0.0/9 — the same block #62 and #63 both said to stay out of. In custom mode the position is simply stated: one primary CIDR range is mandatory. You can optionally create secondary CIDR ranges.
Why This Architecture Holds Up
Three costs, and none of them is address space. The first was the third challenge card: no reservations from a secondary range. The second is name resolution.
Google Cloud does not associate alias IP addresses on the primary interface with the host name. Internal DNS covers the primary address of the primary interface and nothing else, so every alias address is reachable by address only unless you configure DNS yourself. For containers behind an orchestrator that is usually irrelevant, because the orchestrator has its own service discovery. For a hand-rolled deployment putting a second application on an alias address, it is the detail that makes it feel broken.
This quota counts the number of alias IP ranges without regard to each range's size (subnet mask), and the documentation spells out what that means: an individual /24 range is a single alias IP range and an individual /23 range is also a single alias IP range. The ceiling is maximum number of alias IP ranges per network interface 150. So 150 ranges of /24 is 38,400 addresses on one interface, while 150 ranges of /32 is 150 — same quota, two orders of magnitude apart.
That has a direct bearing on a pattern the same page recommends. For mixed workloads, the migratable containers can be configured using /32 ranges, making it easy to migrate them individually, with larger ranges for the ones that stay put. The advice is sound and the granularity is genuinely useful — but since every /32 costs a whole range against both the per-interface limit and the network-wide ALIASES_PER_NETWORK_GLOBAL quota, the pattern has a scale at which it stops working. Mobility per container is paid for in quota, not in addresses, and that is the opposite of how address planning usually trades.
The two accounting details worth knowing
Secondary ranges are generous on addresses and counted strictly on ranges. On the generous side, Google Cloud lets you use all addresses in secondary IPv4 ranges — whereas Google Cloud uses the first two and last two IPv4 addresses in each subnet primary IPv4 address range to host the subnet. A secondary range loses nothing to platform overhead, which is the one place the economics favour the second block.
On the strict side, there are two separate ceilings. Per subnet, maximum number of secondary IP ranges per subnet 170. Per network, the subnet-range quota SUBNET_RANGES_PER_NETWORK includes primary IPv4 address ranges, secondary IPv4 address ranges, and IPv6 address ranges — so a secondary range is not free at the network level either; it competes with every other range for the same budget. And alias usage has a quota of its own, the total number of alias IP ranges used by VM network interfaces (NICs) in the VPC network.
One flexibility the primary range does not have
Secondary ranges are the only part of a subnet's addressing that is genuinely revisable. The primary range can only grow; a secondary range can be taken back: you can remove and replace a subnet's secondary IPv4 address range only if no instances are using that range. The condition is real but reachable — drain the workloads and the block returns. After three posts of one-way doors, that is worth naming: of everything a subnet carries, this is the piece a mistake is cheapest in.
Key Architecture Decisions
The decision is narrower than it looks, because the capability does not depend on it.
| If this is true | Choose | Because |
|---|---|---|
| Services need firewall or advertisement rules distinct from their hosts | A secondary range | It is the only thing the second block actually buys, and it is a real policy surface. |
| Containers must be reachable from on-premises but hosts must not | A secondary range | Cloud Router advertises the secondary range; two firewall rules split the two blocks. |
| Aliases are an addressing convenience with no distinct policy | Allocate from the primary range | No capability is lost, and you carry one range instead of two. |
| Alias traffic is the source in a firewall rule | Source IP ranges, never source tags | Alias ranges are excluded from source tag and source service account matching. |
| A service address must be reserved | Reserve from the primary range, as a /32 alias |
Reservation from a secondary range is not possible. Treat it as a documented exception to the boundary. |
| Many short-lived, individually migratable workloads | Count the ranges before choosing /32 |
150 per interface regardless of size, so per-workload mobility is bought in quota. |
The one to look at today
Find every ingress firewall rule that identifies its source by network tag or service account, and ask whether any of the traffic it is meant to admit originates from an alias IP range. Those are the rules that read correctly and under-match, and no validation will flag them — the rule is valid, the tags exist, the VMs match. Then count alias ranges per interface on the busiest workload and compare with 150, because that ceiling is reached by range count and nothing in an addressing plan makes it visible.
Closing Thought
The sentence that organises this whole topic is the one that sounds least important: secondary ranges merely provide an organizational tool. Read quickly it is a disclaimer. Read against the previous post it is the specification. #63 found that the things addresses used to carry — routing boundaries, identity, segmentation — have all moved elsewhere, leaving the subnet as an allocation unit. A secondary range is the remaining case where organising by address still changes what the platform does, because firewall rules and route advertisements both match on ranges.
Which makes the two exceptions worth more attention than their placement in the documentation suggests. The source-tag exclusion and the reservation asymmetry both puncture the boundary in the same direction: they let traffic or addresses that belong to the service side behave as though they were on the infrastructure side. Neither is an error, both are documented in a single line, and both are invisible in the artifact you would inspect — a firewall rule that looks right, an address that resolves and routes. Three posts into addressing, the pattern holding up best is that the mechanisms are sound and the edges are where the reading has to be literal.
#65 takes the irreversible half of this: expanding a subnet, and what cannot be undone — why the primary range only ever grows, and what that forecloses.
Comments