Warm Standby DR

Warm standby disaster recovery keeps a scaled-down but fully functional copy of an application running continuously in a secondary region, ready to be scaled up to full capacity and take over traffic quickly if the primary region fails — a middle ground between the minimal pilot light approach and a fully active-active deployment.

How It Differs from Pilot Light

Where pilot light keeps only the data layer running continuously and starts compute from scratch during failover, warm standby keeps a live, running (though minimally sized) version of the entire application stack — web servers, application servers, and database — active at all times in the DR region. Because the application is already running, failover mainly requires scaling that standby environment up to handle full production load and redirecting traffic to it, rather than provisioning and starting compute resources from a cold state.

The Tradeoff

This continuous baseline of running infrastructure costs more than pilot light’s near-zero steady-state cost, but it delivers a meaningfully faster recovery time — typically minutes rather than the tens of minutes to hours associated with pilot light — since there’s no cold-start delay for compute resources, only a scaling operation on infrastructure that’s already warmed up and serving at least some traffic or health checks.

When It’s the Right Choice

Warm standby is a common choice for production systems where a recovery time of several minutes is acceptable but full active-active (running at full production capacity in multiple regions simultaneously, with no scale-up delay at all) would be an unnecessary cost for the business’s actual availability requirements. It sits alongside pilot light and active-active as the standard set of DR patterns architects choose between based on the specific RTO and cost tradeoffs a given workload demands.

Testing Warm Standby Without Disrupting Production

A practical operational challenge with warm standby DR is validating that failover actually works correctly without needing to simulate a full production outage — many organizations address this by periodically routing a small percentage of real production traffic to the standby environment during normal operation, verifying it handles real requests correctly while the primary continues serving the bulk of traffic. This kind of live validation catches configuration drift between primary and standby environments (a common and easy-to-miss failure mode, where the standby has quietly fallen out of sync with recent changes to the primary) far more reliably than periodic manual DR drills alone, which tend to happen infrequently enough that drift can accumulate undetected between them.