By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
The most expensive machine in most DR designs is the one that sits idle. A standing recovery site is a full set of hosts drawing power and burning license entitlements, doing nothing but waiting for a bad day that may never come. You size it for the whole estate because that is what a real failover needs, and then it runs at a few percent utilization for years. Finance notices. Eventually someone asks why the disaster you insure against costs almost as much as the production it protects.
DR to the cloud changes the shape of that bill. You stop paying for a full second fleet standing all year and pay instead for capacity when a failover calls for it. In VCF 9 this lives under VMware Live Recovery, and it splits into two roads. You can replicate to a cloud-based VCF site and orchestrate recovery there with VMware Live Site Recovery, the engine that used to be Site Recovery Manager paired with vSphere Replication. Or you can ship snapshots to VMware Live Cyber Recovery, the service that used to be VMware Cloud DR, which lands them on VMware Cloud on AWS. Both count as DR to the cloud. They are not the same product, and the difference decides your RPO, your RTO, and your monthly cost.
What DR to the cloud means in VCF 9
At 3 a.m. the business does not ask which product you used. It asks how much data was lost and how long until the application answers again. Those two questions map to RPO and RTO, the pair this series covered in Part 2, and DR to the cloud trades them against cost in a way an on-premises second site does not. When you own both sites, capacity is fixed and the tuning happens in replication. When the recovery side is cloud, capacity itself becomes a dial, and that dial is where the money and the risk sit.
Road one: a cloud-based VCF site
The first road looks like the DR you already know, only the second site is rented instead of owned. You stand up a VCF site in a cloud or partner region, replicate to it with vSphere replication, and orchestrate recovery with VMware Live Site Recovery. Protection groups, recovery plans, network mappings, and re-IP all work the way Part 6 and Part 7 described. Because it is real vSphere replication into a real VCF site, this road reaches the tightest RPO available in the family, as low as one minute for the workloads that justify it.
Road two: VMware Live Cyber Recovery
The second road is a managed service. VMware Live Cyber Recovery, the offering that used to be VMware Cloud DR, takes snapshots of your protected virtual machines and stores them in a Scale-Out Cloud File System that sits in the cloud, not on hosts you run. When you declare a disaster, the service mounts that file system straight to a recovery SDDC on VMware Cloud on AWS and powers the virtual machines on from it, so you skip a slow storage migration before anything boots. The RPO here reaches as low as thirty minutes. The reason to pick it is not a tighter number. It is that you do not own or run the second site at all until the day you need it.
The two roads off-site
Teams get into trouble when they treat these as one thing called cloud DR and expect a single set of behaviors. They are different engines with different RPO floors, different orchestration, and different failback stories. Here is the split I keep in front of me when I design.
| Approach | What it is | RPO floor | Best when |
|---|---|---|---|
| Cloud VCF site | vSphere replication into a rented VCF site, orchestrated by VMware Live Site Recovery with recovery plans and re-IP | As low as 1 minute | You want full control and the lowest RPO for tier-1 apps |
| VMware Live Cyber Recovery | Managed service ships snapshots to a Scale-Out Cloud File System, mounts to a recovery SDDC on VMware Cloud on AWS | As low as 30 minutes | You want cloud economics and no second site to run day to day |
Pilot light, on-demand, or a full standing site
Once you choose the cloud service road, the next decision is how much recovery infrastructure to keep warm. This is the dial that sets both your RTO and your monthly cost, and it is where I see the most avoidable mistakes.
Full standing recovery site
A recovery SDDC sized for the whole estate, running all the time. Fastest to fail into because nothing has to deploy first, and the most expensive by a wide margin. This is the cloud version of the idle second site, and it makes sense only for a small set of workloads that cannot tolerate a deployment wait.
Pilot light
A minimal recovery SDDC kept warm, commonly two hosts, that scales up to the size a real failover needs when you declare one. You pay for a small standing footprint year round and pay for the rest only during a test or a real event. This is the setting I reach for by default because it keeps RTO short without carrying a full fleet.
On-demand
The cheapest steady state and the one with a catch. A single non-durable host stands as an evaluation footprint, and you scale to a durable two-host configuration only when you need it. A one-host SDDC has no failure tolerance, so it is a place to prove the workflow, not a place to run production during a real disaster. Read the next callout before you make it your plan of record.
The single-host on-demand SDDC bites teams that mistake it for a recovery target. It is non-durable by design, meaning one host with no redundancy, meant for evaluating the workflow. I have watched a team plan to sit their production in a one-host SDDC during a real event because the demo worked there. A pilot light of two durable hosts is the smallest thing I trust to hold live workloads. There is a second trap underneath it: pilot light and on-demand both assume cloud capacity is there when you call for it, and during a wide regional event everyone calls at once. Reserve the scale-up capacity you plan to need, or write down that you accepted the risk.
| Model | Standing hosts | Steady host-hours per month | Extra for a 3-day failover test | Relative cost |
|---|---|---|---|---|
| Full standing site | 8 | 5,760 | none, already full | Highest |
| Pilot light | 2 | 1,440 | +432 | Medium |
| On-demand | 1 non-durable | 720 | +504 | Lowest steady |
Illustrative, based on an eight-host full estate and a thirty-day month. Host-hours only, before storage, egress, and service fees.
How recovery runs once you fail over
The forward direction is the part that demos well. Snapshots already sit in the Scale-Out Cloud File System, so when you declare a disaster the service mounts that file system to the recovery SDDC and powers virtual machines on directly from it. You are not waiting to copy terabytes into the SDDC before the first boot, which is the classic tax of older cloud DR designs. Recovery plans run their ordered power-on and re-IP the same way an on-premises plan does.
The RPO you actually get depends on which road you took. The cloud VCF site path with vSphere replication reaches down to a one-minute RPO for the workloads you point it at. The Live Cyber Recovery path to the file system reaches down to thirty minutes. Neither number is free. Both cost bandwidth in proportion to your change rate, and the tighter the RPO, the more link you buy. Match the tight number to the handful of applications that need it, not the whole estate.
Before you count cloud DR as real recovery, confirm five things. First, you have run a full cloud failover test end to end, not just a green replication dashboard. Second, DNS, re-IP, and firewall rules exist for the recovery network so applications can find each other after they move. Third, you have priced and timed the failback, because moving data back on-prem is the slow, metered leg. Fourth, the scale-up capacity your pilot light needs is reserved or the risk is written down. Fifth, identity services such as directory and DNS are reachable from the recovery SDDC, or you have placed copies there. A recovery that boots but cannot authenticate is not a recovery.
Take an estate that needs eight hosts to run fully at the recovery site. A full standing SDDC runs 8 hosts times 24 hours times 30 days, which is 5,760 host-hours every month whether or not disaster strikes. A pilot light keeps 2 hosts warm, which is 1,440 host-hours, and adds 6 hosts for a 3-day test, which is 6 times 24 times 3, or 432 more, landing at 1,872 for the month. On-demand keeps 1 host, which is 720 host-hours, and scales to 8 for the same 3-day test by adding 7 hosts, which is 7 times 24 times 3, or 504 more, landing at 1,224. The pilot light carries roughly a third of the standing site cost while keeping RTO short. The chart below plots the cumulative host-hours across the month.
A real failover and a real failback move live workloads and can incur downtime and metered data transfer. Run them in a planned window with application owners in the room, and rehearse first as a test recovery into an isolated network, the same discipline covered in Part 8. Do not learn the failback cost during the failback.
What I would actually do
For most mid-size estates without a spare data center, I would run VMware Live Cyber Recovery with a pilot light of two durable hosts as the plan of record, accept a thirty-minute RPO for the general estate, and reserve the cloud VCF site path with its one-minute RPO for the short list of tier-1 applications that justify the bandwidth. I would not make the one-host on-demand SDDC my recovery target, because non-durable means it holds nothing I care about during a real event.
Here is where I part company with the usual pitch. Cloud DR is sold as cheaper, full stop, and in steady state it is. The number that pitch leaves out is failback. If a real event keeps you in the cloud for weeks, the metered egress to move everything home can eat the savings you booked by not running a second site. Budget for the round trip, not just the trip out. And resist the pull to chase a one-minute RPO across the whole estate. On three hundred virtual machines that is bandwidth and money spent buying risk reduction your tier-3 workloads will never cash in.
Common questions
Is DR to the cloud actually cheaper than a second site?
In steady state, usually yes, because you are not running a full host fleet all year. The cost people forget is failback. Moving data back on-prem after a real event is metered egress and takes time, so a long stay in the cloud can erase the steady-state savings. Price the round trip before you commit.
What RPO can I really get to the cloud?
To a cloud-based VCF site with vSphere replication, as low as one minute for the workloads you point it at. To VMware Live Cyber Recovery on the Scale-Out Cloud File System, as low as thirty minutes. Match the tight number to tier-1 only, because bandwidth cost climbs as you push the RPO down.
Do I need a recovery SDDC running all the time?
No. Pilot light keeps a small two-host SDDC warm and scales up on failover. On-demand keeps a single non-durable host for evaluation. That one-host option proves the workflow but is not a production recovery target, so plan around the pilot light if you want somewhere real to land.
Can I test cloud failover without touching production?
Yes, and you should. Run a test recovery into an isolated network on the recovery SDDC, the same test-bubble discipline from Part 8. If you have never run one, your cloud DR plan is unproven no matter how healthy the replication looks.
Does DR to the cloud cover ransomware?
Not on its own. DR gets you running elsewhere quickly, but it will happily replicate an infection along with everything else. Cleaning a compromise is cyber recovery, which uses the isolated recovery environment covered in Part 10. Keep the two plans separate and do not assume one buys the other.
Where this leaves you
DR to the cloud is worth doing when it replaces an idle second site you are paying for and rarely test. Pick the road that matches the workload, keep a pilot light warm rather than a full fleet, and treat failback as a first-class part of the plan instead of an afterthought you discover during an outage. The cloud makes the recovery site someone else problem to run. It does not make the plan test itself.
Next up in the series is sizing and bandwidth, where the change-rate math behind these RPO numbers gets concrete. Read the VMware Live Recovery for VCF 9 complete guide to see how this part fits the whole, then run a test failover to the cloud this quarter if you have not.
« Previous: Part 10 | VMware Live Recovery Complete Guide | Next: Part 12 »
References
- VMware Live Recovery product page (Broadcom)
- VMware Live Recovery for VCF 9.0 (VCF blog)
- Managing your recovery SDDC deployment, pilot light and on-demand (VMware docs)
About The Author
Discover more from Journal of Intelligent Infrastructure – By Dr Pranay Jha
Subscribe to get the latest posts sent to your email.
Previous Post
Next Post
DrJha