Multi-AZ Instance or Multi-AZ Cluster: Two Different Products With One Confusing Name
For anyone choosing an RDS high availability topology, or explaining to a stakeholder why the standby cannot serve reads. Two Different Products With One Confusing Name
Multi-AZ Instance or Multi-AZ Cluster: Two Different Products With One Confusing Name
For anyone choosing an RDS high availability topology, or explaining to a stakeholder why the standby cannot serve reads.
The question that finally made me write this down came from an application architect in a design review. He had read that Multi-AZ gives you a second copy of the database in another Availability Zone, and he wanted to know why we were also paying for a read replica. If there is already a whole second instance sitting there, why is it not answering queries?
It is a completely reasonable question. The answer is that RDS ships two things with "Multi-AZ" in the name, they behave differently, and only one of them has readable secondaries. The AWS console will happily let you pick either one from the same dropdown, which does nothing to clarify matters.
Why this matters
Pick the wrong one and you either pay for capacity you cannot use, or you build a failover story that does not match what your RTO document claims. I have seen both. The second is worse, because you find out during an incident.
The two options are a Multi-AZ DB instance deployment (the original, one primary and one standby) and a Multi-AZ DB cluster deployment (newer, one writer and two readers). They are not tiers of the same feature. The documentation carries an explicit warning that Multi-AZ DB clusters are not the same as Aurora DB clusters either, which tells you how often that confusion comes up too.
Multi-AZ DB instance deployment
The classic setup. One primary, one standby in a different AZ, synchronous replication between them.
The standby is not readable. The documentation is blunt about it: "The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic." The standby exists to be promoted, nothing else. That is the answer to my architect's question, and the reason a read replica is a separate line item.
Failover is a DNS operation. RDS changes the DNS record for the DB instance endpoint to point at the standby, which means your connection string never changes but your existing connections all die. Plan for that in the application: "you need to re-establish any existing connections to your DB instance."
On timing, the documented range is "typically 60-120 seconds. However, large transactions or a lengthy recovery process can increase failover time." If your SLA promises thirty-second recovery, a Multi-AZ DB instance deployment does not get you there on its own.
Automatic failover triggers are documented as a specific list, which is more useful than most people realize when you are writing a runbook:
- The operating system underlying the instance is being patched in an offline operation
- The primary host is unhealthy
- The primary host is unreachable due to loss of network connectivity
- The instance was modified by the customer
- The primary instance is busy and unresponsive
- The storage volume underlying the primary host experienced a failure
- The user requested a failover
Note the fourth one. A customer modification can trigger failover, which is why a seemingly innocuous instance-class change at 2pm on a Tuesday can produce a connection storm in your application logs.
Multi-AZ DB cluster deployment
Different shape entirely. A writer plus two readers across three AZs in the same Region, and the readers are real, readable endpoints. You get a writer endpoint and a reader endpoint.
The replication is semisynchronous, not synchronous. The distinction is specific and worth getting right: a change needs acknowledgment "from at least one reader DB instance in order for a change to be committed," and it does not require "acknowledgment that events have been fully executed and committed on all replicas." That is the mechanism behind the documented claim that Multi-AZ DB clusters typically have lower write latency than Multi-AZ DB instance deployments. You are waiting on one of two acknowledgments rather than on a full synchronous round trip.
On failover, RDS picks the reader "based on which reader DB instance has the most recent change record." Failover duration then depends on replica lag, and the engines differ in a way that is easy to miss. For MySQL, failover time "depends on replica lag of both remaining reader DB instances" because both must apply unapplied transactions. For PostgreSQL, it "depends on the lowest replica lag of the two remaining reader DB instances." If you run both engines, your failover expectations should not be identical.
Where this requires care
The instance class list is short and restrictive. Multi-AZ DB clusters are supported only on
db.c6gd, db.m5d, db.m6gd, db.m6id, db.m6idn, db.m8gd, db.r5d, db.r6gd, db.r6id, db.r6idn, db.r8gd, and db.x2iedn. Every one of those ends in d. If your standard instance class is a plain db.r6g.xlarge, you cannot use it here, and that may mean a different price point than you modeled. Also worth knowing: db.c6gd is the only family on that list that supports the medium size, so small environments have exactly one option.MySQL wants primary keys everywhere. The documentation recommends, in strong language, that all tables have a primary key to prevent replication errors in RDS for MySQL Multi-AZ DB clusters. If you have inherited a schema with heap tables, audit it before you migrate the topology, not after.
Blue/Green deployments do not support Multi-AZ DB clusters. This one surprised me. If your upgrade strategy depends on blue/green, moving to a Multi-AZ DB cluster takes that tool off the table. It appears in the blue/green limitations list alongside cascading read replicas, cross-Region read replicas, and CloudFormation.
Three AZs means three AZs. The cluster spreads across three Availability Zones in the Region. If you operate in a Region with limited AZ availability for your instance family, check before you commit to the design.
RDS Proxy changes the arithmetic. With a proxy in front, the documentation notes it "can also reduce the downtime for a minor version upgrade of a Multi-AZ DB cluster to one second or less." If minor version patching windows are the thing driving your HA conversation, that combination is worth evaluating before you re-architect anything.
Quick reference
- Multi-AZ DB instance: one standby, synchronous, standby is not readable, failover typically 60-120 seconds via DNS change, all connections drop.
- Multi-AZ DB cluster: writer plus two readers across three AZs, semisynchronous (one reader acknowledgment commits), readers serve read traffic, lower write latency.
- Cluster failover picks the reader with the most recent change record; MySQL waits on both remaining readers, PostgreSQL on the lowest-lag one.
- Cluster instance classes are restricted to twelve NVMe-equipped families, and only
db.c6gdoffersmedium. - Give every MySQL table a primary key before running it on a Multi-AZ DB cluster.
- Blue/green deployments do not work with Multi-AZ DB clusters.
- Neither option is a backup. Both are availability features.
My take
The naming is the problem here, and it is worth being pedantic about in design docs. I now write "Multi-AZ DB instance deployment" or "Multi-AZ DB cluster deployment" in full every single time, even though it is clunky, because "we're Multi-AZ" has caused more confused conversations in my experience than almost any other piece of RDS shorthand. Two engineers can agree that a system is Multi-AZ and be describing different architectures with different failover characteristics and different read capacity.
If you need readable secondaries and lower write latency and your instance family is on the supported list, the cluster deployment is genuinely good. If you need blue/green upgrades, or you are on an instance class that is not on the list, the instance deployment plus a read replica remains the pragmatic answer. Just do not assume the newer option is a superset of the older one, because on upgrade tooling it is not.
Further reading
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article