Keep data available—and recover the past

First ask whether the data remains intact. Then ask whether the application can read and write it now. Next ask whether old data can be recovered after deletion or corruption. Finally ask whether the database can accept the current number of client connections.

These are different requirements. A durable backup does not serve live traffic. A live replica can copy a bad deletion. A connection proxy does not add database compute. Write down failure scope, RPO, RTO, read freshness, write ownership, and connection demand separately.

Name the exact service mode. Traditional RDS Multi-AZ uses a synchronous standby for availability. A read replica is asynchronous and serves eligible reads. Aurora uses distributed cluster storage and replica instances with its documented failover behavior.

For object and file services, live replication and retained history have the same separation. Replication can improve location resilience, while versioning, retention, or backup protects an earlier state. Verify the exact mode instead of transferring relational words by analogy.

For a traditional RDS Multi-AZ DB instance, the standby is not a read target. Its job is automatic failover. A read replica executes lag-tolerant reads and may be promoted, but it does not provide the same synchronous automatic failover contract.

Amazon RDS Proxy pools and reuses supported database connections. Use it when connection churn is the measured problem. It does not make a Single-AZ database Multi-AZ, execute report queries, or preserve deleted history.

Combining Multi-AZ, readers, and Proxy can be correct because the requirements are independent. Say which mechanism handles each requirement instead of saying the database is simply “more resilient.”

Read routing must match the freshness requirement. Reports may tolerate observed replica lag; a customer checking the order they just placed may need the writer path. Adding a reader without changing query routing adds cost without moving work.

Backups, point-in-time recovery, snapshots, and versioning preserve earlier state. Set retention and frequency from the RPO. Restore into a safe location and measure whether the application becomes usable inside the RTO.

Monitor replica lag, backup age, writer identity, failover time, restore time, and connection errors. During a drill, record who can write before and after promotion, how clients reconnect, and how failback avoids two writers.

Run a deletion exercise separately from a failover exercise. Successful failover proves live availability; it does not prove recovery of a record deleted ten minutes earlier. Protect recovery copies with scoped roles, keys, networks, retention, and deletion authority.

Cost each mechanism separately: standby capacity, reader compute, proxy usage, retained recovery points, and restore exercises. Remove a mechanism only when its requirement is removed—not because another resilience feature has a similar name.

A restore is complete only when authorised clients can use the recovered application and the team knows which writer is authoritative.