Configure AKS node pools across availability zones

The striking thing about zone resiliency in AKS is that Microsoft documents it as costing nothing extra: spreading nodes across availability zones does not incur an additional charge, because you are placing the same number of virtual machines you were already paying for into different datacentres rather than the same one. There is no per-zone fee and the Standard load balancer is already the default. So the cost question here is not really about Azure spend at all, it is about the cost of an outage versus the cost of the resilience that prevents it.

Frame a single-zone node pool as an item on the reliability risk register, not a line on the bill. The expected cost of leaving it single-zone is the probability of a zone outage multiplied by what an hour of that service being down actually costs you: lost transactions, breached customer commitments, the engineering scramble, and the reputational hit. Against that, the cost of action is a maintenance window to recreate node pools with zones set, because the number of zones on an existing node pool cannot be changed in place.

That is an unusually one-sided trade. The mitigation is engineering time and a planned migration, with no recurring Azure cost. The thing it buys down is the open-ended cost of an avoidable outage. The finance role is to make sure that trade is seen clearly and that the single-zone pools running revenue-bearing workloads are prioritised over the ones that do not matter if they blink.

Priya is the finance partner supporting the platform team's reliability push. The ask that lands is 'recreate the node pools so the cluster spans availability zones.' The instinct is to check what recurring cost that adds, and the answer is reassuring: Microsoft documents that spreading nodes across zones carries no extra charge, so the cluster will not cost more to run afterwards. The same virtual machines simply sit in different datacentres. The only spend is the engineering time for a planned migration, because the number of zones on an existing node pool cannot be changed in place: you create a new zone-spanning pool and move workloads onto it.

So the real number Priya wants is on the other side of the ledger: what does an hour of the checkout API being down actually cost? Once that figure is on the table, the framing writes itself. The system pool and the checkout app pool carry revenue and customer commitments, so a one-off maintenance window to make them zone-resilient is cheap insurance against an open-ended outage cost. A batch-processing pool that can tolerate a few hours down is lower priority. The finance pack reads: 'No recurring Azure cost; one planned migration window; we are buying down the cost of an avoidable outage on the services that earn, and deferring it on the ones that can wait.'

The cost model here is asymmetric. Making node pools zone-resilient adds nothing to the recurring Azure bill, because the same virtual machines simply sit in different datacentres, and the one-off cost is a planned migration window. Leaving a revenue-bearing pool single-zone creates an open-ended downtime exposure: the probability of a zone outage is low in any given month, but the cost when it lands, lost transactions, breached customer commitments, incident response, reputational damage, is large and falls all at once.

The finance role is to attach an expected outage cost to each single-zone pool. A pool running the checkout API has a high cost per hour of downtime and should be migrated first; a pool running an internal batch job that can slip a few hours does not, and can wait. The metric that belongs on the reliability review is not 'how many pools are single-zone' in the raw, it is that count weighted by what an hour of each pool being down would actually cost. That is what turns an engineering chore into a risk-ordered plan, and it makes clear that the spend question is a one-off migration, not a recurring charge.

Availability zones exist so that one datacentre catching fire, flooding or losing power does not take a whole region with it. The leadership question is simple: if one of those zones fails tomorrow, does our platform stay up, or does it go down with the zone? For an AKS cluster whose node pools all sit in a single zone, the honest answer is that it goes down, even though the rest of the region is healthy and even though Microsoft kept the control plane running.

This is not a cost decision. Microsoft documents that spreading nodes across zones carries no extra charge, and the zone-redundant load balancer is already the default. It is a reliability and engineering decision about whether the platform is built to survive a single zone failure or is one bad day in one datacentre away from an outage. The cost of getting it wrong is measured in downtime; the cost of getting it right is a planned maintenance window.

The defensible end state is that every node pool running a production workload is spread across the zones its region offers, the cluster is served by the zone-redundant Standard load balancer, and that this is verified rather than assumed. That is the difference between a platform that degrades gracefully when a zone is lost and one that simply stops.

After a peer in the same market lost an afternoon of trading to a single-zone outage and ended up explaining it to customers and the press, the CEO asked the obvious question at the next review: if that happened to us, would checkout stay up? The honest answer at the time was 'probably not for the node pools, because we never set them up to span zones, even though the control plane would have stayed running.'

The team's response was not to buy anything; it was to rebuild the node pools to span the three availability zones the region offers, confirm the cluster was served by the zone-redundant Standard load balancer it already had, and then prove it by draining a zone's worth of nodes and watching traffic carry on from the others. The next time the question came up, the answer had changed from 'probably not' to 'we tested it: when a zone goes, we lose a third of our capacity for a few minutes and the service keeps serving.' That shift, from hoping a zone failure never hits us to engineering it into a non-event, is the confidence signal this capability delivers, and Microsoft documents that it costs nothing extra in Azure spend to reach.

Almost every avoidable cloud outage that made the news came back to a single point of failure that nobody had removed because removing it felt optional until the day it failed. A single-zone AKS node pool is exactly that: a correlated failure waiting for one bad day in one datacentre. Spreading the pools across zones is the capability that takes that single point of failure off the board, and Microsoft documents it as costing nothing extra to do.

This is the rare reliability decision where the downside of inaction is a full, visible outage of a production service, and the cost of action is a planned maintenance window with no ongoing spend. When the trade is that one-sided, the leadership move is to set the expectation that production node pools span zones by default and that the platform's zone resilience is tested rather than assumed, so the next zone failure is a non-event instead of a headline.