Deploy across multiple Availability Zones

Multi-AZ is one of the few resilience capabilities that carries a real, recurring cost rather than being free to enable. A Multi-AZ RDS instance roughly doubles its compute and storage charge because you pay to run the standby, a Multi-AZ FSx file system runs a second file server, and spanning compute or databases across zones adds cross-AZ data-transfer charges. So this is not a blanket on switch: it is a tiering decision about which workloads are important enough to insure.

Frame each failing control by what depends on it, not by the control count. A single-AZ database behind checkout carries a far higher expected loss than a single-AZ dev sandbox, yet both show up as one red finding. Map the failures to the business workload behind them and prioritise by exposure. Production and customer-facing systems almost always justify the premium; dev, test and disposable environments usually do not, and should be recorded as deliberate single-AZ exceptions rather than left as silent gaps.

The premium is unusually clean to model because it is structural, not variable: roughly 2x the per-resource charge plus cross-AZ transfer for chatty workloads. Against that sits the documented cost of a zone-outage incident, lost revenue per hour, SLA credits, incident response and recovery. For revenue-critical systems the maths is one-sided, which makes the spend easy to approve once it is framed as insurance with a known premium.

Priya is the finance partner supporting the platform team ahead of a SOC 2 audit. The security report shows a dozen high-availability failures across RDS, Auto Scaling, ELB and OpenSearch in three older accounts. Unlike most security findings, this one has a real recurring price tag, so she does not approve a blanket fix. She asks the tiering question first: which of these single-AZ resources actually carry business risk if a zone goes down, and which are dev sandboxes where an outage is an inconvenience.

The team pulls the resource list with environment tags. Two production databases sit behind checkout and authentication with no standby, an OpenSearch domain backs the customer search experience, and the rest are dev and staging instances. Priya prices the premium precisely because it is structural, not variable: roughly 2x the per-resource charge for the production database standbys plus a small amount of cross-AZ transfer she can estimate from existing CloudWatch network metrics. Her finance pack frames it as insurance with a known premium: 'The multi-AZ premium on the two production databases and the search domain is a small, predictable annual line against the open-ended cost of a multi-hour zone outage of checkout. The dev resources stay single-AZ by design and are recorded as deliberate exceptions, because paying the premium on them would be waste.'

The cost model here is unusually clean to forecast because the premium is structural, not variable. Multi-AZ on a database roughly doubles its charge, multi-AZ on a file system runs a second server, and spanning compute across zones adds cross-AZ transfer you can estimate from existing CloudWatch network metrics. So for any workload you can price the resilience premium precisely up front, rather than discovering it later on the bill.

Against that predictable premium sits an open-ended tail risk. A single-AZ production resource is a quantifiable exposure: the cost of a zone-outage incident is the revenue lost during a multi-hour recovery plus SLA credits and reputational damage, against an annual premium that is typically a small fraction of that. The finance role is to attach expected loss to each failing production resource so the work is prioritised by risk, to record every intentional single-AZ exception with an owner, and to budget the premium on critical systems as a deliberate resilience line rather than letting it surface as an unexplained bill increase.

Cloud workloads run inside a single datacentre unless you configure them across multiple. If that one datacentre has an event, a single-AZ database, fleet or file share goes dark and recovery is a manual, multi-hour effort, often with data loss. The report shows this as a scatter of separate findings across databases, compute, storage and networking, but the underlying question is one: which of our production systems are one datacentre outage away from going down?

Unlike most security findings this one is partly a cost decision, because multi-AZ carries a recurring premium on the resources that need it. So the leadership question is not "are we compliant today?" It is "is every production-critical workload resilient by design, with the few intentional single-AZ exceptions on the record?" The defensible end state is multi-AZ by default for production, deliberate exceptions for low-stakes systems, and a guardrail so resilience cannot drift back to one zone unnoticed.

This is the rare class of control where the trade is explicit: a predictable, bounded premium against an open-ended outage risk. For the systems that matter, that is cheap insurance, and it should be a decision leadership makes deliberately rather than one inherited from whoever clicked through a launch wizard.

When a large Availability Zone disruption hit a major Region, the leadership team watched a competitor's checkout go dark for hours while their own customer-facing systems flickered for a minute and carried on. At the next review the CEO asked the question the outage had made concrete: if a datacentre went down for us, which of our systems would survive, and which would need a manual scramble?

The honest answer at the time was a mix, because resilience had been inherited from whoever clicked through each launch wizard rather than decided deliberately. The team's response was to make resilience an explicit per-workload tier. Production and revenue-critical systems were spanned across at least two zones, with automatic failover in about a minute; dev and disposable resources were left single-AZ on purpose and recorded as deliberate exceptions. The default in the infrastructure-as-code modules was changed so new production resources arrive resilient, backed by Config rules so the posture cannot drift. The next time the question came up, the answer was no longer a shrug but a tracked list: every production-critical workload multi-AZ, every exception on the record. That is the difference between resilience by policy and resilience by accident, and the premium that buys it is frequently less than the cost of a single multi-hour outage of the service it protects.

Single-AZ exposure is a direct proxy for a question every executive eventually gets asked: if a datacentre goes down, do our critical systems stay up? For each single-AZ production workload the honest answer is no, recovery would be a manual scramble. Multi-AZ makes the answer yes, with automatic failover in about a minute, and the high-availability controls turn that abstract question into a concrete, tracked list.

What makes this a leadership item rather than a pure engineering one is the cost trade-off: multi-AZ carries a recurring premium, so it cannot be a blanket mandate. The healthy signal is not zero findings; it is that every production-critical workload is resilient by design and every exception is a recorded, deliberate decision. That is the difference between resilience by policy and resilience by accident.