Set up disaster recovery with Azure Site Recovery

Disaster recovery is one of the few resilience controls with a real, recurring Azure cost, so it deserves an honest cost-versus-cost comparison rather than a reflexive yes or no. The spend side is bounded and predictable: a per-instance Site Recovery licence charge for each protected VM, the storage to hold the replicated disks in the secondary region, a small cache storage account, and the cross-region egress for ongoing replication. Crucially, you are not paying for a second running fleet. The recovery VMs only consume compute when you actually fail over or run a drill.

The other side of the comparison is the cost of an outage. For a revenue-generating or customer-facing workload, downtime has a measurable hourly cost: lost transactions, idle staff, SLA credits owed to customers, and the slower cost of reputation and churn. The finance job is to put a number on an hour of downtime for each critical workload, compare it against the monthly Site Recovery cost for that workload, and protect the ones where the maths is obvious. Not every VM clears that bar, and that is the point: disaster recovery should be applied deliberately to the workloads whose downtime is expensive, not blanketed across the estate.

The trade is asymmetric in the same direction as an insurance premium. The monthly cost is small and known. The avoided cost, a prolonged outage of a critical system with no tested way to recover, is large and uncertain. Frame each protected workload as a premium paid against a quantified hourly downtime cost, and the decision stops being abstract.

Priya is the finance partner supporting the reliability programme. The platform team comes back with a request to enable Site Recovery on twenty-two virtual machines, and the instinct is not to approve or reject the lot; it is to ask which of these workloads have a downtime cost that justifies a recurring premium. Site Recovery is not free: each protected VM carries a per-instance licence charge, replicated disk storage in the secondary region, a small cache account, and ongoing replication egress. None of that buys a second running fleet, the recovery VMs only cost compute during a drill or a real failover, but the replication line is real and recurring.

Priya asks the team to attach an hourly cost of downtime to each of the twenty-two VMs and sort by it. Four are revenue-path systems where an hour offline costs more than a year of Site Recovery licensing, six are important internal systems where a few hours of downtime is tolerable but a multi-day region outage is not, and the rest are development and staging machines whose downtime costs essentially nothing. The finance pack reads: 'Protect the four revenue-path workloads now, because the monthly premium is a rounding error against their hourly downtime cost; protect the six internal systems as a planned second wave; leave the dev and staging VMs out, because paying an insurance premium on a workload nobody loses money over is the wrong call.' Disaster recovery becomes a list ordered by downtime cost, not a blanket switch.

The cost model here is a straight comparison of two numbers, which makes it unusually clean to reason about. On one side is the recurring Site Recovery cost for a workload: the per-instance licence, secondary-region disk storage, cache and replication egress, all known and predictable, with no second running fleet to pay for. On the other side is the cost of that workload being offline for an hour, a day, or however long an unrecovered region outage lasts.

For a revenue-path system the comparison is rarely close: the monthly premium is a small fraction of a single hour of downtime, so protection is obviously worth it. For a development or staging VM the comparison is the other way: there is no downtime cost worth insuring, so paying the premium is waste. The finance role is to make that hourly downtime cost explicit for each candidate workload and let it decide, so disaster-recovery spend concentrates exactly where the avoided cost dwarfs the premium and is deliberately withheld where it does not.

Cloud regions are extremely reliable, but they are not infallible, and when one has a bad day every workload that lives only there is offline until it recovers. The leadership question is simple: for the systems the business cannot run without, do we have a tested way to bring them up somewhere else, and how quickly?

Site Recovery is the answer to that question for virtual-machine workloads. It keeps a continuously updated copy of each critical VM in a second region and turns recovery into one orchestrated action. The defensible end state is not 'we have it switched on somewhere'; it is that the critical workloads are replicated, the failover has been rehearsed recently, and the business knows its recovery time is measured in minutes or low hours, not in 'however long the region takes'.

This is a cost decision, but a small and bounded one, weighed against the cost of an outage you have no plan for. The board-level signal is whether downtime of a critical system is a survivable, rehearsed event or an open-ended crisis.

After a peer company spent the better part of two days offline when their primary region had an outage, the CEO asked the obvious question at the next review: if that happened to us, what would we do? The honest answer at the time was uncomfortable. Some critical workloads were replicated, some were not, and nobody could state a recovery time with a straight face because the failover had never actually been run.

The team's response was to stop treating disaster recovery as a checkbox on a vault and start treating it as a rehearsed capability. They listed every business-critical VM, confirmed which were genuinely under replication and which only looked protected, enabled Site Recovery on the ones that were missing, and then, the part that mattered most, scheduled a quarterly test failover into an isolated network so the recovery was proven rather than assumed. The next time the CEO asked, the answer had changed from 'it depends' to 'the revenue-critical systems are replicated to a second region, we ran the drill last month, and recovery is measured in tens of minutes.' That shift, from an untested assumption to a known and rehearsed recovery time, is the confidence signal this capability delivers.

Nearly every serious cloud-availability incident that turns into a business crisis shares a root cause: a critical system that lived in one place, with no tested way to bring it back somewhere else. Disaster recovery with Site Recovery is the capability that removes that root cause for VM workloads, and a regular test failover is what proves the removal is real rather than theoretical.

The cost of getting this wrong is open-ended, a prolonged outage of a system the business cannot run without, while the cost of getting it right is a small, bounded monthly premium on a deliberately chosen set of workloads. This is the kind of insurance decision leadership should make consciously: not protecting everything, but ensuring the handful of systems whose downtime would genuinely hurt are replicated and rehearsed.