Choosing a Topology You Can't Casually Undo

RDS deployment topology isn't an HA toggle — it's a choice of replication layer and node count. Single-AZ has no automated failover at all (restore from snapshot is the only recovery path). Multi-AZ Instance adds one passive standby, replicated synchronously at the EBS block layer — a commit doesn't return until both AZs have the write on disk, but the standby's database engine sits idle until promoted. Multi-AZ DB Cluster (MySQL/PostgreSQL only) adds two active readable standbys using Raft-consensus semi-synchronous replication over local NVMe — a commit needs only one standby to acknowledge, and because both standbys run warm engines continuously applying the replication stream, promotion skips crash recovery entirely.

Needing Multi-AZ Cluster's read capacity or write-latency profile after you've already built on Multi-AZ Instance. There's no in-place upgrade path — 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, so migrating means a snapshot-and-restore or standing up a parallel cluster and orchestrating logical replication or a Blue/Green cutover. And if you're on SQL Server, Oracle, or MariaDB, this option doesn't exist regardless of scale.