Your DR site sits idle 364 days a year. You shouldn’t rent full servers for the one day you need them — AWS Elastic Disaster Recovery replicates your servers block by block into a staging area in your own AWS account, in Mumbai or Hyderabad if you choose, and launches them in order only when you drill or recover.
Buy through TechBag
Same software. Better outcome — at a lower cost.
How it’s rated
Full scoreboard ↓Quick answer
This page covers AWS Elastic Disaster Recovery — the pay-as-you-go server DR service. The rest:
Most product pages skip this. We start here — so you buy a capability, not a buzzword.
Servers are replicated continuously into cheap storage in the cloud, and full machines are launched only on the day of a drill or a disaster.
What consolidation actually replaces, dimension by dimension.
| Dimension | A rented DR rack and nightly copies | AWS Elastic Disaster Recovery |
|---|---|---|
| Second site | A rented rack of idle servers all year | A staging subnet; full instances only on the day |
| Data lost in a disaster | Everything since last night’s copy | Seconds of changes, per AWS’s own claim |
| Boot order | A runbook on a wiki and a phone tree | Recovery plans of up to 20 ordered steps |
| Proving it works | A yearly test that needs downtime | Drills from any point without pausing replication |
| Paying for it | A fixed contract for capacity you rarely use | An hourly fee per server plus metered AWS resources |
| What it is NOT | — | Backup, a multi-cloud target, or a fixed-price bill |
The cheapest test is one server: replicate it into Mumbai, launch a drill from a recovery point, and time it against your RTO.
Vendors love diagrams; buyers need to know what they’re actually operating. Here’s the whole platform, demystified.
An agent on every Windows or Linux source copies changed disk blocks continuously, compressed and encrypted in transit, without a reboot of the server.
A staging subnet holds one EBS volume per source disk and small t3.small replication servers, each serving up to 15 disks, so no full servers run until needed.
Snapshots every 10 minutes are kept an hour, hourly ones a day, and daily ones from 1 to 365 days, so a recovery can start before corruption began.
Launch templates and post-launch actions set up each instance, recovery plans order the boot, and a Failback Client replicates the server home again.
An agent on every server and a staging subnet in your account — full instances launched only for a drill or a disaster.
AWS Elastic Disaster Recovery keeps a cheap, seconds-fresh copy of your servers in AWS until the day you need it.
The agent streams each changed block to staging as it is written, so the copy trails production by seconds, per AWS.
Physical, VMware and Hyper-V servers, machines in another cloud, and EC2 in another zone or Region all use the same agent.
Replicated disks wait on low-cost EBS behind small replication servers; production-size instances exist only during a launch.
Since 27 Aug 2026 a plan runs up to 20 steps and 100 servers in order, with wait and approval steps, at no extra charge.
A drill launches instances from any recovery point without pausing replication; you pay only for the drill’s EC2 time.
Launch templates set instance type and network, and post-launch actions run Systems Manager documents on every recovered server.
Recover from a snapshot taken before ransomware struck, choosing from 10-minute, hourly or daily points; only daily points can be kept up to 365 days.
Since July 2026 EC2 sources can skip conversion; AWS says up to 65% faster on Windows and 40% on Linux.
A Failback Client replicates recovered servers back on-prem, and a mass-failback tool handles whole vCenter estates.
AWS’s re:Invent 2025 DRS session, on-prem servers recovering into AWS, point-in-time recovery after ransomware, and estimating the full DRS bill. All from AWS’s official channels.
AWS’s newest DRS session; recorded before the August 2026 recovery plans shipped.
How on-premises servers replicate into a staging area and launch in AWS on the day.
Using point-in-time snapshots to recover servers to a moment before encryption began.
Estimating the full DRS bill: the server fee plus staging storage, snapshots and compute.
Want a live, India-context walkthrough for your environment?
Book a guided demo →Here’s what genuinely sets it apart — and exactly where it stops.
DRS charges $0.028 per replicating source server per hour, about $20.44 a month, with no upfront fee, minimum or term. AWS says that rate covers replication, drill launches, recovery launches and point-in-time recovery, whatever the disk count or Region, and it is the same in Mumbai and Hyderabad as in US East.
Physical servers, VMware, Hyper-V, other clouds and EC2 all replicate the same way, into your own AWS account. Source, staging and recovery can stay in ap-south-1 or ap-south-2, and an Indian billing address puts the contract with AWS India, which invoices in rupees with GST.
Until August 2026 boot order lived in your own scripts. Recovery plans now run up to 20 ordered steps across 100 servers, with wait and approval steps, in drill or recovery mode, at no extra charge. Each plan covers one account and one Region and must finish within 24 hours, so big estates need several.
AWS is the only target. The hourly fee is roughly a third of the real bill: AWS’s own 100-server example totals $6,389 a month against a $2,044 DRS fee. RPO and RTO figures are claims with no SLA credit, failback to on-prem needs an x86 boot client, and it is not backup.
Inventory the servers to protect, check each OS against AWS’s list, and note which need seconds and which can wait.
Add staging EBS, snapshots, replication servers and drill compute to the $0.028 fee, then pick Mumbai or Hyderabad.
Set up the staging subnet, install the agent on a pilot group, and let the first full copy finish before any drill.
Order the pilot servers into a recovery plan with an approval step, run it in drill mode, and time it against your RTO.
Fail the pilot back with the Failback Client, write the steps down, then add the rest of the estate in waves.
Modelled on Gartner Peer Insights structure. *Counts and breakdowns are illustrative pending verified review collection.
“Our second data centre lease ended and we moved DR for 60 VMware servers into Mumbai. The staging subnet costs far less than the racks did.”
“Budget for the whole bill, not the server fee. Staging volumes and snapshots on our busy SQL boxes came to more than DRS itself.”
“We ran a quarterly drill from a recovery point and replication never stopped. The auditors got launch logs and timings in one sitting.”
“The new recovery plans replaced our boot-order scripts. Database first, approval step, then the app tier, all in one run.”
“Failing back to the plant was the slow part: booting the Failback Client on each server took a weekend for 40 machines.”
“We pointed Hyper-V and physical servers at the same agent. One console for both beat buying two DR products.”
Analyst firms bury this view behind paywalls, and G2 retired its Grid. So here’s TechBag’s synthesis of the disaster recovery market — tap any vendor to see why it sits where it does.
Execution strength vs product vision — the classic market map, minus the paywall.
$0.028 per replicating server-hour; AWS resources billed on top.
The grid nobody publishes — how much of the price is printed before you talk to sales vs how recent and how ordered the recovery is.
Public per-server rate; continuous replication, recovery plans since 2026.
Positions are TechBag’s illustrative synthesis of public review-platform data and vendor documentation — not a reproduction of any analyst graphic. Verify before relying on it.
Against Azure Site Recovery, HPE Zerto In-Cloud for AWS, Druva DRaaS, N2W and Commvault Cloud Rewind — on sources, RPO, orchestration, failback, the full bill, scale and India.
| Dimension | AWS Elastic Disaster Recovery | Azure Site Recovery | HPE Zerto In-Cloud for AWS | Druva DRaaS | N2W Backup & Recovery | Commvault Cloud Rewind |
|---|---|---|---|---|---|---|
| What it is | AWS-native server DR | Azure-native server DR | EC2-to-EC2 DR | DR from backups | Snapshot backup + DR | Whole-app rebuild |
| Deployment | Agent + staging subnet | Vault; appliance on-prem | Agentless appliance | Druva SaaS + your AWS | Server in your account | SaaS, agentless |
| Sources and target | Any source; AWS only | Many sources; Azure only | EC2 in, EC2 out | On-prem in; AWS out | Many AWS services | Cloud apps, three clouds |
| Replication and RPO | Seconds (AWS claim) | 5-minute points | 30-minute default | Hours, = backup cycle | Backup schedule | Snapshot schedule |
| Orchestration and tests | Plans, drills since 2026 | Plans, isolated tests | Failover Test by group | Runbooks, test failover | Recovery Scenarios | Orchestrated rebuilds |
| Failback | x86 client; vCenter mass | Yes, physical as VM | Reverse protection | Documented to on-prem | Another restore run | Not one step |
| Pricing model | Per server-hour | Per instance, monthly | 36-month pack or BYOL | Per VM, on quote | Flat, per edition | SaaS, on quote |
| Published entry price | $0.028/server/hour | $25/instance/month | $17,970 / 10 / 36 mo | Not published | $249/month, 20 inst. | Not published |
| Billed on top | ≈ 2× the fee again | Storage, egress, compute | Snapshots, transfer | Failover compute | Snapshots, N2W server | Rebuilt resources |
| Scale limits | 300 per account-Region | 3,000 disks/subscription | 1,000+ instances | Not published | 20 up to 1,000+ | Not published |
| Ransomware defence | Point-in-time rollback | Copies what is written | CMK, Keycloak, IMDSv2 | Outside your account | Immutable snapshots | Clean-account rebuild |
| India DR site | Mumbai and Hyderabad | Four Indian regions | Not published | Mumbai, not Hyderabad | Your accounts; confirm | Target yours; SaaS? |
| Lock-in and exit | AWS is the only exit | Azure is the only exit | Your snapshots; 36 mo | Target leaves with Druva | Your snapshots, monthly | Native resources |
| Best fit | Mixed estates into AWS | Azure-committed estates | Large EC2 estates | Druva backup customers | AWS backup-first teams | Cloud-native apps |
Honest fit signals — because the fastest way to lose your trust is to pretend one product wins every scenario.
AWS Elastic Disaster Recovery is one of 27 disaster recovery products TechBag carries. The Disaster Recovery guide narrows them to a shortlist and shows the reasoning. →
Drag the sliders (servers you protect; IT staff-hour cost). Estimates model the staff time spent keeping a standby site current and rebuilding servers by hand in tests and outages, at an assumed 1.5 hours per server a year, with 70% of it saved by continuous replication, recovery plans and drills. Both figures are assumptions, and the AWS bill is not included. Illustrative.
Loaded cost = salary + overheads per productive hour. Illustrative only — your TechBag quote models your actual environment and modules.
Published, in US dollars. DRS charges $0.028 per replicating source server per hour, about $20.44 a month, the same in US East, Mumbai and Hyderabad, with no upfront fee, minimum, term or free tier; AWS says it covers replication, drills, recovery launches and point-in-time recovery. It is not the whole bill: staging EBS volumes, snapshots, t3.small replication servers, conversion, drill and recovery compute and data transfer are billed on top, and AWS’s own 100-server example comes to $6,389 a month against a $2,044 DRS fee. There is no rupee list price; AWS India invoices in INR with GST. TechBag models your full bill first, then quotes in INR with GST.
What AWS lists per server
Best for a broader rollout
What the fee does not include
Whatever the list prices above, TechBag negotiates a significantly better deal — with GST-compliant INR invoicing and local support. Ask us for your discounted quote.
Tell us your requirements and current tools — we’ll model it against what you spend today.
Take this into your next vendor call — including ours.
Is AWS acceptable as the only DR site? DRS recovers into AWS and nowhere else, apart from failing back to the source.
Have you priced staging EBS, snapshots, replication servers and drill compute, not just $0.028 per server-hour?
Is every source OS on AWS’s supported list? Windows 2008 and 2012 need legacy installers, and 2003 is out.
Mumbai or Hyderabad? Both run DRS; Hyderabad is an opt-in Region that must be enabled on the account first.
More than 300 replicating servers in one Region? That quota is fixed, so plan staging accounts up front.
How many days of daily snapshots do you need? Anything from 1 to 365; longer retention adds snapshot cost.
How will servers return home? The Failback Client is x86_64 only, and mass failback works with vCenter only.
Which AWS Support plan covers the DR day? AWS recommends Business or Enterprise Support for production DR.
Model the full monthly bill for your servers first, or let a TechBag advisor choose Mumbai or Hyderabad, plan staging accounts and run your first recovery-plan drill.
Stats, ratings, review counts and pricing are illustrative and sourced from public materials; verify before purchase.