RDS vs Aurora: cost decision framework

Quick answer

For small databases under ~100 GB with simple HA: RDS is cheaper. For large databases with read replicas: Aurora is cheaper because replicas share storage. For write-heavy workloads with high I/O: Aurora I/O Optimized eliminates per-I/O fees. For variable workloads: Aurora Serverless v2 wins by scaling to zero (almost). The decision usually isn't pure cost; it's about scale, replicas, and operational fit.

The RDS vs Aurora decision is rarely about pure dollar cost. Aurora costs more per instance hour but provides better scalability, more efficient storage, and integrated HA. Whether that's worth the premium depends on your workload profile. This post breaks down the actual pricing math and the workloads each one wins.

The pricing model difference

RDS

Pay per instance hour by class and engine. Storage is provisioned (you allocate, you pay) regardless of how full it is. IOPS are included up to a baseline for gp3, billed extra for io1/io2.

Example: db.r5.large running PostgreSQL with 200 GB gp3 storage, Multi-AZ:

Instance: $0.50/hour × 730 = $365/month (Multi-AZ doubled)
Storage: 200 GB × $0.115/GB-month × 2 (Multi-AZ) = $46/month
Total: $411/month

Aurora

Pay per instance hour by class. Aurora storage is consumption- based: you pay only for actual data stored, not provisioned capacity. I/O is billed per request on Aurora Standard, free on Aurora I/O Optimized.

Example: db.r6g.large running Aurora PostgreSQL with 100 GB actual data, single writer:

Instance: $0.29/hour × 730 = $211.70/month
Storage: 100 GB × $0.10 = $10/month
I/O (Aurora Standard): usage-based, ~$50/month at moderate traffic
Total: $271.70/month

For the same database, Aurora is cheaper here because no Multi-AZ premium (Aurora replicates across 3 AZs natively without instance duplication) and storage scales with actual data instead of provisioned size.

For full per-resource pricing, see the catalog pages for aws_db_instance (RDS) and aws_rds_cluster (Aurora).

When RDS wins on cost

Small databases without replicas

A single-instance Postgres at db.t4g.medium with 50 GB storage, no replicas, single AZ:

RDS: $30/month instance + $5.75/month storage = $35.75/month
Aurora: $74/month instance + $5/month storage + minimal I/O = ~$85/month

For dev/staging or small production workloads, RDS is materially cheaper. Aurora's premium per instance doesn't pay back at this scale.

Steady utilization with reserved instances

RDS supports Reserved Instances with significant discounts (30-60% for 1-3 year terms). Aurora has its own reserved capacity but the discount is similar.

At the small end with reserved capacity, RDS db.t4g.medium 1-year RI costs ~$22/month. Aurora db.r6g.large with 1-year RI is ~$140/month. For workloads that fit the smaller instances, RDS+RI is very hard to beat.

When Aurora wins on cost

Read replicas at scale

RDS read replicas have their own copy of storage. Three replicas of a 200 GB database = 800 GB of storage billed (writer + 3 replicas).

Aurora read replicas share storage with the writer. Three replicas of a 200 GB cluster = 200 GB of storage billed total. Read replica instances bill but storage is unique to the cluster.

Comparison for a write+3-replica setup with 200 GB:

RDS: 4 instances + 4 storage copies = roughly 4x storage cost
Aurora: 4 instances + 1 storage copy = 1x storage cost

For read-replicated databases, Aurora's storage model is dramatically cheaper. At 1 TB with 3 replicas, the storage savings alone are $345/month.

Workloads with high I/O

Aurora Standard charges $0.20 per million I/O operations. For write-heavy or query-heavy databases, this can be substantial.

Aurora I/O Optimized eliminates the I/O fee but charges 30% more per instance and storage. The crossover with Aurora Standard:

If I/O cost is >25% of your Aurora Standard bill, switch to I/O Optimized.
If I/O is <25%, stay on Aurora Standard.

For workloads doing heavy data processing (ETL, analytics with many table scans, write-heavy OLTP), I/O Optimized is usually the right choice.

Variable workloads

Aurora Serverless v2 scales ACUs (Aurora Capacity Units) between min and max bounds based on demand. For workloads with 4-10x peak-to-trough ratios (business hours apps, batch processing), Serverless v2 can be much cheaper than running provisioned instances at peak capacity 24/7.

Example: an app with 1 hour of peak load needing 8 ACU and 23 hours of trough load needing 0.5 ACU:

