Your production Amazon RDS PostgreSQL database runs Multi-AZ in one Region. An interviewer asks how you would survive the loss of that entire Region. What AWS mechanisms do you reach for, and what does each cost you in recovery point and recovery time?

## Start by naming what Multi-AZ does not do An Availability Zone failure and a Region failure are different events with different answers. Multi-AZ places a standby in a second AZ of the *same* Region and fails the writer endpoint over automatically. Every part of that — the standby, the endpoint, the automated backups — lives in one Region. If the requirement is to survive losing that Region, Multi-AZ is not an answer, and saying so first is what makes the rest of the answer credible. ## Mechanism one: cross-Region read replica You create a read replica in another Region from the source instance's ARN: ```bash aws rds create-db-instance-read-replica \ --db-instance-identifier prod-db-dr \ --source-db-instance-identifier arn:aws:rds:eu-west-1:123456789012:db:prod-db \ --region us-east-1 ``` The replica is a full, running DB instance receiving changes asynchronously over the AWS backbone. It is queryable, which means the DR copy can also serve read traffic local to that Region in normal times. Recovery is a deliberate act: ```bash aws rds promote-read-replica --db-instance-identifier prod-db-dr ``` Three properties matter in an interview. Promotion is **manual** — RDS never promotes a replica on its own, so a real plan needs a human decision or your own automation with a clear trigger. Promotion is **one-way**: the promoted instance becomes an independent, writable database and the replication link is gone for good; you cannot demote it back, and re-establishing the original topology later means building a fresh replica in the other direction. And promotion **involves a brief restart**, so it is fast but not instantaneous. The recovery point is bounded by how far behind the replica was at the moment the Region became unreachable — which is why the replica's replication metrics are something you watch continuously rather than during an incident. The recovery time is the shortest of the three options because the instance already exists and is already hydrated. ## Mechanism two: cross-Region automated backup replication RDS can replicate the automated backup set — the snapshots plus the transaction logs — to a second Region, giving you point-in-time restore there. You pay for storage rather than for a running instance, which for a large database is a substantial difference. The price is recovery time. Recovery means calling a restore in the second Region, which **provisions and hydrates a brand-new DB instance**. For a multi-terabyte database that is tens of minutes at best, and often longer, before anything can serve traffic. The recovery point is governed by how current the replicated logs are — good, but the total outage is dominated by the restore, not by the gap. ## Mechanism three: copied snapshots `copy-db-snapshot` into the DR Region, on whatever cadence you schedule. Cheapest and simplest, and the recovery point is as coarse as your copy interval — if you copy nightly, you can lose a day. It is the right answer for databases that can be rebuilt or whose data is reconstructible from an upstream system, and the wrong answer for anything transactional. ## The part candidates forget: everything around the database A promoted replica or a restored instance is useless in a Region where nothing else exists. A workable DR plan pre-provisions: - **Network**: a VPC, subnets across AZs, a DB subnet group, route tables and security groups that permit your application tier. - **Configuration**: parameter groups and, where the engine uses them, option groups — a restored instance defaults to the AWS defaults unless you name yours. - **KMS keys**: an encrypted database's snapshots and replicated backups must be encrypted with a key **in the destination Region**, so that key and its policy have to exist before the incident, not during it. - **Naming and routing**: something the application resolves — a Route 53 record or a config value — that can be repointed without a code deploy. - **Credentials**: the secret the application uses, replicated to the DR Region, since Secrets Manager secrets are regional. ## Choosing, and saying why The honest framing is a tiering exercise. For a payments-grade system the recovery-point budget is small enough that only a live cross-Region replica qualifies, and you accept the cost of a second running instance plus the data-transfer charges for continuous cross-Region replication. For an internal service that can be down an hour, replicated automated backups give point-in-time recovery at storage prices. For a reconstructible dataset, nightly snapshot copies are proportionate. What an interviewer is listening for is that you attach numbers to each option, that you name promotion as manual and irreversible, that you do not confuse Multi-AZ with regional resilience, and that you say the plan is only real if it has been rehearsed — a DR mechanism nobody has exercised is a hypothesis.