Aurora vs RDS: which costs less, priced on one database

TL;DR. For one production Postgres database with high availability and no read replicas, RDS is cheaper: in our 500 GB example, Aurora Standard loses as soon as it bills more than about 55 million I/Os a month. Add two read nodes and the answer flips, because Aurora's readers share one storage volume and one of them doubles as the standby. Aurora I/O-Optimized then comes in $29.17 a month under RDS whatever the I/O.

Aurora vs RDS comes down to how many copies of your data you pay for. RDS is cheaper per instance and bills I/O as provisioned capacity, so it wins for a single database with a standby; Aurora wins once read replicas, shrinking data or idle hours enter the picture. All prices below are US East on-demand rates for PostgreSQL from AWS's price list for Amazon RDS, publication of October 29, 2026, read on November 2, 2026.

Aurora vs RDS: which costs less for your workload

Four rate differences drive the whole table. A db.r7g.large costs $0.276 an hour on Aurora and $0.239 on RDS, 15% more. Aurora bills $0.10 per GB-month of storage the cluster actually uses, plus $0.20 per million I/Os on Aurora Standard; RDS bills gp3 at $0.115 per GB-month allocated, $0.23 on Multi-AZ, with I/O included up to a baseline. The storage and I/O lines decide the answer far more often than the instance rate.

The same database priced both ways

Consider a hypothetical Postgres database with 500 GB of data on db.r7g.large, at 730 hours a month. RDS gets 500 GB of gp3, which on PostgreSQL volumes of 400 GiB and more comes with a baseline of 12,000 IOPS and 500 MiB/s at no extra charge. Backups are assumed to stay inside each engine's free allowance.

Case A, high availability only. On RDS that is a Multi-AZ DB instance, whose standby "can't serve read traffic". On Aurora it is a writer plus one reader in another Availability Zone, the layout AWS recommends for high availability.

Aurora Standard starts $10.98 cheaper and gives that back after 54.9 million billed I/Os, about 21 per second averaged over the month. AWS counts a billed read as a page the engine fetches because it is "not in memory", and writes in 4 KB units of log, so a database whose working set fits in memory stays near the low end. I/O-Optimized costs $172.70 more than RDS at every I/O level.

Case B, high availability plus two read nodes. RDS adds two read replicas to the Multi-AZ instance. Replicas are "billed as standard DB instances" with its own 500 GB of gp3. Aurora adds a second reader; both readers serve reads, and either can be promoted if the writer fails.

RDS now pays for four instances and three copies of the data. Aurora Standard stays cheaper up to 1,367 million I/Os a month, and I/O-Optimized undercuts RDS at any volume. The two Aurora configurations cost the same at 1,221 million I/Os, which is where to switch.

The fair objection to case B: after an Aurora failover, one reader becomes the writer and you are down to one read node until you replace it. If you need two readers through a failover, price four Aurora instances. That is $855.92 on Standard, still under RDS below 359.8 million I/Os a month (about 137 per second), and $1,160.78 on I/O-Optimized, which loses.

Where Aurora pays for itself

Shared storage is the main lever. The Aurora storage guide says a new instance attaches to the cluster volume because "Aurora doesn't make a new copy of the table data". Each Aurora reader costs $27.01 a month more in compute than an RDS replica of the same class, and each RDS replica carries its own storage at $0.115 per GB-month. Above about 235 GB, before I/O, every extra reader is cheaper on Aurora.

Storage that goes back down. On RDS you can raise allocated storage in place, but "You can't deallocate space". Shrinking it takes a Blue/Green deployment, offered since November 2024, that builds the Green database at the smaller size and switches over. On current Aurora versions, dropping a table or database makes "the overall allocated space" decrease by a comparable amount. A team that purges or archives old data keeps paying for the peak on RDS until someone runs that switchover.

