skip to content

Your network's address range was drawn in week one and is nearly full - what can you realistically still change?

level: middleimportance: should knowfreq 55%

answer

  1. unallocated space is the only cheap lever
  2. replace, do not widen, a live prefix
  3. an additional range as the escape hatch
  4. rolling replacement, tier by tier
  5. addresses recorded outside the network

basics

~20 s

Mostly what is not deployed yet. A prefix carrying live workloads is not widened in place on mainstream platforms, so the realistic move is to add unallocated space or a new subnet and migrate tier by tier - a rolling replacement, not an edit.

solid answer

~40 s

Three levers remain, in increasing cost. First, anything still unallocated: free space inside the network range can be cut into new subnets immediately. Second, extending the network with an additional range where the platform supports it, then placing new subnets there - this is the usual escape hatch. Third, replacing a full subnet by building its successor from spare space and moving workloads over in a rolling replacement, then deleting the old one. What you cannot cheaply do is renumber a live estate: every address that leaked outside the network - into an allowlist, a static configuration, a partner's expectation, a long-lived connection - has to be found and changed, and that discovery, not the instances, is what makes the work expensive.

go deeper

for a junior

Remember that the address range is decided early and is hard to change later, and that reserving spare space up front costs nothing.

for a middle

Explain which changes remain - unallocated space, an additional range, a replacement subnet - and why a live prefix is replaced rather than widened.

for a senior

Lead with the discovery problem: the migration of instances is mechanical, the hunt for addresses recorded outside the network is the schedule.

for a principal

Own the standard that prevents it - a range sized far past the plan, fixed prefix sizes per tier, and a rule that consumers reference names rather than addresses.

## Why the first plan is sticky An address plan is drawn in week one, when the team is smallest and knows least, and it is then written into every interface the estate creates. The range itself is cheap and the **consequences of it are not**: a workload's address is how everything else names it, and mainstream platforms treat an allocated prefix as fixed once it carries interfaces. Platforms differ at the edges - some will let you grow the network by attaching an additional range, some will let you widen a prefix that is still empty - but none of them renumber a running estate for you. So the honest answer to `can we resize it` is: **not the part that is in use**. ## What is effectively immutable - **A prefix that currently holds interfaces.** It is not widened underneath running workloads. - **A subnet's zone**, where subnets are zonal. That is fixed at creation. - **The addresses themselves**, in the sense that changing one means replacing the interface that holds it, which usually means replacing the workload. - **Everything downstream that recorded an address** - which is the part teams forget. ## The moves that remain 1. **Allocate from unallocated space.** If the plan reserved room, new subnets come out of it today, at no cost beyond the change itself. This is why reserving space you do not need is the cheapest insurance in the whole exercise: unassigned address space inside your own range costs nothing to hold. 2. **Extend the network with an additional range** where the platform allows it, then cut new subnets there. The new range must not overlap anything the estate may ever need to join to, which is the constraint that bites organisations that allocated carelessly. 3. **Build the successor subnet and migrate.** Create the replacement out of spare space, deploy the tier into it, shift traffic, drain the old subnet, then delete it. This is a rolling replacement of every workload in the tier, done tier by tier so one failure does not take the estate. 4. **Reclaim what is stranded.** Interfaces left behind by deleted workloads, oversized tiers, environments nobody uses - freeing them buys time, though rarely enough of it. ## What the change actually costs | Change | Realistic? | What it costs | |---|---|---| | Cut a new subnet from reserved space | Yes | A change review | | Attach an additional range to the network | Usually, platform-dependent | A change review plus a non-overlap check | | Widen an empty prefix | Sometimes, platform-dependent | Little - if it is genuinely empty | | Widen a prefix carrying workloads | No | Not offered; plan the replacement instead | | Renumber a live tier | Yes, expensively | A rolling replacement plus every recorded address | | Renumber the whole estate | Technically yes | The project nobody budgets for | ## The part that is not about instances Replacing instances is mechanical. The expensive half is that addresses escape the network: - **Allowlists elsewhere** - a partner, a data provider, another team's boundary filter - keyed on your source addresses. - **Static configuration** that names an address instead of a name, in the places nobody greps. - **Long-lived connections and caches** that hold a resolved address well past a name-resolution change. - **Documentation and runbooks** that a responder will follow at three in the morning. None of these are discoverable from the platform's own view of the network, which is why a renumbering project is mostly an archaeology project. When you are asked for the plan, say that the discovery is the schedule risk and that the migration is the easy part. ## How to not be here - **Reserve deliberately.** Allocate the network range far larger than the plan needs and leave the surplus unassigned and recorded as such. - **Standardise prefix sizes** per tier and per zone, so a team that doubles does not need a bespoke decision. - **Size for the surge**, not the steady state: rolling replacements and failover both peak above the normal instance count. - **Prefer names to addresses** everywhere a consumer could record one, so that a future migration has fewer archaeological digs in it. - **Write the plan down where the estate can see it**, so the next team's allocation does not collide with the room you reserved. The interview answer in one line: what is unallocated is free to change, what is deployed is replaced rather than edited, and what is expensive is everything outside the network that wrote an address down.

  • Why is reserving address space you do not need the cheapest insurance in the plan?
    Because unassigned space inside your own private range holds no resources and generates no charge, while the alternative - renumbering a live estate - costs a rolling replacement of every workload plus the search for every address recorded outside the network. You are trading something free for something expensive.
  • The platform lets you attach an additional range to the network. Does that solve the problem?
    It buys room for new subnets, which is usually enough. It does not renumber anything that already exists, and the new range must avoid overlapping anything the estate may ever need to join to - so a careless second choice simply postpones the same conversation.
  • What makes the discovery phase of a renumbering riskier than the migration itself?
    Addresses that escaped the network are invisible from inside it: partner allowlists, static configuration, cached resolutions, runbooks. The platform can tell you which interfaces hold which addresses, but nothing tells you who else wrote them down, so the schedule risk lives in that search.

saying these in an interview costs you the question

  • Expects to widen a prefix under running workloads
  • Treats renumbering as a configuration edit rather than a replacement
  • Forgets addresses recorded in allowlists outside the network
  • Allocates the smallest range that fits today's fleet
  • Assumes the provider can move an estate onto a bigger range