The best cloud disaster recovery service for Australia and New Zealand

The problem: a second site on the other side of a small map

Disaster recovery in Australia and New Zealand has always been shaped by geography. Most organisations have one primary data centre, a short list of credible secondary locations, and a board or regulator that expects critical systems back within hours. Building and running a second physical site costs nearly as much as the first, and it sits idle almost all of the time. Using a public cloud region as the recovery site is the obvious alternative: replicate servers continuously, keep only cheap storage and small replication servers running, and pay for full compute only during a drill or a real event.

Until recently that option came with a catch for New Zealand buyers. The nearest hyperscale regions were in Sydney and Melbourne, so a New Zealand organisation that wanted its recovery copies kept in the country had to look elsewhere. That changed when Microsoft opened New Zealand North and AWS launched its Asia Pacific (New Zealand) region in September 2025. It changed again for disaster recovery specifically when AWS added Elastic Disaster Recovery to the New Zealand region in July 2026. Google Cloud, by contrast, announced a New Zealand region in 2022 but we found no evidence that it has launched.

The technical questions are the same on both sides of the Tasman. How much data can you afford to lose (recovery point objective, RPO)? How long can systems be down (recovery time objective, RTO)? Can you go back to a point before ransomware encrypted everything? Can you test recovery without touching production? And what does the standby environment cost each month when nothing is wrong?

Who this is for

• Infrastructure, resilience and IT operations leads at Australian and New Zealand organisations that want a cloud region as their disaster recovery site.
• Estates that mix VMware, Hyper-V and physical servers on premises with some workloads already running in AWS or Azure.
• Organisations with data-sovereignty expectations: Australian data recovered in Australia, New Zealand data recovered in New Zealand, with the option to fail over across the Tasman for a regional event.
• It is not a guide to application-level runbook orchestration and dependency mapping, which we cover separately, or to backup of SaaS applications such as Microsoft 365.

How we evaluated

We fixed the criteria and weights before research, based on the problem above. We then reviewed official documentation, pricing pages, price APIs and independent sources for seven services, recording a source for every finding. The decisive facts (regional availability, prices, recovery point retention and compliance listings) were re-checked against the live pages on 19 October 2026. Each service was scored from 1 to 5 on each criterion with a written evidence note.

What we did not do: we did not run these services, measure real RPOs or RTOs, or request quotes. Recovery objectives quoted here are vendor claims. Prices are public list prices in US dollars on the evaluation date; enterprise agreements and partner pricing usually differ. Where we could not confirm a claim, we say so.

Side-by-side comparison

Why AWS Elastic Disaster Recovery is the champion

It is the only service we found with a documented recovery target in three ANZ regions. The service endpoint list for AWS Elastic Disaster Recovery (AWS DRS) includes Asia Pacific (Sydney), Asia Pacific (Melbourne) and Asia Pacific (New Zealand). AWS documents recovery of EC2 instances into a different Availability Zone or a different Region, so an Auckland organisation can recover on-premises servers into the New Zealand region and protect those recovered workloads into Sydney, while an Australian organisation can pair Sydney with Melbourne. AWS does not publish a worked Sydney-to-Auckland reference design, so test the cross-Tasman path yourself.

Its recovery model is continuous with a long look-back. AWS DRS replicates source servers continuously into a low-cost staging area in your account, and AWS says it enables RPOs of seconds and RTOs of minutes. That is a marketing claim rather than an SLA, but the point-in-time design is concrete: the point-in-time policy keeps a snapshot every 10 minutes for the last hour, hourly snapshots for 24 hours, and daily snapshots for a configurable 1 to 365 days. AWS positions this for ransomware recovery: you launch a version of each server from before the attack.

It covers the mixed estates ANZ organisations actually run. AWS lists physical servers, VMware vSphere, Microsoft Hyper-V and other clouds as sources, with broad Windows Server and Linux support. Non-disruptive recovery and failback drills are part of the service, and a failback process returns workloads to on-premises or to another AWS Region.

Its standby cost is simple to model. The pricing page sets one rate, $0.028 per replicating source server per hour (about $20.44 per server per month at 730 hours), which it says is the same regardless of disk size or the Region you replicate to, and which includes test launches, recovery launches and point-in-time recovery. You also pay for the staging area: EBS volumes the same size as your source disks, snapshots, and small t3.small replication servers. Full-size recovery instances are charged only while a drill or recovery runs.

It has public assurance evidence for Australian buyers. AWS lists Elastic Disaster Recovery among its IRAP services in scope. The page does not say which regions the assessment covers, so public sector buyers should confirm Melbourne and New Zealand coverage directly.

AWS DRS did not win every criterion. Azure Site Recovery's recovery plans are more mature (AWS only added recovery plans in August 2026), and Google Cloud's immutable backup vaults are stronger on ransomware protection. AWS DRS won because it combined the widest ANZ footprint with the deepest point-in-time history and the clearest published price.

Where Azure Site Recovery is the better choice

Azure Site Recovery finished a close second and is the better pick for organisations that already run on Microsoft. Its regional story is nearly as strong: Azure pairs Australia East with Australia Southeast, offers restricted Australia Central regions for in-country government DR, and lists New Zealand North among the regions where Site Recovery is zone resilient. New Zealand North has no paired region, but Site Recovery can replicate between any two Azure regions, and you can restrict replication to a geographic cluster if sovereignty rules require it.

Its strengths are orchestration and Microsoft integration. Recovery plans sequence failover across application tiers with scripts, manual steps and automation runbooks, and drills run without affecting replication. Hyper-V machines can replicate as often as every 30 seconds, and Microsoft offers a separate RTO SLA for failover. The Azure Retail Prices API lists $25 per protected VM per month in both Australia East and New Zealand North, and each instance is free for its first 31 days.

