Azure disaster recovery cost is usually lower than the cost of building a second datacentre, but higher than the tidy monthly number Microsoft’s pricing page suggests. That is the honest starting point. Azure Site Recovery is billed per protected instance, with the first 31 days free for each instance, but Microsoft also says you may incur charges for Azure Storage, storage transactions and outbound data transfer. In practice, the bill depends far more on architecture, churn, testing cadence and failover design than on the headline licence alone. (azure.microsoft.com)
My view: most organisations do not overspend on Site Recovery because Microsoft’s licence is expensive; they overspend because they treat disaster recovery as a software toggle rather than an operating model. If you want a realistic budget, start with the workload, not the product SKU.
Where we are
Azure Site Recovery remains Microsoft’s core disaster recovery service for replicating workloads to Azure, to customer-owned sites, or between Azure regions. Microsoft’s current pricing page says the service is billed by the number of instances protected, with each protected instance free for the first 31 days. After that, charges apply per protected instance, and Azure Site Recovery between Azure regions is priced at the same rate as Azure Site Recovery to Azure. Microsoft also states that billing is based on the average daily number of protected instances over a monthly period, which matters if you are onboarding or retiring workloads mid-month. (azure.microsoft.com)
That is the easy part. The harder bit is that the licence is only one component. Microsoft explicitly notes that you may also pay for storage, storage transactions and outbound data transfer. During the first 31 days, the Site Recovery protection itself is free, but those supporting charges can still apply, and a recovered virtual machine may incur compute costs as well. In other words: the service may be free for a month; the recovery environment is not. (azure.microsoft.com)
For UK buyers, that distinction matters because cloud DR budgets are often approved as a resilience line item, then later consumed as a general cloud platform cost. If finance is expecting a fixed software subscription and operations is quietly running replicated disks, test failovers and recovery VMs, you have not got a pricing problem. You have got a governance problem.
Signals worth watching
The first signal is that Microsoft’s own documentation keeps pushing customers towards architecture-aware pricing rather than broad promises. The Azure Architecture Center’s disaster recovery guidance for a multi-tier app explicitly calls out ongoing Site Recovery charges and uses the Azure pricing calculator to estimate a six-VM example. That is telling: Microsoft is effectively saying the cost model is workload-specific, not something you can safely infer from a generic calculator screenshot. (learn.microsoft.com)
The second signal is that Microsoft is still refining where Site Recovery behaves well operationally. Its reliability guidance now lists regions where the core Site Recovery service and Recovery Services vaults are zone resilient, and it also points out that in regions not on that list, zone failures may affect operations. It further notes that Site Recovery is billed based on the number of VM instances protected, regardless of availability zone configuration. That means resilience design and cost design are related, but not identical. Zonal deployment may improve operational confidence without changing the basic per-instance charge. (learn.microsoft.com)
The third signal is that Microsoft is differentiating between workloads rather than pretending all protected servers are the same. The pricing page refers to the Disaster Recovery Software Assurance benefit for Microsoft server products protected with Azure Site Recovery, and other Microsoft documentation now points to special cases such as high churn workloads and support matrices for specific platforms. That is a clue that the real cost conversation is increasingly about the kind of workload you are protecting, not just how many VMs you have. (azure.microsoft.com)
What actually drives Azure disaster recovery cost
| Cost driver | What Microsoft says | Why it matters in practice |
|---|---|---|
| Protected instances | Billed per protected instance, with the first 31 days free for each instance. | This is the visible licence cost and the easiest part to forecast. |
| Storage | Replica storage is charged in the target location. | Disks are often the hidden majority of the bill, especially for larger estates. |
| Storage transactions | Charged during steady-state replication and after failover or test failover. | Frequent recovery testing and chatty workloads increase operational cost. |
| Outbound data transfer | Charged when traffic leaves an Azure region. | Cross-region replication can add meaningful egress cost, especially for high-change data. |
| Recovered compute | Recovered VMs may incur Azure compute charges. | Failover capacity is not free; DR is only inexpensive if you size recovery honestly. |
| Testing and churn | Microsoft says overall storage cost is based on replica storage and the number of DR drills conducted in a year. | The more you test, the more you need to model snapshots, transient disks and associated operations. (azure.microsoft.com) |
The practical lesson is straightforward: a small number of large VMs can cost less than a large number of small ones, but a small number of high-churn, data-heavy VMs can still be awkwardly expensive. Microsoft’s own documentation on high-churn workloads and managed-disk charges shows that replication characteristics matter. If your estate includes databases, analytics tiers or file services, do not assume they behave like office productivity servers. (learn.microsoft.com)
There is also a policy angle. Microsoft’s Azure Policy-based enablement guidance for Site Recovery suggests customers are expected to operationalise protection at scale, not hand-click each VM forever. That is not directly a cost item, but it has budget implications: if you cannot automate onboarding, tagging, exclusions and drift control, the human effort around DR will show up in administration time long before it shows up in a neat cloud invoice. (learn.microsoft.com)
Budgeting rule of thumb: if your DR estimate only includes the Site Recovery licence, it is incomplete. If it includes licence, storage, egress, compute for failover and a realistic test schedule, you are finally approximating the real number.
What I expect
Over the next year, the most significant change will not be a dramatic cut in Site Recovery pricing. It will be a continued shift towards finer-grained cost and resilience decisions. Microsoft is already steering customers towards zone-aware design, workload-specific support matrices and calculator-based estimates. That suggests the pricing model itself is unlikely to simplify; if anything, it will become more dependent on the operational shape of the environment. (learn.microsoft.com)
I would also expect more organisations to discover that Azure disaster recovery cost is less about the DR tool and more about where they are trying to land their recovery posture. If you want warm standby with short RTOs, you are paying for capacity somewhere. If you want low-cost pilot light DR, you are paying with longer recovery times and more manual work. Azure Site Recovery does not change that trade-off; it just makes it easier to buy into it.
For UK enterprises, this intersects with a broader infrastructure trend: the post-VMware world is forcing teams to look at every resilience platform more critically. That is one reason our recent coverage of migration and platform comparison work remains relevant, from Proxmox vs VMware vs Hyper-V vs HPE Morpheus to the VMware exit strategy piece. Once virtualisation strategy changes, DR strategy usually has to change with it.
What could prove this wrong
The main thing that could make today’s cost expectations look wrong is a material change in Microsoft’s pricing or service packaging. The current pricing page is explicit that prices are estimates, that actual pricing may vary by agreement and exchange rates, and that customers should check the pricing calculator for their current offer. In plain English: if you are reading this a year from now, do not treat these rules as immutable. (azure.microsoft.com)
A second possibility is that the cost story changes because the architecture changes. Microsoft continues to support more resilience patterns, including availability zones and specific support matrices for selected scenarios, which can alter the amount of secondary infrastructure you need. If more recovery targets can be run cheaply within a region, some workloads may shift away from classic cross-region DR. But that would be an architecture decision, not a fee reduction. (learn.microsoft.com)
A third risk is that organisations underestimate the commercial effect of testing. Microsoft is clear that storage cost is influenced by replica storage and the number of disaster recovery drills conducted in a year. The more mature your DR programme becomes, the more often you are likely to test it. That is the right thing to do operationally, but it means a “real” DR budget should be higher than a paper plan with annual tabletop exercises. (azure.microsoft.com)
What organisations should prepare for
- Separate the Site Recovery licence from the rest of the recovery stack in your budget model.
- Model storage and egress per workload, not per estate average.
- Account for failover compute, even if you hope never to use it.
- Price at least one real test-failover cycle, because DR you do not test is not DR.
- Map which workloads can tolerate pilot-light recovery and which need warm standby.
- Check whether any Microsoft software entitlement applies, such as the Disaster Recovery Software Assurance benefit for eligible server products. (azure.microsoft.com)
Procurement teams should ask a more awkward question too: what is the business actually buying? If the answer is “regulatory resilience” or “board assurance”, then the cheapest configuration is rarely the right one. If the answer is “a practical recovery option for a handful of critical services”, then Azure Site Recovery can be sensible, provided the infrastructure team prices the whole recovery path rather than the licence alone.
That is where Microsoft’s current documentation is useful. It does not pretend disaster recovery is free, and it does not hide the fact that storage, transactions, egress and compute all participate in the bill. The vendor framing is still optimistic, but the underlying mechanics are clear enough to budget against. The real mistake is to confuse a DR product with DR readiness.
Sources and further reading
- Azure Site Recovery pricing – Microsoft Azure
- Azure Site Recovery product page – Microsoft Azure
- Reliability in Azure Site Recovery – Microsoft Learn
- Multi-tier Web Application Built for High Availability and Disaster Recovery – Microsoft Learn
- Understanding Azure Site Recovery for Managed Disks Charges – Microsoft Learn
- Enable Azure Site Recovery for your VMs by using Azure Policy – Microsoft Learn
- Support for disaster recovery of Hyper-V VMs to Azure with Azure Site Recovery – Microsoft Learn
- Support matrix for shared disks in Azure VM disaster recovery – Microsoft Learn
Spot an error?
If something factual looks wrong, outdated or misleading, flag it here. Corrections are reviewed separately from normal article comments and reader questions.


