The one thing to understand first
Every HA design answers the same two questions: how much data can I lose on failover (RPO, the recovery point) and how long am I down while it happens (RTO, the recovery time). The architecture family decides the answers. Family one fails over between machines that each have a copy of the data; family two fails over between machines that share one durable storage layer.
Family one: synchronous standby on its own storage
RDS Multi-AZ, Cloud SQL regional HA, and Azure Flexible Server zone-redundant HA all work the same way: a standby in another zone is kept current by synchronous replication, so an acknowledged commit exists in two zones before the client is told it committed. RPO is effectively zero for committed transactions. On failure, the provider promotes the standby and repoints DNS — RTO is typically tens of seconds to a couple of minutes, dominated by failure detection and the standby finishing recovery. The standby is generally not readable; it is pure insurance.
Family two: shared-storage failover
Aurora and AlloyDB do not copy data to the failover target because the storage is already shared and already durable across AZs. Promoting a replica is mostly a matter of pointing writes at it; there is no data to replay from scratch, so RTO is short (often well under 30 seconds for Aurora). RPO is governed by the storage quorum, which already holds every acknowledged commit. The catch is cache warm-up: the newly-promoted node starts with a cold buffer cache, so latency is briefly elevated.