Home / AWS

AWSHow-toIntermediate

Amazon Aurora high availability: replicas, failover tiers and endpoints

How Aurora's shared storage and replicas give fast failover, how to set promotion tiers, which endpoints to use for writes and reads, and how to test failovers safely.

Deepak Bhardwaj2 min read

Applies toAmazon Aurora MySQL-Compatible and PostgreSQL-Compatible Editions

How Aurora HA works

  • Storage is a shared cluster volume with six copies across three AZs. It tolerates losing an AZ for writes (4 of 6 quorum) and more for reads.
  • Compute: one writer and up to 15 Aurora Replicas reading the same storage (replica lag typically under 100 ms).
  • If the writer fails, Aurora promotes a replica, typically within about 30 seconds. Without replicas, Aurora must create a new writer instance, which takes much longer.

Important

A production Aurora cluster needs at least one replica in a different AZ. A single-instance Aurora cluster has durable storage but slow recovery from compute failures.

Promotion tiers

aws rds modify-db-instance --db-instance-identifier crm-aurora-2 --promotion-tier 0
aws rds modify-db-instance --db-instance-identifier crm-aurora-3 --promotion-tier 1

Lower tier = promoted first. Give tier 0 to replicas with the same instance class as the writer; a small reporting replica becoming writer causes a performance incident right after the failover.

Endpoints

Endpoint Use
Cluster (writer) endpoint All writes and read-your-own-writes
Reader endpoint Load-balanced reads across replicas
Custom endpoints Group specific replicas (for example, reporting replicas)
Instance endpoints Diagnostics only

Test failover

aws rds failover-db-cluster --db-cluster-identifier crm-aurora --target-db-instance-identifier crm-aurora-2
aws rds describe-db-clusters --db-cluster-identifier crm-aurora \
  --query "DBClusters[0].DBClusterMembers[].{id:DBInstanceIdentifier,writer:IsClusterWriter,tier:PromotionTier}" --output table

Application side

  • Short DNS TTL caching in the app runtime, pool validation, retry on connection loss (same as RDS Multi-AZ).
  • AWS Advanced JDBC/Python/Node.js wrappers with the failover plugin detect the new writer from cluster topology, typically faster than waiting for DNS.
  • RDS Proxy to absorb reconnect storms.

Aurora Serverless v2

Same HA model; set min ACUs on reader instances in tier 0–1 high enough to take writer load immediately after failover (readers in tiers 0–1 scale with the writer).

Monitoring

AuroraReplicaLag, BufferCacheHitRatio, Deadlocks, DBLoad (Performance Insights), and RDS events for failover.

Tip

Fast failover makes a bad query plan or a full connection pool look like a database outage. Check Performance Insights before blaming HA.

Related fixes