RDS for MySQL and Aurora look similar until the input output line appears. Here is how the two price out, where Aurora wins, and what lock in really costs.
RDS for MySQL and Amazon Aurora price compute similarly, but Aurora adds an input output line that can dominate a busy database bill, so the right choice depends on your activity profile and your tolerance for lock in.
RDS for MySQL bills on instance hours, provisioned storage, backup storage, and data transfer. Storage is allocated up front, so you pay for capacity you reserve rather than capacity you use, which is predictable but easy to oversize.
The current rates are on the RDS for MySQL pricing page. Read the storage and instance tiers before you size the environment.
Provisioned storage is a common source of waste because teams allocate headroom and never reclaim it. Right sizing storage to real usage is often the first saving on an RDS bill.
Aurora prices compute by instance hours like RDS, but storage grows automatically and a per request input output line is added in the standard configuration. On a busy database that input output charge can become the largest single cost.
The Aurora pricing page and the Aurora user guide set out both the standard and I/O Optimized configurations.
RDS for MySQL versus Aurora cost model
| Cost line | RDS for MySQL | Aurora standard | Aurora I/O Optimized |
|---|---|---|---|
| Compute | Instance hours | Instance hours | Higher instance rate |
| Storage | Provisioned | Auto grow | Auto grow, higher rate |
| Input output | Included | Per request charge | No per request charge |
| Best for | Predictable, portable | Moderate activity | High input output activity |
Aurora costs more when the workload is input output heavy and runs on the standard configuration, because the per request charge scales with activity. The Aurora I/O Optimized announcement configuration trades a higher base rate for no per request charge and can reverse the result.
There is a break even level of activity above which I/O Optimized is cheaper than standard Aurora. Model your real input output rate against both configurations rather than assuming the default is correct.
Aurora creates more lock in because its storage layer and features are AWS proprietary, while RDS for MySQL runs standard MySQL that ports more easily. The cost of migrating away from Aurora belongs in the total comparison, not just the monthly bill.
Put a number on leaving Aurora before you commit to it. The proprietary storage layer means an exit involves a real data migration, and that cost belongs in the comparison from day one.
The common advice is that Aurora is simply the better managed database, so default to it. We disagree. Across the AWS estates we benchmarked in 2024 and 2025, teams chose Aurora on compute price and were then surprised when the per request input output line dominated the bill, and the proprietary storage layer raised the cost of ever leaving. Better is not the same as cheaper or more portable. The buyer side move is to model your real input output rate against standard Aurora, Aurora I/O Optimized, and plain RDS for MySQL, and to price the migration cost of lock in, so the choice reflects your workload rather than a default preference.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The compute rates invite you to compare on price. The input output line is where the real bill, and the real lock in, actually live.
White Paper · AWS
AWS RDS and Aurora Negotiation
Seven buyer side levers that cut AWS RDS and Aurora cost: instance right sizing, Reserved Instances, Aurora Serverless v2, and the EDP overlap. Read it free.
RDS for MySQL bills on instance hours, provisioned storage, backup storage, and data transfer. Storage is provisioned up front, so you pay for the capacity you allocate rather than what you use, which makes the bill predictable but easy to oversize.
Aurora prices compute by instance hours like RDS, but storage grows automatically and adds an input output line that RDS does not have in the same form. On a busy database the input output charge can become the dominant cost, which surprises buyers who modeled only compute and storage.
Aurora costs more than RDS for MySQL when the workload is input output heavy and the standard Aurora configuration is used, because the per request input output charge scales with activity. The Aurora I/O Optimized configuration trades a higher compute rate for no per request charge and can reverse the comparison.
Aurora I/O Optimized removes the per request input output charge in exchange for a higher compute and storage rate, which helps input output intensive databases. It is cheaper only above a break even level of activity, so model your real input output rate before switching to it.
Aurora creates more lock in because its storage layer and features are AWS proprietary, while RDS for MySQL runs standard MySQL that is easier to move. The migration cost away from Aurora is a real factor that belongs in the total cost comparison, not just the monthly bill.
Choose based on input output profile, availability needs, and portability. RDS for MySQL suits predictable, portable workloads, while Aurora suits high availability and high throughput where its features earn their premium and lock in is an accepted trade.
the instance and storage math, the input output line, the I/O Optimized switch, and the lock in trade across the AWS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
The compute rates look close. The input output line does not. Model your real activity before you assume Aurora is cheaper or dearer.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
Quarterly buyer side notes on AWS database pricing, Aurora, and commitment strategy. No reseller spin.