Database Multi-AZ: High Availability vs. Read Scaling
Multi-AZ deployment is like a hot spare database in another datacenter for automatic failover. It's for critical systems where downtime is costly. The footgun is assuming all standbys serve reads; only the 'cluster' type does, not the 'instance' type.
Why it exists
A single database in one physical location is a single point of failure. If its hardware, network, or entire data center fails, your application goes offline. Multi-AZ deployments were created to solve this by providing automated redundancy across physically separate locations (Availability Zones).
The mental model
Think of it as database insurance. A standard 'Multi-AZ DB instance' is like having a fully-synced clone of your database sitting idle in another building, ready to become the primary at a moment's notice. A 'Multi-AZ DB cluster' is like having two such clones, but they are also allowed to answer phone calls (serve read traffic) while they wait.
How it works
Amazon RDS maintains a synchronous replica of your primary database in a different Availability Zone (AZ). For a 'Multi-AZ DB instance' deployment, there is one primary and one standby. Data is written to the primary and synchronously replicated to the standby. If the primary fails, RDS automatically promotes the standby to become the new primary. For a 'Multi-AZ DB cluster' deployment, there is one writer instance and two reader instances in different AZs. These readers can serve read traffic, and if the writer fails, one of the readers is promoted to become the new writer.
When to use it
Use Multi-AZ for any production database where availability is critical. It's standard for applications that cannot tolerate extended downtime, like e-commerce or financial systems. The 'DB cluster' option is specifically for when you need both high availability and the ability to scale read operations across multiple instances.
When not to use it
It's often overkill for development, testing, or non-critical internal tools where a brief outage is acceptable, as the standby resources incur costs. Crucially, the simpler 'DB instance' deployment is NOT a solution for read scaling, as its standby does not serve traffic. If you only need to offload reads without the automatic failover, a standalone read replica might be a better fit.
One canonical example
A team runs a critical PostgreSQL database using a 'Multi-AZ DB instance' deployment. The primary is in 'us-east-1a' and the standby is in 'us-east-1b'. During a routine maintenance window, the primary instance's underlying hardware fails. RDS automatically detects the failure, performs a DNS switchover, and promotes the standby in 'us-east-1b' to be the new primary. The application experiences a brief interruption but recovers automatically without manual intervention.
Interview question
When considering Multi-AZ for a critical database, which statement is true about its read scaling capabilities?
- a.Multi-AZ DB instances provide read scaling through their synchronously replicated standby.
- b.Read scaling is not a feature of Multi-AZ; it only provides high availability.
- c.All Multi-AZ deployments automatically scale reads using their standby instances.
- d.Only Multi-AZ DB clusters can distribute read traffic across multiple instances.Correct
Why? this is the answer
The card specifies that 'Multi-AZ DB cluster' deployments include reader instances that can serve read traffic, enabling read scaling. In contrast, 'Multi-AZ DB instance' deployments have an idle standby that does not serve reads, making option C incorrect.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on cloud — each one lists the topics its interview covers.
See open roles