Contents
Key takeawaysRDS for MySQL pricingHow Aurora pricing differsWhen Aurora costs moreWhat we see in reviewsLock in and exit costCheck your own numbersReserved Instances and Savings PlansQuestions for AWSWhat to do nextFAQRDS for MySQL and Amazon Aurora price compute similarly, but Aurora Standard adds a per request I/O charge that can dominate a busy database bill. The right choice depends on your activity profile and your tolerance for lock in.
- RDS bills what you provision. RDS for MySQL charges instance hours plus storage you size up front, with gp3 baseline IOPS included in the volume.
- Aurora bills what you use, plus I/O. Aurora storage grows automatically and Aurora Standard adds a charge for every million I/O requests, a line RDS does not have.
- The I/O line can lead the bill. On I/O heavy workloads the Aurora I/O charge can outgrow compute, and memory sizing drives how many reads are billed.
- I/O-Optimized has a break even. It removes the per request charge in return for higher instance and storage rates, so it pays off only on I/O heavy clusters.
- Leaving Aurora is a migration. Its proprietary storage means an Aurora snapshot cannot be restored to RDS for MySQL, so price the exit before you move in.
- Pick the engine, then commit. Reserved Instances and the new Database Savings Plans cut compute only, so settle the engine and configuration before you sign.
RDS for MySQL and Amazon Aurora MySQL both bill compute by the instance hour, at rates close enough that most comparisons stop there. The difference is in storage and I/O. RDS charges for the storage you provision, while Aurora Standard charges for the storage you use plus every million I/O requests.
Below we show how each service bills, where Aurora I/O-Optimized breaks even, what leaving Aurora costs, and how to test your own numbers first. Related AWS pricing guides sit in our AWS knowledge hub.
How does RDS for MySQL pricing work?
RDS for MySQL bills four lines: instance hours, provisioned storage, backup storage and data transfer. You choose the storage size up front and pay for all of it every month, whether the database fills it or not. That makes the bill predictable and 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, and note four details that change the total.
- Baseline performance is included. On gp3 storage, RDS for MySQL includes 3,000 IOPS and 125 MiB/s below 400 GiB, and 12,000 IOPS and 500 MiB/s from 400 GiB up. There is no per request charge.
- Extra performance is a separate line. IOPS and throughput provisioned above the gp3 baseline, or Provisioned IOPS volumes, are billed on top.
- Multi-AZ adds a standby. The standby instance and its storage are billed too, so those lines roughly double.
- Backups are free up to a point. Backup storage up to your total provisioned database storage in the region carries no charge.
Provisioned storage and oversizing
Provisioned storage is a common source of waste because teams allocate headroom at launch and never reclaim it. Right sizing storage to real usage is often the first saving on an RDS bill. Storage autoscaling adds to the problem, because it grows the volume when free space runs low and never shrinks it.
Until late 2024, reducing an RDS volume meant building a new instance and migrating. Since November 20, 2024, RDS Blue/Green Deployments can build the green copy on a smaller volume for RDS for MySQL 5.7 and later, and switch over in as little as a minute.
- Instance hours: the compute base, sized to workload.
- Provisioned storage: reserved capacity, easy to overbuy.
- Backups and transfer: secondary lines that still add up.
Negotiating AWS 10: Terms That Outlast the Discount
How is Amazon Aurora priced differently?
Aurora prices compute by instance hours like RDS, but storage follows the data and Aurora Standard adds a per request I/O charge. In US East (N. Virginia), Standard storage costs $0.10 per GB per month and I/O costs $0.20 per million requests. On a busy database that I/O 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. Storage is replicated across three Availability Zones however many instances you run.
| Cost line | RDS for MySQL | Aurora Standard | Aurora I/O-Optimized |
|---|---|---|---|
| Compute | Instance hours | Instance hours | Higher instance rate than Standard |
| Storage | Provisioned, paid whether used or not | Auto grow, $0.10 per GB per month on what you use | Auto grow, higher rate of $0.225 per GB per month |
| Input output | Included up to the volume baseline; extra IOPS billed | Per request charge, $0.20 per million | No per request charge |
| High availability | Multi-AZ standby billed as a second instance | Storage copies included; a reader instance for failover is extra | Same as Standard |
| Best for | Predictable, portable | Moderate activity | High input output activity |
What counts as a billed I/O on Aurora Standard?
Aurora bills a read I/O each time it fetches a 16 KB data page from storage that is not already in memory. Writes are counted in 4 KB units, and Aurora only ships redo log records to storage, never full data pages.
Instance memory therefore drives the I/O bill. A working set that fits in the buffer pool generates few billed reads. Move the same workload to a smaller instance and billed reads can climb sharply, so a compute saving can reappear on the I/O line.
AWS RDS and Aurora Negotiation
How to cut RDS and Aurora cost through right sizing, Reserved Instances, Aurora Serverless v2 and the EDP overlap.
Get the white paper →When does Aurora cost more than RDS for MySQL?
Aurora costs more when the workload is input output heavy and runs on the Standard configuration, because the per request charge scales with activity. On RDS the same activity is mostly covered by the volume baseline. Aurora I/O-Optimized, launched in May 2023, trades a higher base rate for no per request charge and can reverse the result.
The Aurora I/O-Optimized announcement sets out the trade: instances cost about 30 percent more, storage costs more per GB, and I/O carries no charge. Serverless v2 follows suit at $0.12 per ACU hour on Standard and $0.156 on I/O-Optimized.
Finding the break even point
There is a break even level of activity above which I/O-Optimized is cheaper than Standard Aurora. It equals roughly 30 percent of your instance cost plus $0.125 for every GB stored. AWS says the switch saves up to 40 percent once I/O exceeds 25 percent of your Aurora spend.
Say a cluster has two instances costing $2,000 a month on Standard and stores 1,000 GB. I/O-Optimized adds about $600 of compute and $125 of storage, so it pays once I/O passes $725 a month. At the Standard I/O rate, that is about 3.6 billion requests a month.
| Monthly I/O requests | Aurora Standard total | I/O share of Standard bill | Aurora I/O-Optimized total | Result |
|---|---|---|---|---|
| 1 billion | $2,300 ($2,000 + $100 + $200) | 8.7 percent | $2,825 ($2,600 + $225) | Standard cheaper by $525 |
| 3.6 billion | $2,825 ($2,000 + $100 + $725) | 25.7 percent | $2,825 | Break even |
| 10 billion | $4,100 ($2,000 + $100 + $2,000) | 48.8 percent | $2,825 | I/O-Optimized cheaper by $1,275 (31 percent) |
The break even lands close to the I/O share AWS quotes. The 10 billion requests average about 3,860 a second, inside the 12,000 IOPS gp3 baseline of a 1,000 GB RDS volume. EBS IOPS and Aurora I/Os are counted differently, so treat that as a first test rather than a verdict.
The choice is also reversible. You can move a cluster to I/O-Optimized once every 30 days and back to Standard at any time, so trial it on your busiest cluster for a month and compare invoices. On NVMe based instance classes the switch restarts the engine, so book a maintenance window for those.
What have we seen in recent RDS and Aurora cost reviews?
Across roughly 30 to 40 AWS environments I benchmarked between 2024 and 2025, the choice between RDS and Aurora was usually made on compute price alone. The I/O line was missing from the business case. Three patterns came up repeatedly.
- The I/O charge ran the bill. In 30 to 50 percent of the Aurora bills we reviewed, the per request I/O charge was larger than compute.
- RDS storage was oversized. Provisioned storage ran 20 to 40 percent above actual usage, mostly launch headroom and autoscaling growth.
- Exit cost was never priced. In most cases, the cost of migrating away from Aurora was absent from the comparison that justified moving to it.
Which engine creates more lock in?
Aurora creates more lock in because its storage layer and several features are AWS proprietary, while RDS for MySQL runs standard MySQL that ports more easily. Application code usually works unchanged on either. The data and the operating model make leaving expensive, so the exit cost belongs in the total comparison.
Pricing the migration cost
Put a number on leaving Aurora before you commit to it. The route in is simple, through an Aurora read replica of an RDS for MySQL instance or an RDS snapshot restored into Aurora. The route out is a real data migration, because an Aurora snapshot cannot be restored to RDS for MySQL.
- Tooling: AWS DMS with ongoing replication, binary log replication from Aurora to a MySQL target, or mysqldump with a downtime window.
- Engineering time: testing, cutover rehearsal and rollback planning, usually the largest cost for a production database.
- Feature rework: anything built on Global Database, Backtrack, fast cloning or Aurora specific parameters has to be replaced.
- Double running: both environments bill during replication and validation.
- Decision: weigh the Aurora premium and the lock in against the features you will actually use.
For exit rights across other AWS services, see our guide to AWS lock in risk and exit options.
Why we do not treat Aurora as the default choice
The usual advice is that Aurora is simply the better managed database, so every new MySQL workload should start there. We disagree for steady, moderate workloads. In the reviews above, teams picked Aurora on compute price, then found the I/O line dominated the bill and the storage layer raised the cost of leaving.
Aurora earns its premium where you need fast failover, many readers or Global Database. Everywhere else, model each workload against Aurora Standard, Aurora I/O-Optimized and plain RDS for MySQL, add the exit cost, and let the workload decide.
The compute rates invite you to compare on price. The I/O line and the exit cost are where RDS and Aurora actually differ.
How do you check your own RDS and Aurora numbers?
You can measure both sides with tools already in your AWS account. Pull at least 30 days of data, and 90 if the workload has month end or seasonal peaks.
- Aurora billed I/O. In CloudWatch, sum VolumeReadIOPs and VolumeWriteIOPs per cluster and multiply the monthly total by the I/O rate for your region.
- Aurora I/O share. In Cost Explorer, group Aurora spend by usage type to split instance, storage and I/O charges. It totals all clusters in a region, so use CloudWatch for cluster detail.
- AWS's own view. AWS Compute Optimizer flags Aurora clusters that would cost less on I/O-Optimized. Treat it as a second opinion.
- RDS storage headroom. Compare FreeStorageSpace with allocated storage per instance, and check whether autoscaling has raised the allocation since launch.
- RDS IOPS against baseline. Compare ReadIOPS and WriteIOPS peaks with the gp3 baseline to see whether extra provisioned IOPS are needed at all.
How do Reserved Instances and Savings Plans change the comparison?
Commitments cut the compute line on both engines, which makes storage and I/O a larger share of what is left. Choose the engine and Aurora configuration first, then commit, or you lock in whatever the compute only comparison got wrong.
- Reserved Instances. AWS quotes Aurora Reserved Instance discounts of up to 45 percent for one year and up to 66 percent for three years. They keep applying after a switch to I/O-Optimized, with Aurora accounting for the price difference automatically.
- Database Savings Plans. Launched December 2, 2025, they cover Aurora, RDS and seven other database services on a one year term with no upfront payment: up to 35 percent off serverless and up to 20 percent off provisioned instances. For a steady provisioned instance, compare that 20 percent with the Reserved Instance rate before you choose.
- No stacking. A Database Savings Plan and an RDS Reserved Instance cannot both apply to the same workload.
- Storage and I/O. AWS describes both instruments in terms of instance and serverless usage, so do not count on either to reduce storage or I/O.
For the choice between the two instruments, see Reserved Instances versus Savings Plans.
Extended Support changes the MySQL 8.0 comparison
Standard support for RDS for MySQL 8.0 ended on July 31, 2026, and Extended Support charges, billed per vCPU per hour, started on August 1, 2026. If you cannot upgrade to MySQL 8.4 soon, add that charge to the RDS side of the comparison.
Aurora MySQL version 3, which is MySQL 8.0 compatible, stays in standard support until April 30, 2028. That holds only while each cluster runs a supported minor version, such as the 3.10 long term support release.
How the answer changes with the size of your fleet
With five to ten MySQL databases, you can model each one and pick an engine per workload. At a few hundred, set a rule: RDS for MySQL by default, Aurora where failover time or read scaling requires it, and a quarterly review of the I/O share per Aurora cluster.
What should you ask AWS before you commit?
Ask for the numbers per workload, in writing, before any migration or commitment. AWS account teams and solutions architects often recommend Aurora, and their lines are predictable.
| What you will hear | What to say back |
|---|---|
| Aurora delivers up to five times the throughput of standard MySQL. | Show us the throughput our workload needs today and what the I/O line costs at that load. |
| Switch to I/O-Optimized and save up to 40 percent. | That applies above a 25 percent I/O share. Give us the share per cluster first. |
| Aurora storage grows automatically, so you never pay for headroom. | RDS volumes can now shrink through Blue/Green, so headroom is fixable on both. Price the I/O line for our workload instead. |
| Moving from RDS to Aurora takes a read replica and a promotion. | Then price the route back, since an Aurora snapshot cannot be restored to RDS. |
| Cover it all with a Database Savings Plan. | We will commit once the engine is settled, and only on compute we are sure of. |
If database spend sits inside an enterprise commitment, make sure Aurora and RDS usage both count toward it, so an engine change never creates a shortfall. See our AWS EDP negotiation guide and our guide to negotiating RDS and Aurora cost.
What to do next
- Measure I/O. Pull 30 to 90 days of your real input output rate per cluster, not just compute and storage.
- Cut RDS storage. Right size RDS provisioned storage down to actual usage, using Blue/Green where the volume must shrink.
- Model both Aurora configurations. Compare Standard against I/O-Optimized at your activity level and trial the switch on your busiest cluster.
- Add RDS for MySQL to the comparison. Put both Aurora configurations next to plain RDS for MySQL, including Multi-AZ and any Extended Support charges.
- Price the exit. Add the migration cost of Aurora lock in to the total comparison before any move.
- Then commit. Choose the engine that fits the workload, then cover the steady compute through Reserved Instances or Savings Plans.
Frequently asked questions
How is RDS for MySQL billed?
You pay for instance hours, the storage you allocate, backups beyond the free allowance and data transfer out. Because the storage charge follows allocation, a volume sized for growth that never came keeps billing every month. Check allocated against used storage per instance at least once a year.
How is Amazon Aurora priced differently from RDS?
Aurora charges for the storage your data actually occupies, which also falls when you drop tables on current versions, and Aurora Standard adds a charge per million I/O requests. Buyers who modeled only compute and storage are the ones surprised by the first full invoice.
Is Aurora more expensive than RDS for MySQL?
Aurora costs more mainly when a read and write heavy workload stays on Aurora Standard, because billed I/O grows with every page read that misses memory. Undersized instances make it worse, since a smaller buffer pool sends more reads to storage. Reader instances you do not need for failover add to the gap.
Does Aurora I/O-Optimized fix the input output cost?
It removes the per request charge in exchange for higher compute and storage rates, which helps I/O intensive databases. It only saves money above a break even level of activity, so measure a full month of billed I/O per cluster before switching, and check again after any instance resize.
Can I switch between Aurora Standard and I/O-Optimized?
Yes. It is a cluster setting, not a data migration, and on most instance classes it applies without a restart. NVMe based classes restart the engine, so schedule those in a maintenance window. Only the change to I/O-Optimized is limited, to once every 30 days; switching back to Standard is allowed at any time.
Does Aurora create more lock in than RDS for MySQL?
Yes. Aurora's storage layer and features such as Global Database and Backtrack exist only on AWS. RDS for MySQL runs community MySQL, so a dump or replication stream lands on any MySQL host. Budget engineering time and a period of double running for any Aurora exit.
How do you choose between RDS for MySQL and Aurora?
Base it on I/O profile, availability needs and portability. RDS for MySQL suits steady, portable workloads with predictable storage. Aurora suits databases that need fast failover, many read replicas or cross region replication, where those features earn the premium and the lock in is an accepted trade.