▸1. The Aurora Architecture: "The Log is the Database"
In classical relational architectures, the database engine flushes dirty buffer pages to local disks during checkpoints. AWS Aurora radically redesigned this storage layer:
The Aurora compute engine never flushes data pages directly to block storage. Instead, it streams raw write-ahead journal deltas to a custom distributed storage fleet replicated across 6 nodes in 3 Availability Zones (requiring a 4-of-6 quorum on writes). The storage fleet reconstructs database pages asynchronously.
- •Advantages: Spin-up time for read replicas takes seconds because all replicas read from the unified distributed storage layer with typical replication lag under 10ms.
- •The Drawback (The I/O Tax): Every write-ahead log record and storage read is metered as an "Aurora I/O Request". In poorly indexed databases with heavy full-table scans, the monthly I/O bill can easily triple the compute instance cost.
▸2. Bare-Metal & Self-Hosted Clusters (Patroni / InnoDB Cluster)
Deploying a 3-node HA cluster using Patroni (PostgreSQL) or InnoDB Cluster (MySQL) on dedicated enterprise hardware or bare-metal providers:
- 1Latency Profile: Local enterprise PCIe 4.0/5.0 NVMe storage completes
fsyncoperations in 50–100 microseconds. Because Aurora requires network quorum acknowledgments across multiple AZs, commit latencies rarely drop below 1–3 milliseconds. For latency-sensitive financial ledgers, local NVMe is unmatched. - 2Predictable TCO: Even under sustained workloads driving 100,000 IOPS, the monthly hosting fee remains fixed with zero marginal cost per million I/O operations.
- 3Operational Responsibility: Managing kernel updates, patching, drive replacements, and backup automation rests squarely on your internal DBA/SRE engineering team.