Warm Standby

Warm standby sits between pilot light and active-active on the disaster-recovery curve. The full stack exists and runs in the secondary location at reduced scale, data replicates continuously, and failover is a traffic redirect plus a scale-up.

Typical characteristics: RPO measured in seconds (bounded by replication lag), RTO measured in minutes (bounded by traffic redirection and scale-up time).

Why it matters

It is frequently the right point on the curve, because the alternatives are unbalanced for most systems. Backup-and-restore gives an RTO of hours to days, which is unacceptable for revenue-critical systems. Active-active gives near-zero RTO at a cost and complexity — bidirectional replication, conflict handling, split-brain risk — that many systems do not need.

Warm standby buys most of the availability benefit for a fraction of the complexity.

Implementation patterns

• Continuous asynchronous replication of every stateful component, with lag monitored and alerted as a first-class SLI.
• Infrastructure defined as code and applied to both locations, so the standby cannot drift into being a different system. Drift is what makes untested standbys fail.
• Traffic steering that does not depend on DNS alone. DNS TTLs are honoured inconsistently and clients cache far beyond them; health-aware routing or client-side endpoint lists give bounded failover time.
• Regular exercised failover. A quarterly drill that actually serves production traffic from the standby, then fails back. Anything less is a design, not a capability.
• Scale-up automation pre-tested, because the failover event is a poor time to discover a quota limit in the secondary region.
• Explicit dependency inventory. The system's real RPO is the worst of its components: the database may replicate continuously while the configuration store, secrets manager and object storage do not.

Industry example

An enterprise platform with contractual availability commitments typically lands here for its revenue-critical transactional systems, and deliberately lower for everything else. The important design insight is that a single company-wide DR standard is nearly always wrong — it over-invests in systems whose failure nobody notices for a day, and under-invests in the few whose failure stops revenue.

The tiering that works assigns each system a target based on business impact per hour of downtime: active-active for the handful where downtime is catastrophic, warm standby for revenue-critical systems, pilot light for embarrassing-but-survivable ones, and honest backup-and-restore for the rest — with someone willing to say out loud that a day of downtime is acceptable for a given system.

Failure scenarios

• The standby that has never taken traffic. Configuration drift, expired certificates, missing dependencies added to primary last year, insufficient quota — all discovered during the disaster.
• Failback not designed. Returning, with data written in the secondary during the event, is usually harder than failing over and almost never rehearsed.
• Failover requiring the failed region. A runbook step, a control plane, or a credential that lives in primary.
• Replication lag unmonitored, so the actual RPO at the moment of failure is unknown and far worse than the target.
• Cost pressure quietly reducing the standby until it cannot absorb production load even after scale-up.

Trade-offs

You pay continuously for infrastructure that produces no value in normal operation, plus the engineering cost of keeping two environments identical, plus the drill time. Against that, you get a recovery capability measured in minutes with a fraction of active-active's complexity.

The decisive question is honest: what does an hour of downtime cost this specific system? Multiply by the probability and compare against the annual standby cost. Systems where that arithmetic does not favour warm standby should say so and choose a cheaper tier rather than pretending.

Interview question

"Design DR for three systems: checkout, an internal analytics dashboard, and a customer data export service. Give each an RTO and RPO, justify the difference, and tell me how you would prove each one actually works."