Running the I/O-Cost Math Before Migrating from RDS to Aurora

Decision drivers

Current RDS VolumeReadIOPs/VolumeWriteIOPs from CloudWatch
Which specific problem (failover time, replica lag, storage friction) is actually driving the migration
Whether the workload is high-small-operation ("chatty") vs. large sequential I/O

Production premise

Aurora trades per-operation I/O billing (on Standard storage) and a higher instance rate for AZ-level durability and reader scaling that shares the writer's storage layer instead of replaying a binary log. You're not paying for "faster" — you're paying for a different storage architecture, and that architecture has a different cost shape than RDS's flat EBS-backed billing.

Failure mode & inflection point

The point where this stops being a clear win is a chatty, high-small-operation workload. Pull VolumeReadIOPs and VolumeWriteIOPs from CloudWatch on your current RDS instance. If (avg IOPS × 3,600 × 730) / 1,000,000, multiplied by your region's per-million-I/O rate, is already a meaningful fraction of what you'd spend on Aurora compute, the throughput numbers on the marketing page won't show up as savings — they'll show up as a bigger bill for the same workload.

Production guardrail

Don't approve an Aurora migration until someone has actually run that I/O-cost math against your current RDS VolumeReadIOPs/VolumeWriteIOPs numbers, and named which specific problem (failover time, read-replica lag, storage-growth friction) is driving the move. If nobody's done that math, the migration is being approved on the throughput slide, not the actual workload.