Amazon Aurora replicas typically show replica lag in the tens of milliseconds, while a standard RDS MySQL read replica can fall seconds or minutes behind. What is structurally different about how an Aurora cluster stores its data and feeds its replicas?

## The design Aurora replaced A conventional managed relational database is one server with its own disks. Durability comes from writing a write-ahead log plus data pages, and high availability comes from streaming that log to another complete server that replays it onto its own copy. Every replica therefore does the same work the writer did: parse the change stream, apply it to pages, flush them. When the writer is busy, the replica's single apply path becomes a bottleneck and lag grows. That apply lag is what you are measuring when RDS reports `Seconds_Behind_Source` or a Postgres replay delay. ## What an Aurora writer actually sends Aurora keeps the SQL engine (MySQL- or PostgreSQL-compatible) but replaces the storage layer with a distributed service. On a write, the instance does **not** push data pages down to disk. It ships redo log records — the compact description of the change — to the storage fleet. The storage nodes are not dumb block devices: they apply those log records themselves and materialize the data pages in the background. The often-quoted phrase from the Aurora paper is "the log is the database". The practical effect is far less data crossing the wire per commit than an engine that must eventually write full pages, plus a binlog, plus a doublewrite buffer. ## Six copies, three Availability Zones The cluster volume is sliced into 10 GiB segments. Each segment is replicated six ways: two copies in each of three Availability Zones. Writes use a quorum — the writer sends the log record to all six and acknowledges once four have accepted it. Reads use a smaller quorum of three. Those numbers are chosen so the volume tolerates losing two copies (a whole AZ) without losing write availability, and three copies without losing read availability. Because repair happens per 10 GiB segment rather than per volume, a lost copy is rebuilt from peers quickly instead of requiring a full-volume rebuild. The volume also grows automatically in 10 GiB increments as data arrives, up to a documented ceiling in the low hundreds of TiB on current engine versions, and you never pre-provision it the way you size an EBS volume for RDS. ## What the readers do Aurora Replicas are compute-only. They attach to the same cluster volume the writer is using, so there is no second copy of the data to keep in step. The writer's redo stream is also sent to each reader, but a reader uses it only to keep its **buffer cache** honest: pages it holds that the record touches are invalidated or updated, and anything else is read fresh from shared storage. This is why lag is measured in milliseconds rather than seconds. It is not, however, zero. There is still a short window in which a reader can serve a page slightly behind the writer, so read-after-write is **not** guaranteed through the reader endpoint. Design for that the same way you would with any asynchronous replica: route the read-your-own-write path at the writer, or wait on a replication position. ## The consequences you are being asked about - **Up to 15 Aurora Replicas** per cluster, all sharing one volume, so adding read capacity adds compute cost but not storage cost. - **Fast failover.** Promotion picks a healthy reader (promotion tiers decide which one) and re-points the cluster endpoint. Nothing is copied, so a failover typically completes in well under a minute rather than the minutes an instance rebuild would take. - **Backups are continuous** to Amazon S3 at the storage layer, so taking one does not tax the database instance. - **Reads scale, writes do not.** There is exactly one writer per Aurora cluster. If write throughput is the problem, more readers will not help; you are looking at sharding or a different data store. - **I/O is a billed dimension** in the standard configuration — each storage read and write operation costs money. A very chatty workload can end up paying more for I/O than for compute, which is what the Aurora I/O-Optimized cluster configuration exists to flatten in exchange for a higher instance and storage rate. ## What this does not change Commit latency still crosses Availability Zones — the four-of-six acknowledgement is a network round trip inside the Region, not free. And the engine on top is still MySQL or PostgreSQL, with the same transactions, locking, and query planning. Aurora changed where bytes live and who applies them, not how SQL behaves.