Someone on your team picked Aurora for the new service, or you're migrating off RDS because a comparison post somewhere called it "RDS but better." Then the first full month's bill lands with line items that didn't exist on the old database — a charge for I/O requests, a backup number that doesn't match what you provisioned. Aurora isn't more expensive than RDS by some fixed percentage; it's differently metered, and which side wins depends on your storage growth, your read/write mix, and how spiky your traffic actually is. Here's what each meter actually charges for, with AWS's own numbers, so "Aurora vs RDS" turns into an answer for your workload instead of someone else's benchmark.
What actually differs between how Aurora and RDS bill you?
Both price compute the same way — an hourly rate per instance class, with Reserved Instances discounting a commitment against on-demand: AWS states 1-year Aurora Reserved Instances save up to 45% and 3-year terms save up to 66% over on-demand. That part of the bill is genuinely comparable engine to engine, and it isn't where "Aurora costs more" surprises come from. The differences that actually decide your total sit in the other three meters — storage, I/O, and backups. RDS treats all three as things you provision up front. Aurora treats most of them as things you simply consume.
How does Aurora's storage model differ from RDS's provisioned volumes?
On RDS, you pick a volume size — gp3, io1, io2 — and pay for that full allocation every month whether your tables use 40% of it or 95%. See how RDS pricing actually breaks down for the per-GB and per-IOPS numbers behind that side of the comparison.
Aurora doesn't ask you to provision storage at all. The cluster volume grows automatically as your data grows and shrinks automatically when you drop it — AWS's own documentation is explicit that removing data (dropping a table, truncating a database) reduces the allocated space and the resulting charge, up to a maximum of 256 tebibytes for supported engine versions. You're billed for what's actually stored, not for a number you typed in at creation time, and the underlying volume is already replicated across three Availability Zones in a Region by default.
That flexibility isn't free. Aurora Standard storage runs $0.10 per GB-month; Aurora I/O-Optimized runs $0.225 per GB-month — more than double. Which one you should be on depends entirely on the next meter.
What's the Aurora "I/O charge" that catches teams off guard?
Aurora Standard meters every read and write request to the storage layer separately from compute, at $0.20 per million I/O requests. This line item has no RDS equivalent — RDS gp3 volumes come with a bundled baseline of IOPS included in the storage price, so normal read/write activity within that baseline never triggers a separate per-request charge. On Aurora, a write-heavy or index-heavy workload can rack up I/O charges that dwarf the storage line, and that's the exact surprise this section is here to prevent.
AWS's own guidance on the trade-off is direct: Aurora I/O-Optimized is the better choice once your I/O spend passes 25% of total Aurora database spend. Below that line, Standard is cheaper. Above it, AWS states that switching to I/O-Optimized — which removes the per-request charge entirely and folds it into the higher storage and instance rates — can cut your bill by up to 40%. You can move between the two once every 30 days; non-NVMe-based instances switch with no downtime, NVMe-based instances need a brief restart.
A 1,000 GB Aurora Standard database growing 2% a day over 30 days, serving 350 read pages and 100 write pages per second, comes out to $362.28 in combined storage and I/O for the month in US East (N. Virginia). That's the shape of number to hold against your own CloudWatch I/O metrics — not a flat percentage rule of thumb applied without checking.
Pull the two metrics that tell you which side of the 25% line you're actually on:
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
--metric-name VolumeReadIOPs \
--dimensions Name=DBClusterIdentifier,Value=my-aurora-cluster \
--start-time "$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--period 86400 --statistics Sum --region us-east-1
Run the same query for VolumeWriteIOPs, sum both across the window, multiply by $0.20 per million requests, and compare the result against your instance and storage charges for the same period in Cost Explorer.
Does Multi-AZ cost the same on both?
On RDS, Multi-AZ is a second full instance kept synchronized as a standby, and turning it on exactly doubles two meters, not all of them: compute and storage both double, because you're paying for a complete second copy of each. AWS's own Dedicated Log Volume example shows the multiplier precisely — an io1 log volume attached to a Single-AZ PostgreSQL instance in US East (N. Virginia) costs $428/month ($0.125 × 1,024 GiB of storage plus $0.10 × 3,000 IOPS); the identical configuration on Multi-AZ with one standby costs $856/month — exactly 2×.
Aurora has no Multi-AZ switch to flip, because the redundancy is already built into the storage layer described above — three-AZ replication at no charge beyond the per-GB rate. What costs more on Aurora is adding instances: a reader in a second Availability Zone bills as its own full instance-hour, same as the writer. A Multi-AZ-equivalent Aurora setup is priced by counting instances, not by a doubling multiplier applied to one.
Are backups priced the same way?
No, and a straight percentage comparison here is misleading. RDS gives you free backup storage up to the total size of your provisioned storage — a 500 GB gp3 volume running a 300 GB database gets 500 GB of free backup headroom, whether or not the extra 200 GB is ever used. Aurora's free allowance is the size of the data you're actually storing, the metric AWS tracks as VolumeBytesUsed — there's no over-provisioned number for the free tier to inherit from, because there's no provisioning step at all.
AWS's own backup example shows the arithmetic: a cluster whose volume was 100 GB before a 7-day retention window, with 135 GB of incremental change data recorded during that window, totals 235 GB of backup usage. Subtract the free allowance — the latest volume size, 200 GB — and you're billed for 35 GB. On RDS, an oversized volume quietly buys extra backup headroom as a side effect of the waste. On Aurora it doesn't, because there's nothing to over-provision in the first place.
When does Aurora Serverless change the answer?
Aurora Serverless v2 prices compute by the Aurora Capacity Unit (ACU) instead of by instance class, scaling in fractional increments down to a minimum of 0.5 ACU. Aurora Standard bills $0.12 per ACU-hour; I/O-Optimized bills $0.156 per ACU-hour. AWS's own example: a workload needing 5 ACUs for 30 minutes costs roughly $0.33 in compute on Standard. Nothing on the RDS for MySQL or RDS for PostgreSQL side works this way — the closest RDS gets to elastic compute is picking a smaller instance class and living with its fixed rate whether you're at 5% or 95% utilization.
Serverless is the right comparison to reach for when traffic is genuinely spiky — a staging database, a low-traffic side project, anything with long idle stretches between bursts — rather than for a steady production workload, where a rightsized fixed instance on either engine usually beats paying the ACU rate around the clock.
What else should I check before I decide?
If RDS is still on the table for either engine, how RDS pricing actually breaks down has the per-GB and per-IOPS rates behind the provisioned side of this comparison. And whichever one you land on, the instance class you pick on day one rarely stays the right size for the life of the database — see how to right-size an RDS instance without downtime for the metrics that prove a database has outgrown or shrunk past its original class, and how Multi-AZ makes changing it safe.
This decision is also one line in a bigger bill. If you haven't yet, work through the rest of an AWS account in order of savings-per-minute — database engine choice is rarely the biggest lever in the account, just the one with the most opinions written about it.
How do I find out which one is actually cheaper for my account?
Running these numbers for one database is doable by hand in twenty minutes. Running them for an account with a mix of RDS and Aurora clusters — separating I/O-driven spend from storage-driven spend, catching a cluster that crossed the 25% I/O threshold six months after launch and never got switched — is the part that stops happening after the first review. Parsivex checks every Region for RDS and Aurora databases sized past what their workload uses, and then keeps watching, so a database that drifts back out of line gets flagged instead of quietly running up the same bill again. For what an over-provisioned instance finding means in your report, see Over-provisioned RDS instance, or read how scans work before you connect an account.