RDS vs Aurora Cost: When Aurora Is Actually Cheaper (2026)

RDS and Aurora both bill for compute, storage, backups, and data transfer, and on the surface the line items look identical. The differences that move real bills are narrower than people expect:

• Instance price. The same instance class (e.g. db.r6g.large) costs more per hour on Aurora than on RDS running the same engine. That premium buys you Aurora's storage engine and faster failover, whether you need them or not.
• Storage price per GB. Close between the two, but metered differently — RDS storage is provisioned (you pay for what you allocate), Aurora storage auto-scales in 10 GB increments and you pay for what you actually use.
• I/O requests. This is the one that actually decides the winner. Aurora Standard charges per million I/O requests against the storage layer. RDS has no equivalent line item — instead you pay for IOPS capacity up front (provisioned IOPS or gp3 baseline/burst), regardless of how much you use it.
• Replica storage. Aurora replicas share one copy of storage across the cluster. RDS read replicas are full standalone instances with their own storage volume, so each one duplicates the storage bill.

Everything else — backup storage beyond the free allowance, cross-AZ data transfer, snapshot export — is priced similarly enough on both that it rarely decides the comparison. Focus the analysis on instance price, storage, and I/O.

For provisioned instances, Aurora's hourly rate for a given instance class typically runs 15–40% above the equivalent RDS instance on the same underlying engine (PostgreSQL or MySQL-compatible). Illustrative us-east-1 on-demand rates for a mid-size instance:

Aurora I/O-Optimized uses the same instance rate as Aurora Standard on newer generations, but removes the per-I/O-request charge entirely — the trade is a flat instance-price bump (roughly 20–30% over Aurora Standard depending on instance family) in exchange for unmetered I/O. That reframes the decision: it's not "RDS vs Aurora," it's "pay per I/O (Aurora Standard) vs pay a flat premium and stop counting (I/O-Optimized) vs provision your own IOPS capacity (RDS)."

Aurora Serverless v2 bills per ACU-second (Aurora Capacity Unit, roughly 2 GB RAM + proportional CPU/network), typically around $0.12/ACU-hour, and scales between a minimum and maximum ACU count you set. A workload that idles most of the day and bursts occasionally can cost far less than a fixed provisioned instance sized for its peak — but a consistently busy workload running near its max ACU ceiling around the clock usually costs more than the equivalent provisioned instance, because you're paying the on-demand ACU rate continuously instead of a reserved/provisioned rate.

Storage pricing is close enough between RDS and Aurora that it's rarely the deciding factor, but the metering model differs:

• RDS (gp3): ~$0.115/GB-month, provisioned in advance. You pick a volume size and pay for all of it, whether or not the database uses it. Baseline 3,000 IOPS and 125 MB/s throughput are included free; more costs extra (see below).
• Aurora: ~$0.10–0.12/GB-month (engine-dependent), billed on actual data used, auto-scaling up to 128 TB in 10 GB increments. No pre-provisioning, no wasted allocated-but-unused capacity.

For a database with a stable, predictable size, this difference is a rounding error. For a database that grows unpredictably or where you'd otherwise over-provision RDS storage "to be safe," Aurora's pay-for-what-you-use model can save real money on the storage line specifically — just not enough on its own to flip the overall verdict.

This is where the RDS vs Aurora decision actually gets made. Aurora Standard charges roughly $0.20 per million I/O requests against the distributed storage layer. Every read that misses the buffer pool, every write, every redo-log flush counts as an I/O request. For a chatty OLTP workload doing millions of small transactions a day, this adds up fast and is easy to underestimate when you're only looking at the instance price.

RDS doesn't have a per-request charge. Instead you provision I/O capacity up front:

• gp3 (general purpose SSD): 3,000 IOPS / 125 MB/s included free; beyond that, ~$0.005 per provisioned IOPS-month and ~$0.04 per provisioned MB/s-month above baseline. Good for moderate, fairly predictable I/O.
• io2 (provisioned IOPS SSD): ~$0.125 per provisioned IOPS-month, no baseline included — you provision exactly the IOPS you need. Built for consistently high, latency-sensitive I/O (tens of thousands of IOPS).

