Aurora vs RDS Cost Comparison: When Each Wins, with Break-Even Math
Aurora and RDS look interchangeable in the AWS console and price very differently in practice. The I/O model, storage-consumed pricing, and Aurora I/O-Optimized option mean the same workload can cost 40 percent less on Aurora or 40 percent more, depending on the access pattern.
The Aurora versus RDS cost question is the most frequent database design question we get from buyers entering an EDP cycle. Both run MySQL and PostgreSQL-compatible engines on AWS-managed infrastructure. Both bill instance-hours and storage. They diverge sharply on the I/O model, the storage charge basis, the replica strategy, and the elasticity options. Picking the wrong engine for a workload routinely costs $200K to $800K annually at enterprise scale.
The cost model side-by-side
| Dimension | RDS MySQL/PostgreSQL | Aurora MySQL/PostgreSQL |
|---|---|---|
| Instance-hour rate | Standard db.m/r/t classes | ~20% higher than equivalent RDS class |
| Storage charge | Per-GB-month allocated | Per-GB-month consumed (no provision-then-pay) |
| I/O charge | Bundled in gp3/io2 storage | $0.20 per 1M requests (Standard) or none (I/O-Optimized) |
| I/O-Optimized premium | Not applicable | ~30% higher instance and storage rate, no per-request I/O |
| Replica scaling | Up to 5 read replicas; async | Up to 15 replicas; shared storage, near-zero replica lag |
| Failover RTO | 60 to 120 seconds (Multi-AZ) | Under 30 seconds typical |
| Serverless | Not available | Aurora Serverless v2 (ACU-based) |
| Backup storage | Free up to 100% of allocated; paid above | Free up to 100% of consumed; paid above |
Aurora I/O-Optimized: the critical economic decision
AWS introduced Aurora I/O-Optimized in 2023 specifically because the per-request I/O charge made write-heavy workloads economically unattractive. The trade:
- Aurora Standard. Lower instance-hour rate. $0.20 per million I/O requests.
- Aurora I/O-Optimized. ~30 percent higher instance-hour rate. ~30 percent higher storage rate. Zero per-request I/O charge.
The break-even rule of thumb: if I/O charges exceed roughly 25 percent of your Standard Aurora instance-hour bill, I/O-Optimized pays back. CloudWatch metric to measure: VolumeReadIOPs and VolumeWriteIOPs. Multiply monthly request count by $0.20 / 1,000,000 and compare to instance cost.
Worked example: 2,000 RPS write-heavy workload
Workload: PostgreSQL, 2,000 writes per second sustained, 200 GB data, 1 db.r6g.2xlarge equivalent.
| Component | RDS PostgreSQL | Aurora Standard | Aurora I/O-Optimized |
|---|---|---|---|
| Instance/month | $734 | $881 | $1,145 |
| Storage/month (200 GB) | $23 (gp3) | $20 (consumed) | $26 (consumed) |
| I/O/month (5.2B writes) | Included in gp3 | $1,040 | Included |
| Multi-AZ multiplier | x2 | Built-in | Built-in |
| Total/month | $1,514 | $1,941 | $1,171 |
For this workload, Aurora I/O-Optimized is cheapest, Aurora Standard most expensive. The I/O cost on Aurora Standard wipes out any compute savings.
Worked example: read-heavy workload with replicas
Workload: MySQL, 90 percent reads, 200 reads/sec, 1 writer + 4 replicas, 500 GB data.
RDS with 4 read replicas runs 5x the instance cost plus 5x the storage allocation. Aurora's shared-storage architecture means the 4 read replicas share the single 500 GB Aurora volume; you pay instance-hours but not duplicated storage.
| Component | RDS (1 + 4 replicas) | Aurora Standard (1 + 4 readers) |
|---|---|---|
| 5x instance-hours (r6g.large) | $1,860 | $2,232 |
| Storage (500 GB) | $285 (5x gp3 allocated) | $50 (single shared volume, consumed) |
| I/O (~1.5B reads) | Included in gp3 | $300 |
| Total/month | $2,145 | $2,582 |
RDS edges out at $2,145 versus Aurora's $2,582 here. But: if any one of the four RDS read replicas needs Multi-AZ, RDS jumps materially. If failover RTO matters, Aurora's sub-30-second failover may be worth the premium.
Aurora Serverless v2 economics
Aurora Serverless v2 prices in Aurora Capacity Units (ACUs). One ACU is roughly 2 GB memory and proportionate compute. Pricing is per ACU-hour, scaling continuously between configured min and max.
The decision:
- Spiky workloads with idle periods. Serverless v2 wins. Pay only for ACUs consumed.
- Steady-state workloads. Provisioned Aurora is usually cheaper. Serverless v2 has no RI option.
- Development / QA. Serverless v2 with a low minimum (0.5 ACU) and aggressive scale-down can cut non-prod database cost by 60 to 80 percent.
The most common Serverless v2 mistake: setting the minimum ACU too high. Many teams set min=2 by default; for development workloads, min=0.5 is appropriate and cuts idle cost by 75 percent.
When RDS is the right answer
- Single-instance workloads with predictable I/O. The Aurora premium does not pay back.
- Small databases (under 100 GB). Aurora's instance premium is not amortised.
- Heavy bulk-loading workflows. Aurora I/O charges on Standard configuration can be punitive.
- Compatibility-critical workloads. Vanilla MySQL/PostgreSQL feature parity is closer than Aurora's compatibility layer.
- SQL Server, Oracle, MariaDB. Aurora does not support these engines; RDS is the only managed option.
When Aurora is the right answer
- Workloads needing fast failover. Aurora's sub-30-second failover beats RDS Multi-AZ.
- Read-replica-heavy architectures. Aurora's shared storage means replicas are cheap to add.
- Global applications. Aurora Global Database supports cross-region replication with sub-second lag.
- Spiky workloads. Aurora Serverless v2 elasticity is unique.
- Storage-heavy workloads. Aurora's storage-consumed pricing avoids over-allocation cost.
The EDP overlay
Both RDS and Aurora roll into the broader database scope of an EDP negotiation. Specific Aurora-relevant items:
- Aurora I/O-Optimized pricing concessions on high-volume write workloads.
- Aurora Global Database data transfer discounts at multi-region scale.
- Aurora Serverless v2 ACU-rate discounts on sustained committed spend.
- Standard EDP tier discounts apply equally to Aurora and RDS instance pricing.
Migration economics: Aurora to RDS or vice versa
Migration is feasible in both directions:
- RDS to Aurora. Use AWS Database Migration Service (DMS) or Aurora's Read Replica promotion. Typical migration window: hours for small databases, days for large.
- Aurora to RDS. Less common; DMS supports it but the operational shift is larger.
The economic test: net present value of three years of cost savings minus migration project cost. Most workloads with clear engine mismatches break even in 6 to 12 months.
Action checklist
- Inventory every RDS and Aurora cluster. Classify by access pattern: read-heavy, write-heavy, mixed.
- For each Aurora Standard cluster, calculate I/O cost as a percent of instance cost. If above 25 percent, model I/O-Optimized.
- For RDS clusters with 3+ read replicas, model migration to Aurora.
- For small Aurora clusters (under 100 GB, single instance), model migration to RDS.
- For dev / QA workloads, model migration to Aurora Serverless v2 with min=0.5 ACU.
- Scope Aurora-specific items into your next EDP negotiation.
- Contact our advisory team for an Aurora versus RDS workload audit benchmarked against $2.4B+ of reviewed AWS spend.
See our AWS database cost strategy guide and RDS pricing optimization guide for how this decision rolls into the broader database picture.