Amazon Aurora

Amazon Aurora is AWS’s own relational engine, wire-compatible with MySQL and PostgreSQL. AWS states it delivers up to five times the throughput of MySQL and up to three times that of PostgreSQL on the same hardware. The reason for the difference is architectural: Aurora separates compute from storage, and the storage layer is a purpose-built distributed service rather than a volume attached to one instance.

Aurora is available in two forms — provisioned, described here, and Aurora Serverless, which manages capacity for you.

Storage

The cluster volume is a single virtual volume built from SSDs and spread across three Availability Zones. This happens regardless of how many database instances the cluster has.

• Data is written six ways — two copies in each of three Availability Zones.
• Aurora tolerates the loss of two copies without affecting writes, and three copies without affecting reads.
• Storage grows automatically from 10 GiB, and shrinks again when data is dropped. The maximum cluster volume size is up to 256 TiB depending on engine version.
• The storage layer is self-healing: blocks and disks are scanned continuously for errors and repaired.

Because storage is shared, adding a database instance to a cluster does not copy any data — the new instance simply attaches to the volume that already holds it. That is why Aurora adds and removes replicas in minutes rather than hours.

Two storage configurations are offered. Aurora Standard charges separately for I/O requests and suits moderate-I/O workloads. Aurora I/O-Optimized includes I/O in the instance and storage price and is the cheaper option once I/O exceeds roughly a quarter of the total Aurora bill.

Instances

• One writer instance plus up to 15 read replicas in a cluster.
• Instances can be placed in one, two or three Availability Zones. Two is the minimum for high availability: a writer in one and at least one replica in another.
• The writer handles all write traffic; the writer and every replica can serve reads.
• Replicas are typically within 100 ms of the writer, because they read the same storage rather than replaying a log.
• Failover is automatic and does not require the application to change endpoint.
• The largest Aurora instance classes offer 192 vCPUs and 1,536 GiB of memory (db.r7i.48xlarge, db.r8g.48xlarge). This ceiling moves with each instance generation, so check the current instance-class table rather than designing to a remembered number.

Endpoints

• Cluster endpoint — always resolves to the current writer. Use it for writes, and keep using it after a failover; the DNS record follows the promotion.
• Reader endpoint — load-balances read connections across the available replicas.
• Custom endpoints — route to a named subset of instances, for example to send reporting queries to two large replicas and application reads to the rest.
• Instance endpoints — address one instance directly. Useful for diagnostics, rarely the right thing for an application.

Replica types

Aurora clusters can carry two different kinds of replica.

Aurora replicas (up to 15) read the shared storage volume. They add read capacity, are eligible for automatic failover, have the lowest impact on the writer, and lag by milliseconds.

Binary log replicas use the engine’s own logical replication rather than the shared storage. They lag by seconds rather than milliseconds and are not failover targets, but they can cross Regions, can be given a deliberate replication delay, and can carry a different schema or subset of the data from the primary. Choose them when you need those properties; choose Aurora replicas otherwise.

Both kinds are asynchronous.

Global databases

An Aurora global database has one primary Region that accepts writes and up to 10 read-only secondary Regions.

• Replication happens at the storage layer, using dedicated infrastructure, so the primary carries almost no replication cost.
• Cross-Region latency is typically under a second.
• A secondary can be promoted — planned, as a switchover with no data loss, or unplanned, as a failover after a Region-wide outage.
• A secondary cluster is read-only and can therefore hold up to 16 readers rather than the usual 15.

Backups

• Backups are always on and cannot be disabled.
• Snapshots and backups have no measurable performance impact, because they are taken from the storage layer rather than from an instance.
• Snapshots can be shared with other AWS accounts and copied across Regions — see sharing a database with an external auditor.

When Aurora is worth it

Aurora costs more per instance-hour than the equivalent RDS engine. It earns that back where any of the following matter: fast and automatic failover, replicas that can be added and removed quickly, read scale beyond a handful of replicas, storage that manages itself, multi-Region read distribution, or a workload spiky enough that Aurora Serverless saves more than the premium costs.