The practical difference: Aurora Standard's I/O charge scales with actual usage (you only pay for I/O you generate), while RDS provisioned IOPS is capacity you pay for whether you use it or not. A bursty workload with a high peak but low average I/O can look expensive on RDS (you provision for the peak) and cheap on Aurora Standard (you pay for the average). A workload with sustained, predictable high I/O looks the opposite: RDS provisioned IOPS becomes a fixed, capped cost, while Aurora Standard's per-request meter keeps climbing linearly — which is exactly the scenario Aurora I/O-Optimized exists to fix, by swapping the per-request meter for a flat instance surcharge.

Three smaller line items worth knowing about before you build a cost model:

• Read replicas. Aurora replicas attach to the same shared storage volume as the writer — you pay for each replica's compute, but not a second copy of storage. RDS read replicas are independent instances with their own storage allocation, so three RDS replicas mean three separate storage bills on top of three instance bills. For read-heavy apps running multiple replicas, this alone can tip the comparison toward Aurora regardless of the I/O math.
• Backups. Both services include backup storage up to the size of your database for free during the retention window; extra backup storage and long-term retention beyond that are billed per GB-month on both, at similar rates. Aurora backups are continuous and incremental; RDS backups are snapshot-based. Neither is a major cost driver in most setups.
• Data transfer. Identical pricing model on both — free within the same AZ, charged for cross-AZ and internet egress at standard AWS rates. Not a differentiator between RDS and Aurora specifically.

Assumptions: single db.r6g.large instance, us-east-1, 100 GB of data, light traffic — roughly 5 million I/O requests per month (a typical small SaaS app database: a few hundred requests/second at peak, mostly cached reads).

At this traffic level, I/O charges are trivial on either service — the entire gap comes from Aurora's higher instance price. RDS wins by roughly 20%. This is the common case for early-stage SaaS products, internal tools, and most app databases that aren't under heavy transactional load: Aurora's failover speed and storage durability are nice-to-haves you're paying a premium for, not a cost saver.

Assumptions: single db.r6g.xlarge instance, us-east-1, 500 GB of data, heavy OLTP traffic — roughly 2 billion I/O requests per month (a busy transactional system: order processing, high-frequency writes, cache-unfriendly access patterns doing low thousands of I/O operations per second sustained).

Here the picture flips hard. RDS with enough provisioned IOPS to handle 2 billion requests a month needs roughly 10,000 IOPS sustained, and that capacity is the majority of the bill. Aurora Standard's per-request charge is real money at this volume (~$400/mo) but still undercuts RDS's provisioned-IOPS cost. Aurora I/O-Optimized wins outright— the ~30% instance premium is far smaller than either the RDS IOPS bill or Aurora Standard's metered I/O charge. This is the textbook case I/O-Optimized was built for: high, sustained I/O where the per-request meter would otherwise dominate the bill.

The crossover between Aurora Standard and I/O-Optimized generally lands when I/O charges alone would exceed roughly 10–15% of the instance cost — below that, stay on Standard; above it, I/O-Optimized's flat premium is cheaper than the meter. AWS publishes an I/O usage percentage in Aurora's billing console specifically to help estimate which side of that line you're on before switching storage configurations.

• Small app database, low-to-moderate traffic → RDS. The instance-price discount outweighs anything Aurora offers, and gp3's free IOPS baseline covers you.
• High, sustained I/O (busy OLTP, high-QPS APIs) → Aurora I/O-Optimized. Unmetered I/O beats both RDS provisioned IOPS and Aurora's per-request meter once volume is high enough.
• Moderate, growing I/O and you're not sure yet → Aurora Standard. Start metered, watch the I/O usage percentage in Cost Explorer / the Aurora console, and switch to I/O-Optimized when it crosses the 10–15% threshold. Switching is a configuration change, not a migration.
• Spiky, bursty, or intermittent traffic → Aurora Serverless v2. Pay per ACU-second and scale toward zero during idle periods instead of running a fixed instance around the clock.
• Read-heavy with multiple replicas → lean Aurora. Shared storage across replicas avoids paying for duplicate storage on every replica, which adds up fast on RDS past two or three replicas.

Whichever you pick, the number to track isn't the instance price — it's I/O requests per month relative to instance cost. That ratio, more than any feature comparison, is what actually decides RDS vs Aurora on your bill. For the bigger picture of where database spend sits in a typical AWS bill, see our breakdown of why AWS bills climb, and for warehouse-side query costs, our Snowflake vs BigQuery vs Redshift cost-per-query comparison.