RDS removes five jobs from your team: running the engine, backups, minor patching, standby replication and failover, and host, disk and network operations. It hands back two: a maintenance window and a parameter group. Aurora is a different architecture behind a compatible protocol, with storage in a distributed layer of six copies across three zones and compute as a separate instance. Replicas are typically milliseconds behind, failover is faster, storage grows by itself, and you pay for I/O operations as a line item.
That line item is the one to price first.
The break-even, with the course's numbers
Aurora standard bills storage I/O per request. Aurora I/O-Optimized charges roughly 30% more per instance-hour and a higher storage rate, and nothing per I/O. So the choice is arithmetic. For the two r5.large instances in the course's reference architecture:
instances $423.40 a month
+ about 30% + $127.02
+ storage, 100 GB + $12.50 ($0.225 vs $0.10 per GB-month)
= premium $139.52 a month
at $0.20 per million requests:
$139.52 buys 698 million I/O = 265 I/O per second sustained
Above roughly 265 sustained I/O per second, I/O-Optimized is cheaper for this cluster. Below it, standard is. At that point I/O is about a quarter of the Aurora bill, which is the threshold AWS itself gives.
Think Like an Engineer
Rates change and so do instance classes. Keep the shape of the calculation, premium divided by price per request divided by seconds, and re-run it with current rates before you decide.
What to do with it
An order system at 5,000 orders a day is nowhere near that line and should stay on standard. A write-heavy workload with an index per query and a busy autovacuum crosses it easily, and is the case where the I/O line quietly exceeds the instance line.
Do not infer the answer from the workload's reputation. Measure VolumeReadIOPs and VolumeWriteIOPs for a fortnight, then do the division.
