RDS Multi-AZ: instance deployment vs DB cluster, failover behaviour and app readiness

#Two Multi-AZ flavours

#Failover triggers

AZ outage, primary host or storage failure, instance class change, OS patching, or a manual reboot with failover. The DNS name of the endpoint is updated to the new primary.

#Test it

aws rds reboot-db-instance --db-instance-identifier crm-prod --force-failover
# DB cluster:
aws rds failover-db-cluster --db-cluster-identifier crm-cluster
aws rds describe-events --source-identifier crm-prod --source-type db-instance --duration 60

Measure from the application's point of view: how long until requests succeed again?

#Make the application ready

• DNS caching: Java caches DNS forever by default with a security manager; set networkaddress.cache.ttl=5. Connection pools must drop dead connections.
• Pool validation: test-on-borrow or a short maxLifetime, so connections to the old primary are discarded.
• Retries with backoff for connection errors and read-only errors during the switchover.
• Consider RDS Proxy: keeps client connections open and reconnects to the new primary, often cutting failover impact to seconds.
• AWS Advanced JDBC Wrapper (and similar drivers) monitor topology and fail over faster than DNS.

#Read replicas are not HA (alone)

Read replicas are asynchronous and need manual promotion (or Aurora). Use them for read scaling or cross-region DR; use Multi-AZ for HA. You can combine both.

#Monitoring

• RDS event subscription for failover, failure and maintenance categories to SNS.
• ReplicaLag on DB cluster readers (should be near zero).

aws rds create-event-subscription --subscription-name crm-events --sns-topic-arn arn:aws:sns:ap-south-1:111122223333:db-alerts \
  --source-type db-instance --source-ids crm-prod --event-categories failover failure maintenance

Note

Multi-AZ protects against AZ and hardware failure, not against bad data. A DELETE without WHERE is replicated to the standby in milliseconds. Keep PITR and snapshots for that.