Cloud is a good fit for disaster recovery. You pay for a small footprint most of the time and scale it up when needed, rather than owning a second data centre that idles. The economics are genuinely favourable compared with the traditional approach.
The catch is that the favourable economics depend on the standby being small, and a small standby is one you cannot test properly without spending money.
The three postures
Backup and restore. Backups in cloud storage, nothing running. Cheapest by a wide margin, recovery measured in many hours or days, entirely dependent on restore throughput and how quickly you can build the target.
Pilot light. Core services running minimally — a replicating database, the network, the identity plumbing — with application capacity built on demand. Recovery in hours. This is where most organisations should be and where fewest actually are.
Warm standby. A scaled-down but complete copy, running. Recovery in minutes, cost proportional to how complete it is.
The cost difference between these is large. So is the recovery time difference. The mistake is choosing a posture by cost and then documenting a recovery time objective from a different posture.
The costs people miss
Replication is continuous. Data changing continuously is being copied continuously, and that traffic is billed. For a busy database this can exceed the standby compute cost.
Storage exists whether or not compute does. Pilot light still holds a full copy of the data.
The failover itself. Spinning up full production capacity means paying production rates for as long as you run there. If your event lasts three weeks, that is three weeks of double or full cost, and it is not in most budget models.
Coming back. Failback means moving changed data in the other direction, which means egress, which is the expensive direction.
Testing. Every realistic test costs a fraction of a real failover. Which is exactly why testing gets deferred.
The test problem
An untested DR plan is a document, not a capability. But a realistic test of a pilot light or warm standby means spinning up capacity, which costs real money, which requires approval, which means it happens annually at best and often never.
The organisations that handle this well do two things.
They test components continuously and the whole thing occasionally. Verify replication lag daily. Restore a database monthly. Build the application tier from templates quarterly. Run the full failover annually. Most of the risk is in the components, and components are cheap to test.
They budget the test explicitly. A line item, agreed in advance, so that the test does not require a business case each time. This single administrative change is the difference between a plan that is exercised and one that is not.
The question to settle first
What are you protecting against? A region-level cloud failure, a ransomware event, a data centre loss, or an application-level disaster are four different scenarios with four different designs.
Ransomware in particular is not solved by replication, because replication faithfully copies the encryption. It needs immutable backups with independent credentials, which is a different architecture from a warm standby.
Organisations that design one DR capability for all four scenarios generally have one that works for none of them properly. Name the scenario, then design for it, then price the test.