skip to content

Your platform puts each subnet in one availability zone - what does a three-zone service need in its address plan?

level: middleimportance: must knowfreq 62%

answer

  1. the subnet is the placement handle
  2. one per zone, per tier
  3. symmetric prefixes, or a hidden cap
  4. headroom for a lost zone's instances
  5. platforms differ: zonal against regional

basics

~20 s

At least one subnet per zone per tier, each with its own non-overlapping prefix. A zonal subnet cannot span zones, so the platform can only place instances in the zones you gave it subnets in, and each prefix needs its own growth headroom.

solid answer

~40 s

Where a subnet lives in a single availability zone, the subnet is your unit of placement: the platform can only put a workload in a zone where you allocated a subnet for that tier. So a three-zone service needs three subnets per tier, each with its own prefix out of the network range. Size them symmetrically - if you expect the surviving zones to absorb the instances of a lost zone, every prefix needs headroom beyond its own steady-state share. Record which zone each prefix belongs to, because address exhaustion will then be a per-zone event rather than a network-wide one, and some platform components ask for a subnet in every zone they serve.

code

yaml · 24 lines
yaml
network:
  range: 10.20.0.0/16
  subnets:
    - name: app-zone-a
      zone: a
      range: 10.20.0.0/20
    - name: app-zone-b
      zone: b
      range: 10.20.16.0/20
    - name: app-zone-c
      zone: c
      range: 10.20.32.0/20
    - name: data-zone-a
      zone: a
      range: 10.20.48.0/22
    - name: data-zone-b
      zone: b
      range: 10.20.52.0/22
    - name: data-zone-c
      zone: c
      range: 10.20.56.0/22
  unallocated:
    - range: 10.20.64.0/18
      note: reserved for growth, deliberately unassigned

go deeper

for a junior

Know that a zone is a failure domain inside a region and that a zonal subnet lives in exactly one of them, so several subnets are needed to spread a service.

for a middle

Explain why the subnet is the placement unit, why prefixes are sized symmetrically, and how the plan differs where a platform makes subnets regional.

for a senior

Show the failover arithmetic: survivors carry more than their share, so headroom is part of the prefix, and a missing subnet caps spread silently.

for a principal

Set the standard other teams allocate against - a fixed prefix size per zone per tier, so no team's plan silently caps its own spread or the estate's growth.

## What `zonal` means for a subnet An **availability zone** is a failure domain inside a region. When a platform makes subnets zonal, each subnet you create is pinned to exactly one of those zones for its whole life: its prefix cannot stretch across zones, and the subnet cannot later be moved to a different zone. A workload placed in that subnet is therefore placed in that zone. **The subnet becomes your placement handle.** The consequence is blunt: the platform can only spread a service across the zones where you gave it a subnet for that tier. Draw two subnets and ask for three-zone spread, and you get two-zone spread. ## What a three-zone service needs 1. **One subnet per zone, per tier.** A three-zone service with a front tier and a data tier needs six subnets, not two, and each one carves a distinct prefix out of the network range. 2. **Symmetric prefixes.** Give the three subnets of a tier the same prefix size unless you have a reason not to. Asymmetry quietly becomes a capacity cap in the smallest zone, and it shows up only at peak. 3. **Headroom past the steady-state share.** If losing one zone means the other two carry the whole service, each of them needs enough free addresses for roughly half as many instances again. Sizing each subnet for exactly one third of the fleet guarantees the failure you were spreading to survive. 4. **A record of which zone each prefix belongs to.** Exhaustion is per subnet, so it will hit one zone at a time; a plan that does not say which prefix is which zone makes that symptom hard to read. 5. **Space for the components you did not think of.** Managed components you place inside the network get an interface in each zone they serve, and they draw from the same prefixes. ## Where subnets are regional instead Platforms genuinely differ here, and an interviewer may well be on the other design. Where a subnet is **regional**, one subnet spans the zones of a region and the platform chooses which zone each workload lands in. That changes the address plan more than it changes the architecture: - you allocate **fewer, larger prefixes** - often one per tier rather than one per tier per zone; - you no longer see per-zone address accounting, because all zones draw from the same pool; - placement across zones is expressed as a property of the workload rather than as a choice of subnet; - exhaustion becomes a single network-wide event instead of a one-zone symptom. Neither model is better; they force different plans, and confidently describing only the one you happen to have used is the usual stumble. ## The two models side by side | | Zonal subnet | Regional subnet | |---|---|---| | What you allocate | One prefix per zone per tier | One prefix per tier | | Who picks the zone | You, by choosing the subnet | The platform, from the workload's spread setting | | Where exhaustion appears | In one zone, while others scale fine | Across the whole tier at once | | Sizing unit | The zone's share plus failover headroom | The tier's whole fleet plus headroom | | Cost of a mistake | A missing subnet quietly caps spread | An undersized prefix caps the whole tier | ## Traps worth naming in the answer - **A subnet cannot change zone.** Correcting a wrong zone means creating a new subnet and replacing the workloads in it, not editing a field. - **Zone identifiers are not a coordination key.** On some platforms the zone label you see is an alias, and there is no guarantee that the same label means the same physical zone in another account, so do not treat it as a shared name across teams. - **An even spread needs an even number of subnets per tier.** Three subnets and a fleet that does not divide by three leaves one zone heavier, which matters when that is the zone you lose. - **Deployment surge lands per zone.** A rolling replacement runs old and new instances together inside the same zonal prefix, so the peak address demand is above the steady-state count. The short interview answer is: the subnet is the placement unit, so the address plan has one symmetric, headroom-carrying prefix per zone per tier - and if your platform makes subnets regional instead, say so and describe how the plan collapses.

  • You allocated subnets in two zones but asked the platform for a three-zone spread. What happens?
    You get two-zone spread. The platform places workloads only where a subnet exists for that tier, so the third zone is simply never used. The request is not rejected in any obvious way, which is why the gap usually surfaces during a zone failure rather than at deploy time.
  • Why size each zonal subnet for more than a third of the fleet?
    Because the point of spreading is surviving the loss of a zone, and the survivors then run more instances than their steady-state share. A prefix sized for exactly one third has no room for those extra instances, so the failover fails on addresses rather than on capacity.
  • A subnet was created in the wrong zone. How do you correct it?
    You do not: a subnet's zone is fixed for its life. Create a new subnet in the intended zone out of unallocated space, move the workloads onto it in a rolling replacement, then delete the old one once nothing holds an address in it.

saying these in an interview costs you the question

  • Thinks one subnet stretches across every zone in the region
  • Sizes each zonal subnet for exactly its steady-state share
  • Believes a subnet can be moved to another zone later
  • Assumes the platform will spill into a zone with no subnet
  • Treats zone identifiers as a name shared across accounts