In Amazon RDS, how does a Multi-AZ deployment differ from a read replica, and which of the two would you add to relieve a database whose CPU is saturated by reporting queries?

## The question behind the question Interviewers ask this because the two features look similar on the console page — both create a second copy of your database in another Availability Zone — and candidates who have only read the marketing routinely answer "Multi-AZ, for high availability and to spread the read load". The second half of that sentence is wrong, and it is wrong in a way that produces a real incident: you pay double for an instance you believe is absorbing traffic, and it absorbs none. ## What a Multi-AZ DB instance deployment actually is An Availability Zone (AZ) is one or more physically separate data centres inside an AWS Region, with independent power and networking. A Multi-AZ *DB instance* deployment gives you one primary and one standby in a different AZ of the same Region. RDS keeps the standby's storage in step with the primary synchronously — a commit is not acknowledged to your client until the write is durable on both sides — which is why Multi-AZ adds a little write latency and why it protects you against losing committed transactions if the primary's AZ disappears. The crucial property is that **the standby is not addressable**. It has no endpoint you can connect to, it cannot serve a `SELECT`, and it does not reduce load on the primary by one query. Its whole purpose is to be there when RDS decides a failover is required: an AZ outage, primary host or storage failure, an instance-class change, an OS or engine patch, or a manual `reboot-db-instance --force-failover`. RDS then makes the standby the primary and repoints the DNS record behind your single writer endpoint at the new host. AWS documents this as typically completing in 60–120 seconds for a Multi-AZ DB instance deployment. Your application does not change its connection string; it does have to survive dropped connections and reconnect, which is why short DNS TTL handling and connection-pool validation matter on RDS. ## What a read replica is A read replica is a *separate DB instance* that RDS creates from a snapshot of the source and then keeps up to date using the engine's native asynchronous replication. Because the replication is asynchronous, the replica acknowledges nothing back to the writer, so it adds no write latency — and it can trail the source. It has its own endpoint, its own instance class (it need not match the source), and it can be placed in another AZ or another Region. Asynchronous also means **you must send reads there deliberately**. RDS does not route traffic for you: your application, your ORM's read/write splitting, or a proxy layer decides which queries go to the replica endpoint. And RDS will never promote a read replica automatically when the source dies; promotion is an explicit `promote-read-replica` API call that turns the replica into an independent, writable instance and permanently severs replication. ```bash aws rds create-db-instance-read-replica \ --db-instance-identifier prod-db-reports \ --source-db-instance-identifier prod-db \ --db-instance-class db.r6g.xlarge ``` ## Choosing for the reporting workload A writer pinned at high CPU by analytical scans is a read-capacity problem, so the answer is a read replica, sized independently of the writer and given its own endpoint for the BI tool. That isolates the scan-heavy workload's CPU and buffer-cache pressure from transactional traffic. Multi-AZ would change nothing about the CPU picture — it would only mean that when the overloaded primary falls over, a second, equally overloaded instance takes its place. ## They are not alternatives Production systems usually run both: Multi-AZ on the writer so an AZ failure is a blip instead of an outage, plus one or more read replicas for reporting or read-heavy endpoints. You can also enable Multi-AZ *on a replica*, so the replica itself has a standby and survives losing its own AZ. What Multi-AZ gives that replicas do not is a guarantee about committed data at failover time; what replicas give that Multi-AZ does not is queryable capacity and cross-Region reach. ```bash aws rds modify-db-instance \ --db-instance-identifier prod-db \ --multi-az \ --apply-immediately ``` ## The one-line summary to say out loud Multi-AZ is a *durability and availability* feature with an invisible standby and one endpoint; read replicas are a *capacity and locality* feature with visible endpoints and no automatic failover. Anything about read scaling is answered with replicas.