Spread virtual machines across availability zones

Spreading a workload across zones is not free, and that is the honest starting point. Going from one virtual machine to a zone-redundant pair or a scale set roughly doubles the compute you run for that workload, because you are paying for the redundant capacity that sits ready in the other zone. Data egress between zones can also carry a small charge. So the question finance owns is not 'is this free' the way some controls are. It is 'is this workload worth keeping up through a zone fault, and is the cost of the redundancy smaller than the cost of the outage it prevents.'

For most genuine production workloads the arithmetic is one-sided in favour of resilience, but not for all of them. A batch job that can simply rerun tomorrow, a dev box, an internal tool nobody misses for an hour: these do not justify doubling their footprint, and Advisor flagging them is not a reason to spend. The finance role is to separate the workloads where an hour of downtime has a real, quantifiable cost, lost revenue, missed SLAs, idle staff, from the ones where it does not, and to fund zone redundancy only for the former.

Frame each Advisor finding against the cost of the outage it guards against, not against a target of zero findings. A single-instance virtual machine running the checkout path of a revenue system is a high-priority spend. The same finding on a scratch machine is one to dismiss with a note. The metric that matters is downtime cost avoided per pound of redundancy, not the raw count of flagged machines.

Priya is the finance partner supporting the platform team's reliability review. Advisor flags six single-instance machines under 'Use Availability zones for better resiliency and availability', and the instinct from the platform side is to make all six zone-redundant. The finance instinct is different: each one that becomes zone-redundant roughly doubles its compute cost, because you pay for the standby capacity in the other zone, so blanket approval would double the bill for that whole tier whether or not the workload earns it.

Priya asks the team to attach a downtime cost to each flagged machine. Two of them, the payments service and the checkout path, lose real revenue for every minute they are down and clearly justify the redundancy: the cost of a second zone is a fraction of the cost of an hour of lost transactions. Two are internal tools where an hour of downtime is an annoyance, not a loss, and two are scratch and batch machines that can simply be restarted. The finance pack reads: 'Fund zone redundancy for the two revenue-path workloads, where the doubled compute cost is far smaller than the outage it prevents; dismiss the four where downtime has no quantifiable cost, with a note on the record.' The number that matters is downtime cost avoided per pound of redundancy, not the count of findings closed.

The cost model here is the mirror image of a free control. Zone redundancy costs real money, roughly doubling the compute for each protected workload, so it has to be justified workload by workload against the cost of the outage it prevents. That makes it a textbook expected-value decision: probability of a zone fault, times the cost of the downtime it would cause, against the known, recurring cost of the redundancy.

For a revenue-path workload the maths usually favours redundancy comfortably, because an hour of lost transactions dwarfs the marginal cost of a second zone over a year. For a batch job or an internal tool it usually does not, and spending there would be waste dressed up as reliability. The finance role is to attach a downtime cost to each flagged workload so the spend goes where it earns its return, and to record the workloads where the deliberate answer is to accept the single-instance risk rather than pay to remove it.

Availability zones are the difference between a local datacentre problem being an Azure incident you read about and an outage your customers feel. A workload running on one virtual machine in one zone has a single point of failure that you do not control and cannot prevent: when that zone has an event, the service is down until Azure restores it.

The leadership question is not 'how many reliability findings do we have?' It is 'which of our workloads cannot survive a zone fault, and have we decided on purpose which of those we are willing to leave that way?' The defensible end state is that every workload critical to the business runs across multiple zones, and the single-instance machines that remain are a deliberate, documented choice rather than an accident waiting for a bad day.

This one is a genuine cost decision, unlike many reliability controls. Zone redundancy roughly doubles the compute cost of a workload. So the leadership move is to set the bar: name the workloads where downtime is unacceptable, fund redundancy for those, and accept the single-instance risk everywhere else with eyes open.

After a regional cloud incident took a competitor's checkout offline for most of a morning, the CEO asked the obvious question at the next review: if one of our datacentres has a bad day, what goes down with it? The honest answer at the time was that the payments and checkout services each ran on a single virtual machine in a single zone, so the answer was 'those would, completely, until Azure brought the zone back', and nobody had decided that on purpose.

The team's response was to stop treating reliability as a per-machine cleanup and start treating it as a deliberate tiering decision. They inventoried which workloads were single-instance, named the two that the business genuinely could not afford to lose, and moved those onto a Virtual Machine Scale Set spread across three zones behind a load balancer. The rest stayed single-instance on purpose, recorded as accepted risk. The next time the CEO asked the question, the answer had changed from 'the revenue path would go down and we did not realise' to 'the revenue path now survives any single zone fault, and the machines that would not are ones we have consciously decided are not worth the redundancy.' That shift, from accidental single points of failure to a deliberate, costed tiering of what survives a zone fault, is the confidence signal this capability delivers.

Most major cloud outages that customers actually feel trace back to a workload that had no path to survive the failure underneath it. Spreading critical workloads across availability zones is the capability that removes that single point of failure for the services the business cannot afford to lose, and it does so within a single region, without moving data across borders.

Unlike many reliability controls, this one costs real money, so it is a genuine prioritisation decision rather than an automatic yes. The leadership job is to decide which workloads must survive a zone fault and fund redundancy for exactly those, accepting the single-instance risk elsewhere as a conscious, documented choice. That is the difference between resilience by design and resilience by luck.