In 2017, ten AWS engineers, with Alexandre Verbitski as first author, published Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases at SIGMOD. By then the team had run Aurora as a production service for over 18 months, and the paper is written from that experience.
Its central claim fits in one sentence: in the cloud, the bottleneck for a relational database is no longer the disk or the CPU, it's the network between the database and its storage. Everything distinctive about Aurora follows from taking that seriously.
The problem
Take a traditional database, MySQL in the paper's example, and make it highly available in the cloud the standard way: a primary in one availability zone on network-attached disks (EBS), mirrored synchronously to a standby in another zone. Then count what crosses the network for one write.
The paper lists it: the redo log, the binary log archived for point-in-time restore, the modified data pages, a second copy of each page written to guard against torn pages, and metadata files. Each goes to EBS, which mirrors it, and then the whole chain is repeated on the standby. Several of these steps are sequential, so latencies add up, and every write waits for the slowest copy. In the paper's words, it behaves like a write quorum of four out of four: any slow node slows everything.
The standard way to make many machines agree on a commit, two-phase commit, has its own problem at cloud scale: it's chatty, and it handles failure badly, while a large fleet always has something failing somewhere.