SysPad › Lessons › database lessons › Amazon Aurora

How Amazon Aurora works

MySQL/PostgreSQL-compatible relational database with up to 5× MySQL or 3× PostgreSQL performance. Distributed storage auto-scales to 128 TiB. Supports up to 15 low-latency read replicas.

Aurora’s big trick is almost philosophical: it stopped treating the database as a box with a disk inside, and turned the storage into its own distributed service. That single split is why it can keep six copies of your data, lose an entire data centre, and barely notice.

What you will learn

Why does separating compute from storage change what a "replica" even is?
How can Aurora lose a whole Availability Zone without losing a single write?
Why do Aurora’s read replicas lag by milliseconds when RDS replicas can lag by seconds?
When is plain RDS actually the smarter (and cheaper) choice?

The database, split in two

In a normal database the compute and its disk are one unit. Aurora pulls them apart: instances are stateless compute, and your data lives in a separate shared distributed storage layer that auto-grows to 128 TiB (up to 256 TiB on current engine versions).

Once storage is shared, adding a reader no longer means copying the whole dataset, which reshapes everything that follows.

Six copies, four to win

The storage service keeps six copies of your data, two in each of three Availability Zones. A write is considered durable as soon as four of the six acknowledge it; a read needs three.

That quorum math means Aurora can lose an entire AZ (two copies) and one more disk and still not lose a committed write. Durability is structural, not a backup you hope ran.

⚓ This is why Aurora is a default for systems that treat data loss as unacceptable.

Why ship "redo log records" instead of the actual data pages?

A traditional engine writes whole modified pages (plus logs) over the network. Aurora sends only the compact redo-log records and lets the storage tier materialise pages on demand. Dramatically less network traffic per write is a big part of Aurora’s performance story; AWS’s published benchmarks claim up to 5x MySQL and 3x PostgreSQL throughput (a vendor benchmark, not a guarantee for every workload).

Replicas that barely lag

Aurora supports up to 15 read replicas, and they all read the same shared storage volume rather than holding private copies. So a replica isn’t catching up by copying data, it’s reading the one true copy.

The payoff: replica lag is typically well under 100 ms (versus seconds for classic RDS), and failover is fast because a reader can be promoted to writer in seconds without rebuilding any data.

Serverless v2: capacity as a dial

With Aurora Serverless v2 you don’t pick an instance size; you set a range of Aurora Capacity Units (each ACU is roughly 2 GiB of memory plus matching CPU) and Aurora scales compute up and down in 0.5-ACU steps to match load, even down to zero (auto-pause) when the database is idle.

When plain RDS is the better call

Aurora is MySQL- and PostgreSQL-compatible, not every engine (no SQL Server or Oracle), and its storage and I/O pricing model can cost more than a modest RDS instance for small or low-traffic databases.

If you need a specific engine Aurora doesn’t offer, want the simplest possible cost model, or your database is small and quiet, classic RDS is often the pragmatic choice. Aurora earns its keep at scale and where its durability and fast failover matter.

Flashcards

In Aurora, what happens to the dataset when you add a 15th read replica?: Nothing is copied. All replicas read the same shared distributed storage, so adding a reader just adds compute that attaches to the existing volume.
An entire Availability Zone holding Aurora data goes dark. Do you lose committed writes?: No. With six copies across three AZs and a 4-of-6 write quorum, losing one AZ (two copies) still leaves a durable majority. No committed write is lost.
What does an Aurora writer actually send to the storage layer on a write?: Just the compact redo-log records, not full data pages. Storage rebuilds pages itself, which slashes network I/O and is central to Aurora’s speed.
Why can Aurora readers serve near-fresh data while RDS replicas may be seconds behind?: Aurora readers query the same shared volume directly (lag usually under 100 ms). Classic RDS replicas keep separate copies updated asynchronously, so they lag more.
Traffic is bursty and unpredictable and you don’t want to size an instance. Which Aurora mode?: Aurora Serverless v2 scales compute (in ACUs) up and down automatically to track load, so you pay for what the workload actually needs.

Sources

Open the SysPad canvas · Official Amazon Aurora documentation