Provisioned Aurora at peak (8 ACU equiv = db.r6g.2xlarge): ~$1,000/month
Aurora Serverless v2: 1×8 + 23×0.5 = 19.5 ACU-hours/day × $0.12 = $70/day = $2,100/month

Wait, that's more for Serverless v2 at this load profile. Aurora Serverless v2 wins when the trough is very low (under ~10% of peak), not at higher utilization. Run the math carefully.

The complete decision framework

Walk through these questions in order:

1. Database size and HA requirements

Under 100 GB, no replicas, simple Multi-AZ HA needed → RDS. Above 100 GB or multiple read replicas needed → Aurora.

2. Workload pattern

Highly variable with low baseline → Aurora Serverless v2. Steady production → provisioned Aurora.

3. I/O intensity

Write-heavy or query-heavy on Aurora → I/O Optimized. Read-heavy or balanced → Aurora Standard.

4. Reserved capacity

Stable production: both RDS RI and Aurora RC save 30-65%. Buy for whichever you're using at baseline.

5. Existing team expertise

Aurora has some quirks (cluster endpoints, custom endpoints, IO billing) that aren't in plain RDS. If your team is fluent in Postgres or MySQL but new to AWS, RDS is operationally simpler.

Migration considerations

Moving RDS to Aurora is supported via the RDS console (uses DMS under the hood). The data migration is straightforward; the operational changes are larger:

Aurora has separate writer and reader endpoints. Application code needs to route reads to the reader endpoint to get the benefit of read replicas.
Aurora storage I/O appears as a separate billable dimension. If you're on Aurora Standard, monitor I/O usage from day one.
Aurora backups are different. Snapshots are continuous; you don't take "nightly snapshots" the way you might on RDS.

For an actual cost estimate of both options on your Terraform, c3x makes the comparison concrete:

# c3x-usage.yml
resource_usage:
  aws_rds_cluster.production:
    storage_gb: 500
    monthly_io_requests: 100000000

  aws_db_instance.alternative:
    # ... same workload as RDS comparison

Run c3x estimate to see both side by side.

FAQ

RDS or Aurora, which is cheaper?

RDS is cheaper per instance hour. Aurora is roughly 20-30% more per hour for the same instance class. But Aurora's storage model is more efficient (you pay only for actual data stored, not provisioned capacity), and Aurora typically handles more throughput per instance. For small databases, RDS wins on cost. For large or write-heavy databases, Aurora can be cheaper despite the higher per-hour rate.

When does Aurora actually save money?

Two scenarios. First, when you'd otherwise over-provision RDS storage to get IOPS — Aurora storage scales automatically and bills only for used GBs. Second, when you need read replicas — Aurora replicas share storage with the writer, so you don't duplicate storage cost. RDS replicas have their own copy of the data.

What's Aurora I/O Optimized?

A storage configuration where instance prices are ~30% higher than Aurora Standard, but I/O operations are free (Aurora Standard charges $0.20 per million I/O). For write-heavy or I/O-intensive workloads where I/O is a meaningful portion of the bill (>25%), I/O Optimized is cheaper. The crossover depends on read/write patterns.

Is Aurora Serverless v2 always cheaper?

For variable workloads, yes — Aurora Serverless v2 scales compute by demand, so you don't pay for idle. For steady-state production with sustained utilization above 50%, provisioned Aurora is cheaper because the per-ACU rate is higher than the equivalent provisioned-instance rate.

What about RDS Multi-AZ vs Aurora's built-in HA?

Different models. RDS Multi-AZ provisions a hot standby that doubles your compute and storage cost but doesn't serve reads. Aurora replicates storage across 3 AZs by default with 6 copies of data, and read replicas can serve reads in addition to providing failover. Aurora's HA model is more efficient at HA + scale-out reads; RDS Multi-AZ is simpler for plain failover.

Does C3X estimate both RDS and Aurora?

Yes. RDS is aws_db_instance; Aurora is aws_rds_cluster + aws_rds_cluster_instance. C3X reads both and applies the correct pricing model. Storage estimates for Aurora are usage-based since storage is consumption-based; specify expected size in c3x-usage.yml.

The summary

Most teams overthink this decision. The pragmatic answer:

New small applications under 100 GB: use RDS. Cheaper, simpler.
Growing applications with read replica needs or going past 500 GB: migrate to Aurora.
Aurora Serverless v2 for any application with low baseline + occasional spikes.
Aurora I/O Optimized for any write-heavy production database.
Reserve capacity for both once you have 6 months of stable usage data.

For broader workflows including how to PR-gate database choices, see budget guardrails in CI.