Warm Standby

Warm standby keeps a complete, working version of a workload running at reduced capacity in a separate recovery location, often another cloud Region. The standby includes the application tiers, networking, data stores, and supporting dependencies needed to provide service. Unlike an environment assembled only after an outage, it can already process requests at a limited scale, although it does not normally serve production traffic.

The defining distinction is functional readiness rather than full production capacity. A pilot light typically keeps essential components, particularly data replication, running while other application infrastructure must be started or deployed during recovery. Warm standby has the application environment running already; recovery focuses on promoting writable data stores, scaling resources, validating readiness, and shifting traffic. Backup and restore generally requires more reconstruction, while active-active runs multiple locations that normally serve production traffic. These strategies offer different cost, complexity, and recovery characteristics rather than interchangeable labels.

Recovery objectives should determine the design. Recovery time objective, or RTO, is the maximum acceptable time to restore service after disruption. For warm standby, this includes incident detection, the decision to fail over, database promotion, capacity expansion, and traffic redirection. Recovery point objective, or RPO, is the maximum acceptable amount of data loss expressed as time. Asynchronous replication can leave recent writes unavailable in the recovery location, so a running standby does not imply zero data loss. Neither RTO nor RPO is guaranteed by choosing the strategy; both require measurement through realistic exercises.

For example, an online ordering application might run its primary environment in one Region and a smaller application fleet with a replicated database in another. The standby receives application updates and configuration changes alongside production. After a primary-region failure, operators assess replication lag, prevent conflicting writes where possible, promote the recovery database, scale the application fleet, test critical transactions, and redirect clients. If the design permits limited service before scaling completes, recovery can be staged, but restoring full production capacity remains part of the recovery plan.

Capacity and dependencies are common sources of failure. A configured scaling policy does not guarantee that instances will be available during a regional incident. Teams should check service quotas, instance availability, database scaling constraints, startup times, and any need for capacity reservations. Recovery also depends on certificates, secrets, encryption keys, identity permissions, container images, external integrations, and connectivity being available independently of the failed location. DNS failover can help redirect clients, but caching and existing connections can delay the transition.

Warm standby costs more than backup and restore or a minimal pilot light because application resources and data replication run continuously. It usually costs less than maintaining multiple fully provisioned production environments. Replication does not replace backups: accidental deletion, corruption, or malicious changes may propagate to the standby. Maintain protected recovery points, rehearse failover under representative load, and document failback, including data synchronization and controlled traffic movement. High availability across Availability Zones can complement this strategy, but does not by itself provide recovery from a regional outage.