Failover

Failover is a recovery mechanism that transfers responsibility from an unavailable or unhealthy component to another component capable of doing its work. The component might be an application server, database, network endpoint, or an entire deployment. Failover supports high availability by reducing the time a service remains unavailable after a failure. High availability is the objective; failover is one mechanism used to achieve it.

A practical failover design requires more than a spare server. It needs a way to detect failure, a healthy alternative with sufficient capacity, and a mechanism to redirect traffic or transfer processing responsibility. Health checks should reflect whether a component can perform useful work, not merely whether its operating system responds. Detection thresholds must balance fast recovery against unnecessary transfers caused by temporary network problems or brief performance slowdowns.

In AWS, a Region contains multiple Availability Zones, and each Availability Zone consists of one or more discrete data centers with independent power, networking, and connectivity. Deploying application instances across multiple Availability Zones reduces exposure to a single zone failure. For example, a web application can run instances in two zones behind a load balancer. If instances in one zone become unhealthy, the load balancer can direct new requests to healthy instances in the other zone. Multiple instances located only in one zone do not provide the same protection against a zone-wide disruption.

Application availability also depends on the data tier and other dependencies. A web tier distributed across zones can still become unavailable if it depends on a single database without a recovery alternative. A database failover design typically replicates data to another database resource and promotes or selects an eligible replica when the primary fails. Applications must handle broken connections, reconnect to the appropriate endpoint, and retry operations safely. Keeping user sessions only in an individual application server's memory can also interrupt users when traffic moves elsewhere.

Active-passive designs keep an alternative ready to take over, while active-active designs serve traffic from multiple resources and shift work to surviving resources after a failure. Either approach requires enough surviving capacity to handle the expected workload. Automatic scaling can replenish capacity, but provisioning takes time and should not be treated as instant protection against a sudden zone failure.

Failover involves cost and consistency trade-offs. Redundant capacity, data replication, monitoring, and testing increase expense and operational complexity. Asynchronous replication can leave a promoted replica missing recent writes. Synchronous replication can reduce that risk but adds coordination and latency. Recovery time objective describes the target time to restore service, while recovery point objective describes the acceptable amount of data loss measured in time.

Failover does not necessarily preserve existing connections, guarantee zero downtime, or protect against every failure. Multi-zone deployment addresses zone-level failures within a Region; protection against a regional outage requires a separate cross-Region strategy. Backups support restoration but do not, by themselves, provide a ready failover destination. Test failure scenarios regularly, prevent multiple nodes from incorrectly acting as the sole writer, and plan failback—the controlled return to the preferred resource after recovery.