Backups and idle time. Both engines give free backup storage up to the size of your database storage (Aurora, RDS). Beyond it, the price list charges $0.095 per GB-month on RDS for PostgreSQL and $0.021 on Aurora PostgreSQL, 4.5 times less. For idle databases, Aurora Serverless v2 at a 0 ACU minimum pauses, and "You aren't charged for instance capacity while an instance is in the paused state"; it needs Aurora PostgreSQL 16.3, 15.7, 14.12 or 13.15 and later. RDS can stop an instance for "a maximum of 7 consecutive days", with storage and backups still billed. Aurora I/O-Optimized vs Standard works out where Serverless v2 beats a provisioned instance.

Two limits on all of this. RDS also offers a Multi-AZ DB cluster whose standbys serve reads, at $0.345 per GB-month of gp3 in the price list; it sits between the two cases and is not priced here. And these are list prices: a Database Savings Plan applies to both Aurora and RDS instances, so re-run the comparison at your committed instance rates.

How to check which one your databases need

1. List each RDS database with its copies. For every instance, note the class, whether it is Multi-AZ, how many read replicas it feeds, and allocated storage against the FreeStorageSpace metric. A database with replicas or a large unused allocation is the first candidate.
2. Price both sides with your own numbers. Aurora Standard is cheaper while billed I/Os per month, in millions, stay below (RDS bill minus Aurora instance cost minus $0.10 times used GB) divided by $0.20. Use the same formula with I/O-Optimized rates to check the flat option.
3. Measure I/O on Aurora before you move. Your RDS ReadIOPS and WriteIOPS are per-second disk I/O rates on EBS volumes, and they do not map onto Aurora's billed I/Os. AWS documents creating an Aurora read replica of an RDS for PostgreSQL instance as a migration path; its VolumeReadIOPs and VolumeWriteIOPs are the billed operations. Billed reads depend mostly on the queries it serves, so route a share of real read traffic there for a week or two. We have not run this measurement ourselves; treat it as the closest proxy available.
4. Re-run it when the shape changes. Adding a replica, purging a year of data or an I/O spike moves the break-even. RDS pricing, line by line lists every RDS meter, and what cloud databases cost puts these lines next to the rest of the data platform.

The answer is per database, and most teams run a mix: a quiet single-instance service that belongs on RDS beside a replica-heavy one that belongs on Aurora. Datapace is building one map of your data estate with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. If the I/O line is the open question, start with Aurora I/O-Optimized vs Standard and when to switch.

Sources

1. AWS, Price List API offer file for Amazon RDS, US East (N. Virginia), publication of October 29, 2026, read November 2, 2026 (instance, storage, I/O, provisioned IOPS, backup and Serverless v2 rates for RDS for PostgreSQL and Aurora PostgreSQL).
2. AWS, Amazon Aurora storage (shared cluster volume, no copy per instance, dynamic resizing, billing for used space).
3. AWS, Replication with Amazon Aurora (readers as failover targets, high-availability recommendation, Aurora read replica of RDS for PostgreSQL).
4. AWS, Amazon Aurora FAQs: billing (how read and write I/Os are counted).
5. AWS, Amazon CloudWatch metrics for Amazon Aurora (VolumeReadIOPs, VolumeWriteIOPs).
6. AWS, Scaling to zero ACUs with automatic pause and resume (billing while paused, engine versions).
7. AWS, Amazon Aurora pricing (free backup storage up to the cluster size).
8. AWS, Amazon RDS for PostgreSQL pricing (free backup storage up to total database storage in a Region).
9. AWS, Amazon RDS DB instance storage (gp3 baseline IOPS and throughput by volume size).
10. AWS, Increasing DB instance storage capacity (allocated storage cannot be deallocated).
11. AWS, Multi-AZ DB instance deployments (standby does not serve reads).
12. AWS, Working with DB instance read replicas (replicas billed as standard DB instances).
13. AWS, Stopping an Amazon RDS DB instance temporarily (7-day limit, charges while stopped).
14. AWS, Amazon RDS instance-level metrics (FreeStorageSpace).
15. AWS, Amazon RDS Blue/Green Deployments now support storage volume shrink, November 20, 2024.
16. AWS, Multi-AZ DB cluster deployments (readable standbys).
17. AWS, Database Savings Plans pricing (eligible Aurora and RDS instances).