On cost, RDS versus Aurora comes down to three components priced differently in each engine: compute by instance hour, storage by capacity, and I/O. Aurora compute can carry a premium per hour, but its storage scales automatically and its I/O model can make it cheaper at high throughput, especially under Aurora I/O Optimized where per request I/O charges disappear. Standard RDS on gp3 bundles a baseline of IOPS into the volume price, which makes it the cheaper home for steady, predictable, low I/O workloads. Reserved Instances discount the compute portion of both, so the storage and I/O model is what actually decides the comparison.
Most teams pick by reputation rather than by their own I/O profile, which is how they end up paying an Aurora premium for a workload RDS would have run more cheaply, or drowning a high throughput RDS instance in provisioned IOPS charges. Here is how to decide from your numbers.
How is each engine priced?
Both engines bill compute by the instance hour, and Reserved Instances discount that compute for a one or three year term by roughly 30 to 60 percent against on demand depending on term and payment option. The difference is everything around the compute.
Standard RDS attaches an EBS volume you size and pay for. On gp3 you get a baseline of throughput and IOPS included in the volume price, with the option to provision more. On io2 you pay per provisioned IOPS, which is precise but expensive at scale. Multi AZ deployments roughly double the instance cost because you run a standby. Aurora decouples storage from the instance: storage grows automatically and is billed per GB month, replicas share that storage layer so you pay compute but not duplicated storage, and I/O is billed one of two ways. Aurora Standard charges per I/O request, which is cheap when traffic is light and punishing when it is heavy. Aurora I/O Optimized removes per request I/O charges entirely in exchange for a higher compute and storage rate, which flips the math for I/O heavy workloads.
When is Aurora cheaper, and when is RDS cheaper?
| Workload profile | Usually cheaper | Why |
|---|---|---|
| Steady, predictable, low I/O | Standard RDS on gp3 | Baseline IOPS bundled in the volume price; no Aurora compute premium |
| High throughput, read heavy, many replicas | Aurora I/O Optimized | Shared storage layer for replicas and no per request I/O charges |
| Spiky or intermittent | Aurora Serverless v2 | Compute scales by capacity unit, so you stop paying for idle headroom |
| High but bursty I/O on RDS | RDS on gp3 with provisioned IOPS | Cheaper than io2 if the burst baseline is moderate |
| Very high sustained I/O | Aurora I/O Optimized | Per request I/O on Aurora Standard or io2 on RDS would dominate the bill |
The decision rule is simple to state. Pull your actual I/O rate from CloudWatch, then compare the per request I/O charge you would pay on Aurora Standard, the provisioned IOPS charge on RDS io2 or gp3, and the flat premium of Aurora I/O Optimized. Whichever is lowest for your real throughput wins. Do not guess from the engine name.
Do not forget the standby and the replicas
Two structural costs distort naive comparisons. On RDS, Multi AZ runs a full standby instance you pay for even though it serves no read traffic, so a Multi AZ RDS deployment costs roughly double the single instance figure. On Aurora, read replicas share the storage layer, so adding a replica adds compute but not another full copy of storage, which makes Aurora cheaper as the read fleet grows. If your comparison ignores the standby and the replica fleet, it will mislead you on exactly the workloads where the engines diverge most.
A scaling fintech ran a read heavy transactional database on Multi AZ RDS with three read replicas and was provisioning io2 IOPS to keep up. The per IOPS charge and the duplicated storage across replicas dominated the bill. Moving to Aurora I/O Optimized removed per request I/O charges, collapsed replica storage into the shared layer, and let the read fleet grow without multiplying storage cost. Reserved Instances then covered the steady Aurora compute. The database line fell sharply and was part of the work that left the estate materially lighter. Figures are verified against billing data and anonymized.
Where this fits in the AWS estate
Database choice is one of the larger standing levers in AWS compute spend, and it pairs with commitment strategy and storage discipline. Once you have chosen the engine, cover the steady compute with RDS Reserved Instances, and apply the same scrutiny to your caching and search tier in ElastiCache and OpenSearch cost control. The storage rate underneath it all is shaped by EBS volume rightsizing and gp3 migration. The whole estate picture lives in the AWS cost optimization guide.
Frequently asked questions
Is Aurora always more expensive than RDS?
How does I/O pricing differ between RDS and Aurora?
Do Reserved Instances apply to both RDS and Aurora?
Choose the cheaper database with us
We help enterprises decide RDS versus Aurora from their own I/O and replica profile, then cover the steady compute with the right commitments. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.