Choosing a Topology You Can't Casually Undo

Decision drivers

Multi-AZ DB Cluster exists only for MySQL/PostgreSQL — the decision is void for Oracle, SQL Server, and MariaDB
Whether a standalone read replica already exists or is planned alongside a Multi-AZ Instance (the condition that makes the Cluster topology a cost improvement, not just a feature add)
Topology changes require snapshot + restore, not an in-place modification — budget it as a rebuild
Multi-AZ Cluster requires NVMe-backed instance families (m5d/m6gd/m6id/m6idn/r5d/r6gd/r6id/r6idn/x2iedn/c6gd) — a compute-family constraint, not a checkbox
Relative cost floor: Multi-AZ Instance = 2x base rate; Multi-AZ Cluster = 3x base rate

Production premise

RDS gives you three deployment topologies, and they differ in more than an HA checkbox. Each one is really a choice of replication layer and node count.

Single-AZ is one instance with no standby behind it. There is no automated failover at all. If the instance fails, your only recovery path is restoring from a snapshot.

Multi-AZ Instance adds one passive standby in a second AZ. Its replication happens at the EBS block layer, underneath the database engine: a commit does not return until both AZs have the write on disk. The standby's engine sits idle, though. It does no work until promotion.

Multi-AZ DB Cluster goes further, and it exists only for MySQL and PostgreSQL. It gives you two active, readable standbys, using Raft-consensus semi-synchronous replication over local NVMe drives. A commit needs only one standby to acknowledge. And because both standbys run warm engines that continuously apply the replication stream, promotion skips crash recovery entirely.

Failure mode & inflection point

The failure is building on Multi-AZ Instance and only later needing what Multi-AZ Cluster offers — its read capacity or its write-latency profile. There is no in-place upgrade path between them.

Multi-AZ Cluster requires NVMe-backed instance families (AWS supports db.m5d, m6gd, m6id, m6idn, r5d, r6gd, r6id, r6idn, x2iedn, and c6gd for this topology) and a different storage architecture entirely. Migrating means a snapshot-and-restore, or standing up a parallel cluster and orchestrating logical replication or a Blue/Green cutover.

And if you run SQL Server, Oracle, or MariaDB, the question never opens. Multi-AZ Cluster does not exist for those engines, regardless of scale.

Production guardrail

Default to Multi-AZ Instance for any production workload without a proven multi-reader need.

Move to Multi-AZ DB Cluster only when two concrete facts are both already true. First, you are on MySQL or PostgreSQL. Second, you are already running — or about to provision — a standalone read replica alongside a Multi-AZ Instance. That is the exact pattern the Cluster topology replaces, at a real saving: 3 nodes at 3x base rate instead of 4 nodes at 4x. Failover also drops from 60–120s down to under 35s.

Do not provision Multi-AZ Cluster speculatively, before that read-replica need exists. You would be locking yourself into NVMe instance families and a 3x cost floor for capability you are not using yet.