Amazon Aurora

Cluster compute is separate from storage

Aurora is compatible with MySQL or PostgreSQL protocols but is an AWS-developed engine. Its cluster volume grows automatically up to 128 TiB and keeps six copies of data across three AZs. Compute instances (one writer, up to 15 readers) all share that volume.

flowchart LR
  W["Writer endpoint<br/>cluster-xxx"] --> A["Writer instance<br/>AZ 1a"]
  R["Reader endpoint<br/>cluster-ro-xxx"] --> B["Reader 1<br/>AZ 1b"]
  R --> C["Reader 2<br/>AZ 1c"]
  A --> S["Shared cluster volume<br/>6 copies, 3 AZs"]
  B --> S
  C --> S
  %% step W: Applications send writes to the writer endpoint, which always points to the current writer.
  %% step A: There is one writer at a time.
  %% step R: The reader endpoint spreads new connections across the readers.
  %% step B: Readers read the same storage, so replica lag is usually only milliseconds.
  %% step C: If the writer fails, a reader is promoted, typically in about 30 seconds, and the writer endpoint moves.
  %% step S: Storage survives losing an entire AZ, because data is written to six copies in three AZs.

Endpoints

The writer endpoint (cluster endpoint) directs writes to the current writer. The reader endpoint balances new connections across replicas; applications do not write through it. A custom endpoint groups instances for workloads such as analytics on larger readers, and instance endpoints reach one instance directly (rarely needed). Because endpoints are DNS names, configure short DNS caching in the client so failover is quick.

Availability and scaling

Replica promotion tiers (0 highest) influence which reader becomes writer on failover. Aurora Auto Scaling adjusts reader count based on CPU or connections, not the writer. Aurora Serverless v2 scales the capacity of each instance in small steps (ACUs) within a minimum and maximum, which fits variable or unpredictable load; it can be mixed with provisioned instances in one cluster.

Aurora versus RDS

Backup and recovery features

Aurora backs up continuously to S3 with PITR like RDS. Backtrack rewinds a cluster in place to an earlier time in seconds; it exists only for certain Aurora MySQL configurations and does not replace backups. Cloning creates a copy-on-write copy of a cluster quickly for testing.

Global Database

Aurora Global Database has a primary Region and up to several read-only secondary Regions with storage-level replication, typically under a second of lag, for low-latency reads and DR. Planned switchover or unplanned failover promotes a secondary; it needs a runbook and application reconnection.

Traps: writing through the reader endpoint; thinking Aurora Auto Scaling adds writers; treating Backtrack as a backup.