TopolearnAurora is the default high-end relational option on AWS, and its architecture changes how you think about replicas and failover.
Aurora is AWS's MySQL- and PostgreSQL-compatible engine with a redesigned storage layer. Instead of each instance owning a disk, a cluster has one shared, distributed storage volume that keeps six copies of the data across three AZs and grows automatically. Writes need four of six copies and reads three, so losing an entire AZ (plus one more copy) doesn't lose data.
Compute is separate: one writer and up to 15 readers in any AZs, all reading the same storage. Replicas don't replay a full copy of the data, so replica lag is usually milliseconds, and any reader can be promoted.
Endpoints: the cluster endpoint always points to the writer, the reader endpoint load-balances across readers, and custom endpoints group specific instances (for example, analytics readers). Failover promotes a reader, usually within a minute or less; give readers failover priorities and run at least one reader in another AZ.
Serverless v2 instances (db.serverless) scale capacity in fine-grained Aurora Capacity Units between a minimum and maximum, and can mix with provisioned instances in the same cluster. Scale-to-zero is supported for idle dev databases.
Other features worth knowing:
- Fast cloning: copy-on-write clones of a whole cluster in minutes, ideal for testing on production-like data.
- Global Database: storage-level replication to other Regions, typically under a second of lag.
- I/O-Optimized storage removes per-I/O charges, cheaper when I/O is a large part of the bill.
- Backtrack (MySQL) rewinds a cluster in place without restoring.
Example
aws rds create-db-cluster --db-cluster-identifier orders \
--engine aurora-postgresql --storage-type aurora-iopt1 --storage-encrypted \
--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
--master-username app --manage-master-user-password \
--db-subnet-group-name app-db --vpc-security-group-ids sg-db
for i in 1 2; do # writer + reader; RDS spreads them across AZs
aws rds create-db-instance --db-instance-identifier "orders-$i" \
--db-cluster-identifier orders --engine aurora-postgresql \
--db-instance-class db.serverless
done
aws rds describe-db-clusters --db-cluster-identifier orders \
--query 'DBClusters[0].[Endpoint,ReaderEndpoint]' --output text
# orders.cluster-c1abc.eu-west-1.rds.amazonaws.com orders.cluster-ro-c1abc.eu-west-1.rds.amazonaws.com
aws rds failover-db-cluster --db-cluster-identifier orders # rehearse failover
# Copy-on-write clone for testing
aws rds restore-db-cluster-to-point-in-time --db-cluster-identifier orders-test \
--source-db-cluster-identifier orders --restore-type copy-on-write \
--use-latest-restorable-timeRemember
- One shared six-way storage volume across three AZs; compute is separate
- Writer plus up to 15 readers with millisecond lag; cluster and reader endpoints
- Serverless v2 scales capacity in ACUs, including to zero for idle clusters
- Clones, Global Database and I/O-Optimized storage are key differentiators
Watch out for
- Running a single Aurora instance and assuming the storage replication makes compute highly available too.