Multi-AZ vs Multi-Region for RDS / Aurora — what the failover actually buys you

The architecture review meeting asks the same question every time a SaaS gets serious about uptime: “we have Multi-AZ on the RDS, do we also need Aurora Global Database in a second region?” The answer is almost never the same as the question being asked. Multi-AZ covers the failure modes that actually happen — instance hardware, an AZ network blip, a patch that goes sideways. Multi-Region covers the rare ones — a regional outage, a regulator who wants the data physically elsewhere, a customer in another continent who needs sub-100ms reads. Confusing the two means paying for the wrong protection and still being exposed.

What’s happening

Multi-AZ and Multi-Region are two different replication topologies built on two different consistency models.

Multi-AZ (single region, synchronous standby). Provisioned on RDS as MultiAZ: true and on Aurora as a multi-AZ cluster with reader instances in separate AZs. On RDS, writes commit to both the primary and the standby before the client acknowledgement returns — the standby is a hot copy at the storage layer. On Aurora, the cluster volume is replicated across six storage nodes spread over three AZs, so the storage layer is inherently multi-AZ even with a single writer. Failover is automatic, triggered by health checks, and the DNS endpoint flips. Real-world failover times: 30–90 seconds on RDS, 10–30 seconds on Aurora.

Multi-Region (Aurora Global Database, async secondary). A second Aurora cluster in another region replicates from the primary using the cluster volume’s storage-layer replication, with a typical lag of under one second under normal load. The secondary is read-only until you explicitly promote it. Promotion is a manual API call (or a Step Function you wire up), it breaks the replication link, and it takes a minute or two to complete. RTO with a manual runbook is 5–15 minutes; with a fully automated promote, 2–5 minutes. RPO is the replication lag at the moment of failure — sub-second in steady state, potentially longer if the primary region went dark mid-batch.

The trade-offs land like this:

The conversation gets confused because both features get sold as “high availability.” They are not the same kind of HA. Multi-AZ is operational HA — it keeps the database up through the failures that happen multiple times a year. Multi-Region is disaster recovery — it keeps the business running through the failures that happen once a decade.

How to verify

Start by asking what you are actually trying to protect against. The honest answer for most SaaS is “we want our database to survive an EC2 reboot in one AZ at 03:00 on a Sunday.” That is Multi-AZ. The dishonest answer is “we want full regional failover” with no runbook, no DNS strategy, and no plan for the application tier — that is paying for Multi-Region while operating like Multi-AZ.

Check what you have today. For RDS:

aws rds describe-db-instances \
  --db-instance-identifier prod-db-1 \
  --query 'DBInstances[].[DBInstanceIdentifier,MultiAZ,AvailabilityZone,SecondaryAvailabilityZone]' \
  --output table

For Aurora, the writer is in one AZ but the cluster volume spans three:

aws rds describe-db-clusters \
  --db-cluster-identifier prod-aurora-1 \
  --query 'DBClusters[].[DBClusterIdentifier,AvailabilityZones,MultiAZ,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output json

For Aurora Global, the secondary shows up as a separate cluster in another region linked back to the primary:

aws rds describe-global-clusters \
  --global-cluster-identifier prod-global-1 \
  --query 'GlobalClusters[].[GlobalClusterIdentifier,Status,GlobalClusterMembers[*].[DBClusterArn,IsWriter]]' \
  --output json

Then verify the application tier is ready for the topology you chose. Multi-AZ failover changes the writer endpoint’s underlying IP, not the DNS name — the application has to handle a brief connection drop and reconnect within 60 seconds. Connection pools with stale-connection detection (pgbouncer, RDS Proxy, or HikariCP with validationQuery) handle this; connection pools without it stall for 5–10 minutes until TCP keepalive expires.

For Multi-Region, the verification list is longer. The application must be able to redirect to the new region. Route 53 health-checked records, ALB target groups in both regions, the application’s secrets and config replicated to the secondary region, S3 buckets cross-region replicated, an automated promote-and-cutover runbook — all of it has to be drilled. A Multi-Region database with no application-tier failover plan is a Multi-AZ at double the cost.

The fix

Pick the topology that matches the failure modes you actually take seriously.

Default for production SaaS: Multi-AZ. Every production database, every environment that takes a real customer write, runs Multi-AZ. This is non-negotiable. The cost is roughly a 100% premium on the database compute line, sometimes less on Aurora because the reader is also a usable read endpoint. The premium buys automatic failover from AZ-scoped failures, which happen often enough to be worth the line item.

Add Multi-Region only when the requirement is real. Real requirements are: regulatory (the data must be available from a second region for compliance reasons), commercial (an SLA promises continued service through a regional outage), or geographic (a substantial customer base needs reads inside their region). “We might want it someday” is not a real requirement.

If you go Multi-Region, build the application-tier failover first. The database promotion is the easy part. The hard part is the secrets in Secrets Manager, the SQS queues, the S3 buckets, the cached config in ElastiCache, the API Gateway custom domains, the SAML federation pointing at the primary region’s identity provider. Database promotion without application failover gets you a healthy database serving traffic that cannot reach it.

Drill the failover quarterly. Multi-AZ failover is testable with aws rds reboot-db-instance --force-failover — schedule it during a quiet window, watch the application reconnect, log the time. Multi-Region promotion is testable in a non-prod global cluster — promote the secondary, run a smoke test, then re-establish the global cluster in the other direction. A failover topology that has not been exercised in production within the last quarter is unverified, regardless of what the documentation says.

Do not run Multi-Region with a single-region application. This is the most common waste of spend we see — Aurora Global Database paid for in full, with no runbook to actually use it, no DNS strategy, and an application tier that points at a hardcoded primary-region endpoint. If the runbook is “page someone and figure it out,” the second region is paperwork, not protection.

The decision is mostly binary. Either the business takes a regional outage seriously enough to pay for the full Multi-Region apparatus and drill it, or it does not. Sitting in the middle — paying for Aurora Global Database but never using it — is the worst of both worlds.

Stack Harbor designs and operates production RDS / Aurora topologies as part of Managed AWS and the ongoing Managed Cloud Ops layer. If your database posture is “Multi-AZ checkbox + hope,” start with an infrastructure consult.