Failover transfers service responsibility from an unavailable primary component to an available replacement. The replacement may be a standby database, replica cache node, or virtual machine in another Availability Zone. section 1.2.3 section 13.2
A typical database failover keeps a primary and standby synchronized. When the primary fails, the service promotes the standby and redirects clients, often through DNS. RDS detects and performs this process automatically without human intervention. section 10.5
Common AWS failover patterns include:
- RDS Multi-AZ uses a standby database; clients continue through the updated DNS name after promotion. section 10.5
- Redis cluster mode elects new primaries through a configuration endpoint, avoiding DNS and usually completing faster than a single-primary deployment. section 11.2.4
- Multi-AZ web architectures distribute virtual machines across data centers, while a load balancer sends requests only to healthy machines. section 1.2.3
Database primary failure
An application sends requests to an RDS primary while data is synchronously replicated to its standby. If hardware or network failure makes the primary unavailable, RDS promotes the standby and updates DNS so clients reach the former standby. section 10.5
Figure 10.6 The client fails over to the standby database if the primary database fails, using DNS resolution.
Trace how clients reach the standby database after the primary fails and DNS resolution changes. section 10.5
Failover improves availability but adds cost and does not remove every outage concern. RDS charges for both primary and standby instances. DNS-based Redis failover may take about 1–1.5 minutes, while cluster mode can elect a primary in under 30 seconds. A whole Availability Zone outage can also expose storage and IP-address limitations. section 10.5 section 11.2.4 section 13.2
