Run scale sets as zone-redundant for fault tolerance

Spreading a scale set across availability zones is one of the few resilience moves with an almost flat cost. The instances themselves cost the same whether they sit in one zone or three, so the headline compute bill barely moves. The genuine, bounded costs are narrow: a little extra headroom so the fleet can still serve when one zone's worth of instances is gone, and cross-zone data transfer for traffic that now crosses zone boundaries, which Microsoft bills at a low per-gigabyte rate. Everything else is engineering time to rebuild or reconfigure the set.

Frame each single-zone scale set as a line on the downtime risk register, not a tick on a reliability checklist. A scale set running a revenue-bearing API in one zone carries a far larger expected loss than an internal batch worker, yet both surface as the same Advisor recommendation. Map each set to the workload behind it and the revenue or operations that stop when it stops, then prioritise by the cost of the outage, not by the count of recommendations.

The arithmetic is one-sided. The resilience premium is a small, predictable amount of extra capacity plus some cross-zone transfer. The alternative is the cost of an outage when a zone fails: lost revenue per minute, SLA credits owed to your own customers, emergency engineering time and the reputational hit of being down while competitors stay up. For any workload that matters, the premium is a fraction of one avoided outage.

Priya is the finance partner supporting the platform team's reliability push. Advisor flags five scale sets for availability-zone deployment, and the instinct is not to wave through a blanket re-architecture budget; it is to ask what is actually behind each recommendation and what spreading it across zones really costs. Because the instances cost the same in one zone or three, the headline compute bill barely moves. The real, bounded costs are narrow: a little extra headroom so the fleet still serves when one zone's instances are gone, and cross-zone data transfer billed at a low per-gigabyte rate. Everything else is engineering time.

Priya asks the team to map each single-zone scale set to the workload behind it and the cost of that workload being down. One runs the checkout API, where every minute offline is lost orders. One is the customer-facing web frontend, already spread across three zones. The rest are internal batch and reporting workers where an hour of downtime is an inconvenience, not a loss. The list is reframed on the downtime risk register: the checkout set is a rebuild to schedule this sprint because its outage cost dwarfs the resilience premium, the batch workers are lower priority, and nothing here is a large spending decision. The finance pack reads: 'Making the revenue scale sets zone-redundant adds a small, bounded premium in spare capacity and cross-zone transfer; the downside we are buying out of is a full checkout outage the next time a zone fails.'

The cost model here is asymmetric in the way resilience spend usually is. Running a scale set zone-redundant costs a small, bounded premium: the instances are the same price, and the extra is spare headroom plus low-rate cross-zone transfer. Leaving a revenue workload single-zone creates a concentrated tail risk: low probability in any given month, but a severe, all-at-once loss when the zone does fail, and the probability across years of operation is not negligible.

The cost of an outage is well understood inside the business even when it is not on the cloud bill: lost revenue per minute of downtime, SLA credits owed to your own customers, emergency response time, and the slower-burning cost of customers who churn after being unable to transact. Against that, the resilience premium is a fraction of a single avoided outage. The finance role is to attach an expected downtime cost to each single-zone scale set, so the work is prioritised by the revenue or operations at risk, not by the order Advisor happens to list the recommendations.

A single-zone scale set is the kind of architecture choice that turns a localised Azure incident into your incident. When a zone has an outage, every workload pinned to it goes down together, and the report shows this as a quiet reliability recommendation rather than a flashing risk, right up until the day the zone actually fails.

The leadership question is not 'is the scale set running today?' It is 'when one zone has an outage, which of our workloads stay up?' The defensible end state is that production scale sets are spread across multiple availability zones by default, the few that genuinely cannot be are named and owned, and a new single-zone production set is hard to create by accident.

This is a cost decision, but a small and asymmetric one. Running a scale set zone-redundant adds a modest, bounded premium in spare capacity and cross-zone transfer. The cost of not doing it is paid all at once, on the worst possible day, in lost revenue and reputation. It is a governance decision about whether resilience is the default or something everyone has to remember to switch on.

After a regional incident briefly degraded one availability zone and a competitor in the same region went dark for the afternoon, the CEO asked the obvious question at the next review: if that zone had been ours, would checkout have stayed up? The honest answer at the time was no, because the checkout scale set ran every instance in a single zone, a default nobody had revisited since the early days.

The team's response was to stop treating zone redundancy as a per-scale-set recommendation and start treating it as the production default. They listed every scale set and how many zones it spanned, rebuilt the revenue-bearing ones as Flexible scale sets spread across three zones, and then set their Bicep templates and an Azure Policy audit so a new production scale set defaults to multiple zones rather than one. The next time a zone wobbled, checkout served straight through it on the remaining zones, and the only signal was a brief, automatic dip in spare capacity. That shift, from a single zone failure meaning a full outage to it meaning a graceful dip, is the one-line confidence signal this capability delivers, and it costs only a small, bounded premium to reach.

Nearly every avoidable cloud outage that traces back to a single datacentre event has the same root cause: a workload that could have been spread across zones was pinned to one. Running scale sets zone-redundant is the capability that makes that root cause structurally difficult, and a template-and-policy default makes a new single-zone production set hard to create by accident.

The cost of getting this wrong is large, sudden and visible to customers, while the cost of getting it right is a small, predictable premium on the compute bill. This is the kind of resilience trade where the downside of inaction is severe and concentrated and the cost of action is modest and spread out, which is exactly the trade leadership should be quickest to approve for any workload that carries revenue or reputation.