RDS for MySQL vs Aurora. The bill is in the I/O.

Amazon RDS for MySQL and Amazon Aurora MySQL run the same engine family, but they bill on different meters. RDS charges instance hours plus provisioned storage. Aurora charges instance hours, storage that grows automatically, and in the standard configuration a separate I/O line that can dominate the bill.

This comparison is for engineering and procurement teams choosing between the two managed MySQL options on AWS in 2026. Read it alongside the AWS EDP and commitment guide and the AWS Savings Plans buyer guide.

How do RDS for MySQL and Aurora bill differently?

Both are managed database services, so you pay for compute by the instance hour. The split shows up in storage and I/O, where the two services use different models.

What does RDS for MySQL charge for?

RDS for MySQL uses a simple meter. You pick an instance class, you provision a fixed amount of storage, and you pay for both whether or not you use them fully.

• Instance hours: the running cost of the class you select.
• Provisioned storage: the gigabytes you allocate, billed monthly.
• Backups and I/O: bundled into the storage tier for standard volumes.

What does Aurora MySQL charge for?

Aurora separates storage from compute and grows storage automatically. In standard mode it also meters read and write I/O as a distinct line.

• Instance hours: roughly 20 percent above the matching RDS class.
• Storage: billed per gigabyte used, growing in 10 gigabyte steps.
• I/O: charged per million requests in standard mode, removed under I/O Optimized.

When does Aurora I/O Optimized make sense?

AWS documents the two storage modes on the Aurora pricing page. I/O Optimized trades a higher fixed rate for zero per request I/O, which wins once I/O passes about a quarter of your Aurora bill.

Which option costs less for your workload?

There is no single answer. The cheaper option depends on how much I/O your workload drives and how steady it is across the month.

When does RDS for MySQL come out cheaper?

RDS tends to win for steady workloads with predictable storage and modest I/O. You pay for what you provisioned, and there is no surprise I/O line at month end.

When does Aurora come out cheaper?

Aurora tends to win for read heavy workloads that scale out across replicas, or where automatic storage growth avoids over provisioning. The replica model and failover speed are the usual reasons teams pay the premium.

What is the most common costing mistake?

Comparing only the instance hour rate. The headline rate ignores I/O, which is exactly the line that makes a standard Aurora bill jump on a busy workload. Model the full meter before you switch.

Teams pick Aurora for the instance rate, then get billed on I/O nobody modeled. The deciding number is requests per month, not dollars per hour.

What to do next

1. Pull your current monthly I/O request count from CloudWatch before you compare.
2. Model RDS, Aurora standard, and Aurora I/O Optimized on that real I/O volume.
3. Check whether your workload is read heavy enough to use Aurora replicas.
4. Confirm storage growth patterns so auto grow does not become a silent cost line.
5. Fold any move into your Savings Plans or EDP commitment math, not a standalone quote.
6. Set a CloudWatch alarm on I/O spend if you stay on Aurora standard.
7. Re check the model at renewal, since AWS adjusts both meters over time.

Frequently asked questions

Is Aurora always more expensive than RDS for MySQL?

No. Aurora instance hours run about 20 percent higher than the matching RDS class, but the total can land lower for read heavy workloads that use replicas or that would otherwise over provision RDS storage. The deciding factor is I/O volume, not the instance rate.

What is the I/O charge on Aurora?

In standard mode Aurora charges per million read and write I/O requests as a separate line. On a busy workload that line can rival the instance cost, which is why I/O Optimized exists to fold it into a higher fixed rate.

When should I use Aurora I/O Optimized?

Use I/O Optimized when I/O passes roughly a quarter of your standard Aurora bill. It removes the per request charge in exchange for a higher instance and storage rate, which usually wins for high and spiky I/O.

Can I move from RDS for MySQL to Aurora without downtime?

Largely yes. You can create an Aurora read replica of an RDS for MySQL instance and promote it, which keeps the cutover window short. Test the application against Aurora first, since some MySQL features and parameters differ.

Does a commitment discount apply to both?

Reserved capacity and EDP commitments cover both services, but the discount math differs because the meters differ. Model the committed spend against your real workload rather than assuming a flat percentage carries across.

Which is better for a small, steady application?

RDS for MySQL is usually the simpler and cheaper choice for a small, steady application with predictable storage and low I/O. Aurora earns its premium at scale, on read heavy or bursty workloads, not on modest ones.