High Availability Across AZs and Regions

A single point of failure is any one component whose failure takes the whole workload down with it — and a database sitting in a single Availability Zone is a classic example. Amazon RDS Multi-AZ (with one standby) removes it: RDS automatically provisions a synchronous standby replica in a different AZ, keeps it continuously up to date, and — during planned maintenance, an instance failure, or an AZ disruption — automatically promotes it. The DB instance's endpoint doesn't change, so most applications reconnect without any reconfiguration. AWS states that this failover can complete in as little as 60 seconds.

The standby exists purely for failover. It is not the same feature as a read replica, which is a separate, asynchronously updated copy you create specifically to serve read traffic and reduce load on the primary.

aws rds modify-db-instance \
  --db-instance-identifier orders-db \
  --multi-az \
  --apply-immediately

High availability isn't only about the database surviving a failure — it's also about the database surviving a flood of connections. A workload built on AWS Lambda can scale to hundreds of concurrent invocations in seconds, and if each one opens its own direct database connection, the database can run out of connection slots long before it runs out of compute. Amazon RDS Proxy sits between the application and the database, pooling and reusing a much smaller number of backend connections across many client connections. It also improves failover: because the proxy — not the application — holds the connections, it can reroute traffic to a newly promoted instance without every client having to reconnect from scratch, and it can authenticate using AWS Secrets Manager or IAM rather than a credential baked into the application.

Within one Region, an Application Load Balancer and Multi-AZ cover most availability needs. Across Regions, Amazon Route 53 decides which Region a request even reaches. Simple routing answers with a single resource. Weighted routing splits traffic across resources in proportions you set — useful for a gradual migration or a canary release. Latency routing sends each request to the Region with the best measured latency for that resolver. Failover routing is built for active-passive high availability specifically: Route 53 answers with the primary resource as long as its health check passes, and switches to the secondary the moment that health check fails.