Why architecture matters here
Conventional MySQL high availability is an amplification machine. The engine flushes 16KB pages for every dirty buffer, writes each page twice (doublewrite) to survive torn writes, appends redo and binlog, and then ships binlog events to replicas that re-execute or re-apply them — each replica repeating the same page-write amplification locally. Synchronous semi-sync replication adds a network round trip to every commit, priced at the slowest participant. Failover means promoting a replica whose apply lag becomes your data-loss window, then waiting for crash recovery to replay redo. Every one of these costs grows with write volume.
Aurora's architecture matters because it deletes the amplification rather than optimizing it. If storage nodes can apply redo records to construct pages themselves, the engine never writes a page at all — no checkpointing stalls, no doublewrite, no full-page images in the log. If durability is a 4-of-6 quorum over segments the storage fleet owns, then replication, backup, and recovery stop being engine features and become properties of the fleet: backup is a continuous stream from storage to S3 with zero load on the writer, and recovery is 'ask the quorum what the latest durable log point is,' which takes seconds regardless of workload.
The design also matters for what it enables above it: readers that share the same storage volume (no per-replica copy of the data), fast database cloning via copy-on-write at the segment level, and storage that grows in 10GB increments to 128TB+ without a resize event. Understanding the storage layer is understanding why Aurora behaves differently from RDS MySQL under load, during failover, and on your bill.
The architecture: every piece explained
Segments and protection groups. An Aurora volume is chopped into 10GB protection groups. Each protection group is replicated as six segments: two in each of three AZs, placed on different storage nodes. The segment is the unit of failure and repair — small enough that re-replicating one from its peers takes seconds on a 10Gbps+ fabric, which is the trick that makes six-way replication affordable: fast repair means the window where a second failure can stack on a first is tiny.
The write path. The engine generates redo log records, each tagged with a monotonically increasing Log Sequence Number (LSN) and routed to the protection group owning the affected page. Records are sent to all six segments in parallel; the transaction layer tracks acknowledgments. Two watermarks define durability: the VCL (Volume Complete LSN), the highest point below which every log record is confirmed durable at quorum, and the VDL (Volume Durable LSN), the highest complete transaction boundary at or below VCL. Commits are acknowledged to clients when their commit LSN ≤ VDL — asynchronously, so the engine's worker threads never block on storage round trips.
Inside a storage node. Receipt of a log record follows a deliberately short synchronous path: append to an in-memory queue, persist to a local SSD journal, ack immediately. Everything else is asynchronous background work: sort and gossip with peer segments to fill holes in the log sequence, materialize pages by applying log records to prior page versions, stream log and pages to S3 for backup, and garbage-collect log records once the pages they produced are durable. The node maintains multiple page versions, which is what lets the engine read a page 'as of' a specific LSN.
Readers. Up to 15 reader instances attach to the same volume. The writer streams its redo log to readers as well — not for durability, but as a cache invalidation and warm-up feed: readers apply records to pages already in their buffer pool and fetch anything else from storage on demand, reading at their own consistent LSN point. Replica lag is typically 10-20ms because nothing is re-executed; it is log-apply into memory. Quorum epochs guard the whole structure: every read and write carries an epoch number, and a new writer increments it, instantly fencing a deposed writer's in-flight operations.
End-to-end flow
Trace a single-row UPDATE with COMMIT. The engine modifies the page in its buffer pool and emits a redo record at LSN 9,001,224 for protection group 47. The record fans out to PG 47's six segments. Four acks arrive within ~1-2ms (the two slowest — one in a briefly congested AZ — don't matter). VCL advances past 9,001,224; the transaction's commit record is below the new VCL, so VDL advances too, and a completion callback acknowledges the commit to the client. The engine thread that ran the update was never blocked; it had already moved on, and the commit ack rode the asynchronous VDL advance.
On storage node 3 in AZ-2, the record landed in the update queue and hit the local journal before the ack went out. Minutes later, background work applies it — reading the prior page version at LSN 8,998,410, applying the delta, writing a new page version — and the gossip protocol notices segment 5 (AZ-3) has a hole from a dropped packet and forwards the record peer-to-peer. No engine involvement. The log record and old page versions eventually stream to S3 as part of continuous backup, then get garbage-collected locally.
A read on a reader replica at that moment: the replica has advanced its read point to VDL 9,001,224 via the log stream. A query touching the updated row finds the page in its buffer pool already patched by log-apply. A query touching a cold page issues a storage read 'page P as of LSN 9,001,224' to the nearest segment believed current (a 1-of-6 read in steady state — read quorums are only needed during recovery), and the storage node returns the materialized version. Crash-recovery flow, for contrast: a new writer instance establishes a new epoch, asks each protection group for its local completeness point, computes VCL as the quorum-durable minimum, truncates everything above it, and opens for business — seconds, with redo apply happening lazily in storage as pages are touched.