Zerto vs Azure Site Recovery: what a one-hour RPO costs per protected VM

The bill is per instance, and the instance count is the decision

Disaster recovery stopped being a capital project and became a subscription line, and the line is counted in protected instances rather than in terabytes. Azure Site Recovery publishes its pricing on a per-instance basis, with the protected instance as the unit the meter reads, and the storage and network charges that make replication work are billed separately from that instance fee. A team that protects 50 VMs and a team that protects 500 are therefore buying two different products from the same catalogue page, and the second one is where the architecture argument starts.

The reason the count matters more than the volume is that a protected instance is a VM, not a gigabyte. A 900-person estate running a few fat database servers and a long tail of small application VMs pays for the tail as well as the databases, and the tail is usually where the VM count explodes. Before any comparison of Zerto and Azure Site Recovery can be honest, the buyer needs the number the vendor will meter: how many VMs sit inside the recovery scope, and how many of those are in scope only because nobody has retired them.

That is also the number the newsletter promised. Price 50 VMs and price 500 VMs across both products and the shape of the answer changes, because one side charges per instance and the other sells a licence. The rest of this page separates those two mechanics and gives the conditions under which each one wins.

What each product actually does with the replication

Azure Site Recovery is Microsoft's replication and orchestration service inside the Azure portal. It replicates workloads from a primary site into a recovery region, keeps the replicas in storage, and runs recovery plans that bring machines up in a defined order when a failover is declared. The service is documented as covering Azure-to-Azure, VMware, Hyper-V and physical server scenarios, and the recovery-side compute is charged when it runs, which is why a cold standby is cheaper than a warm one.

Zerto approaches the same problem from the appliance side. Its replication is continuous and the recovery point objective is set by the journal rather than by a scheduled snapshot, which is the property that makes a one-hour RPO a configuration choice rather than a storage-cost negotiation. The product is sold as a licence, and the licence is what the buyer negotiates.

The practical difference for a platform team is where the intelligence sits. With Site Recovery the orchestration, the runbooks and the failover live in Azure and the recovery target is Azure. With Zerto the replication layer is portable across hypervisors and clouds, which matters to an estate that has not finished deciding where its recovery site will be.

Where the published numbers run out

Microsoft publishes its Site Recovery pricing page, so the per-instance rate, the storage rate and the network egress treatment are all checkable before a call. That is the stronger position of the two on paper, and it is the reason the Azure option is easier to model in a spreadsheet on day one.

Zerto publishes no list price on the material available here. That is a finding, not a gap to be filled with an estimate: the buyer should ask for the per-VM licence figure, the term it covers, whether the licence is perpetual or subscription, and what the vendor charges for the recovery-side compute and storage that the licence does not include. A quote that names only the licence and not the run cost is not comparable to the Azure page.

The same discipline applies to the Azure side. The instance fee is the visible number, but the storage that holds the replicas, the egress when a failover pulls data across regions, and the compute that runs during a test or a real recovery are all separate. Ask Microsoft for a worked example at 50 and at 500 protected instances, with a test failover included, because a recovery plan that has never been tested is a document rather than a capability.

What it costs before and after

The grid below separates the two billing mechanics on the criteria the decision actually turns on. It is not a price list, because one side of it has no published price; it is the set of questions that decide which quote is smaller for a given estate.

Read the first row first. If the estate is 50 VMs, the per-instance model is a small number and the licence negotiation is probably not worth the procurement cycle. At 500 VMs the per-instance model scales linearly with the count while a licence is a fixed number across the estate, and that is the point where the two curves cross in Zerto's favour, subject to the quote.

The RPO row is where the technical argument lives. A one-hour RPO is achievable on both, but on the Azure side it is a function of how often replication runs and what storage tier holds the replicas, both of which are billed. On the Zerto side it is a function of the journal, which is inside the licence.

The workloads the count hides

A VM count is a blunt instrument, and both products know it. The 500-VM estate is rarely 500 identical machines: it is a handful of databases with tight RPO requirements, a middleware tier that has to come up in order, and a long tail of application servers whose loss would be annoying rather than fatal. The recovery plan is where that hierarchy gets expressed, and the hierarchy is what determines whether the one-hour RPO applies to five VMs or to all 500.

That distinction changes the bill on the Azure side directly, because the instance fee is charged per protected instance and the storage tier can differ per workload. It changes the Zerto negotiation indirectly, because the licence is usually quoted against a scope and the scope is the thing to argue about. A buyer who walks into either call with a single number and no tiering has given away the only lever that moves the price.

The other workload question is where the recovery site sits. An Azure-to-Azure plan keeps everything inside one cloud account and one bill, which is simpler to model and harder to argue is independent of the primary provider. A portable replication layer allows a recovery target that is not the same vendor, and that resilience argument is worth a premium that the spreadsheet will not show.

The decision rule

Choose Azure Site Recovery if the estate is modest, the recovery target is already Azure, and the team wants a published per-instance rate it can model before the first call, because the pricing page gives it the number and the portal gives it the orchestration without a second vendor.

Choose Zerto if the VM count is large enough that a fixed licence beats a per-instance meter, or if the recovery site has to be portable across hypervisors and clouds, and accept that the comparison then rests on a quote you have to request rather than a page you can read.

Wait if neither side has given you a worked example at your real VM count with a test failover included, because the one-hour RPO is a design target and the bill is what happens when you test it.