The trade-offs are look-back depth and ransomware protection. According to the Site Recovery FAQ, crash-consistent recovery points are created every five minutes, application-consistent points no more than hourly, and the oldest usable recovery point is 15 days with managed disks. Ransomware that sits undetected for longer than that will need a separate backup. Failback to an on-premises physical server is not supported; you fail back to a VMware VM instead. Choose Azure Site Recovery if your estate is mostly Hyper-V or Azure, if you want proven recovery plans today, or if your team already operates Azure Automation.

Other credible options

Veeam (3.40) has the broadest workload coverage of any candidate and is a strong choice for organisations that already use it for backup. It can restore physical, virtual and cloud workloads into Azure, EC2 and Google Compute Engine, and its Veeam Data Cloud Vault offers immutable-by-default storage in Australia East and New Zealand North from $14 per TB per month. It scored lower because its continuous data protection replicates only to vSphere, so recovery into a hyperscaler is a restore from backup with an RPO equal to the backup interval, and its licence pricing is not published.

Commvault Cloud (3.20) has the widest storage footprint for isolated copies: its Air Gap Protect regions include AWS Sydney, Melbourne and New Zealand and Azure New Zealand North. Its Auto Recovery feature uses periodic replication with an RPO above 15 minutes, and its SaaS workload protection for AWS lists only Sydney in the region. Commvault publishes backup prices but not prices for its DR features. It announced IRAP PROTECTED status for its SaaS portfolio in 2023.

Zerto (3.15), now part of HPE, offers the best recovery granularity on paper: its journal-based protection recovers to any point with seconds of granularity and keeps up to 30 days of history. We could not verify which Australian and New Zealand regions it officially supports because its product and help pages did not load, and HPE does not publish a list price. Ask for the interoperability matrix before shortlisting it.

VMware Live Recovery (2.90) has excellent recovery plans and automated failback for vSphere estates, and an isolated recovery environment for ransomware investigation. It protects vSphere VMs only, its Live Cyber Recovery regions include Sydney but no New Zealand target, and the Live Recovery FAQ points buyers to an account representative for pricing, with commit-only subscriptions and a 10 TiB minimum per region.

Google Cloud Backup and DR (2.80) has the strongest ransomware protection in this group: its backup vaults enforce write-once, read-many immutability and indelibility, and the service is in Google's IRAP products in scope. It is aimed at workloads already in Google Cloud, does not document on-premises Hyper-V or physical protection, and Google Cloud has no launched New Zealand region.

Limitations and trade-offs

• RPO and RTO figures are vendor claims. AWS's "seconds and minutes" is marketing, not an SLA. Your real recovery time depends on boot order, DNS, identity and application start-up, which no replication tool measures for you.
• AWS DRS has no documented immutable recovery points. Point-in-time snapshots help you go back before an attack, but an attacker with administrative access to the AWS account could still interfere. Separate the DR account, restrict who can change replication settings, and keep an immutable backup as well.
• AWS DRS recovery plans are new. They launched in August 2026. Teams that need complex multi-tier sequencing today may find Azure Site Recovery or VMware Live Recovery more mature.
• The New Zealand regions are young. AWS opened its New Zealand region in September 2025 and added DRS in July 2026. Confirm that the instance types you need are available there before you rely on it.
• IRAP scope is not region-specific in public material. AWS lists DRS as IRAP in scope without naming regions; Microsoft's IRAP assessment covers Australian regions but the service list is behind a sign-in. Request current assessment letters.
• Cross-Tasman failover adds latency and data transfer charges. We did not model egress costs between Australia and New Zealand, and neither AWS nor Microsoft publishes a reference design for it.

Implementation and pricing considerations

1. Classify workloads by recovery tier first. Only systems with tight RPOs need continuous replication; the rest can be restored from immutable backups more cheaply.
2. Model the standby bill with real numbers. For 50 replicating servers, the AWS DRS service fee alone is about $1,022 a month at list price (50 x $20.44), before staging EBS volumes, snapshots and replication servers. The same 50 VMs on Azure Site Recovery cost $1,250 a month in licence fees after the free period, before storage.
3. Choose the recovery region for sovereignty, then test the cross-Tasman path. New Zealand organisations can now recover in New Zealand on AWS or Azure; decide whether Australian regions are acceptable as a second tier and document the decision.
4. Reserve capacity for the day you need it. Microsoft recommends capacity reservations in the target region; plan the same for large AWS recoveries in younger regions.
5. Run drills on a schedule. Both leading services make drills cheap: you pay for compute only while test instances run. Quarterly drills catch configuration drift before a real event.

Questions to ask vendors

1. Which Australian and New Zealand regions can we use as both the replication target and the recovery site, and are any features reduced in the New Zealand region?
2. What RPO and RTO do you commit to contractually, and what does the SLA actually cover?
3. How far back can we recover, and are recovery points protected from deletion by a compromised administrator account?
4. What exactly do we pay each month when nothing is wrong: licence, storage, snapshots and replication servers?
5. How does failback work for physical servers, VMware and Hyper-V, and how much data is transferred?
6. Is the service itself covered by your IRAP assessment, and does that assessment include the Melbourne and New Zealand regions?
7. What capacity guarantees exist for a recovery during a region-wide event when many customers fail over at once?

What would change our verdict

We will revisit this recommendation if AWS adds immutable recovery points or publishes region-specific IRAP coverage, if Microsoft extends Site Recovery's 15-day recovery window, if Google Cloud launches its New Zealand region, or if HPE publishes Zerto's supported regions and pricing. Each change would move at least one score on the criteria above.