"The Log is the Database"
In a traditional database, a write operation involves multiple steps: write to a transaction log, write dirty pages to a buffer pool, eventually flush those pages to disk, and send all of this data across the network to a standby replica. Aurora eliminates most of this by adopting a principle called "the log is the database."
When your application commits a transaction, Aurora only sends redo log records — the minimal description of what changed — to the storage layer. The storage nodes apply those log records to reconstruct the actual data pages themselves. This dramatically reduces the amount of data sent over the network (Aurora claims a 7.7x reduction in I/O compared to MySQL) and allows commits to return to the application much faster.
The 4/6 Quorum
Aurora's storage volume is automatically divided into 10 GB segments called Protection Groups. Each segment is replicated 6 times across 3 Availability Zones (AZs):
- 2 copies in AZ A
- 2 copies in AZ B
- 2 copies in AZ C
This replication is managed entirely by the storage layer. The compute instance writes once; the storage layer handles distributing that write to all 6 copies.
Write Quorum (4/6): A write is considered durable when at least 4 of the 6 storage nodes acknowledge it. This means Aurora can tolerate losing an entire AZ (2 copies) plus one additional node and still complete writes successfully.
Read Quorum (3/6): To reconstruct a consistent view of data, Aurora needs to confirm 3 copies agree. In practice, reads usually come from the local buffer cache and never touch the quorum mechanism.
Why these numbers matter: The quorum math guarantees that the 4 nodes that acknowledged a write and the 3 nodes needed for a read will always overlap by at least 1 node. This overlap ensures you can never read data that hasn't been durably written.
Self-Healing Storage
Because the storage layer continuously monitors all 6 copies of every segment, it can detect corruption or disk failure without any involvement from the compute layer. When a bad block is detected, the storage layer automatically reconstructs it from the other 5 healthy copies — in the background, while your database continues serving traffic. The compute node never pauses, never retries, and never even knows a repair happened.
This is a fundamental shift from traditional databases, where a disk failure would trigger a failover event, a period of downtime, and manual intervention to rebuild the standby.
Interviewers frequently ask: "How does Aurora achieve faster failover than standard RDS Multi-AZ?" The key answer is storage architecture. In RDS Multi-AZ, the standby must replay a transaction log to catch up after a primary failure. In Aurora, all replicas are already reading from the same shared storage volume — there is no replay needed. The new primary simply starts accepting writes to the same storage the old primary was using. Failover typically completes in under 30 seconds.