List-price math only. Real RDS and Aurora bills can be cut further with Reserved Instances (1-year or 3-year terms, 30-60 percent off), Aurora I/O-Optimized for high-throughput workloads, and rightsizing instance shapes against actual Performance Insights data. The deep audit models your real Cost and Usage Report to rank reduction wins by dollar impact.
| Line item | Math | Monthly |
|---|---|---|
| — | ||
| Instance shape | RDS MySQL $/hr | RDS Postgres $/hr | Aurora MySQL $/hr | Aurora Postgres $/hr |
|---|---|---|---|---|
| db.t4g.medium (Small) | $0.073 | $0.082 | $0.082 | $0.090 |
| db.r6g.large (Medium) | $0.240 | $0.250 | $0.290 | $0.300 |
| db.r6g.4xlarge (Large) | $1.920 | $2.000 | $2.320 | $2.400 |
| Line item | RDS | Aurora Standard |
|---|---|---|
| Storage ($/GB-mo) | $0.115 (gp3, doubled for Multi-AZ) | $0.10 (3-AZ replicated, single rate) |
| I/O requests | Bundled into storage | $0.20 per 1M requests |
| Serverless v2 ACU rate | — | $0.12 per ACU-hour |
One-page checklist covering the biggest database cost levers — Reserved Instance commitment timing, when to switch from Aurora Standard to I/O-Optimized, the Serverless v2 min-ACU trap that quietly inflates idle cost, read-replica vs Aurora reader cost comparison, gp3 vs io2 storage choice, the Multi-AZ overprovisioning pattern, snapshot retention cost creep, backup window pricing surprises, cross-region replication egress, and the Aurora Global Database secondary-region cost. PDF sent to your inbox.
RDS Multi-AZ: instance_hourly × 730 × (multi_az ? 2 : 1) + storage_gb × $0.115 × (multi_az ? 2 : 1)
Aurora Standard: instance_hourly × 730 + storage_gb × $0.10 + (io_millions × $0.20) — one writer instance, replication handled by shared storage layer across 3 AZs.
Aurora Serverless v2: avg_acu × $0.12 × 730 + storage_gb × $0.10 + (io_millions × $0.20)
Example: db.r6g.large MySQL, 100 GB storage, 10M I/O requests, Multi-AZ on. RDS = $0.24/hr × 730 × 2 + 100 × $0.115 × 2 = $350.40 + $23 = $373.40/mo. Aurora Standard = $0.29/hr × 730 + 100 × $0.10 + 10 × $0.20 = $211.70 + $10 + $2 = $223.70/mo. Aurora Serverless v2 at 2 ACU avg = 2 × $0.12 × 730 + $10 + $2 = $175.20 + $10 + $2 = $187.20/mo. The 730 hours/month convention matches AWS billing (365.25 × 24 / 12).
RDS becomes cheaper than Aurora Standard when storage is small relative to compute and I/O volume is high. Aurora charges per-million I/O requests on top of instance and storage, while RDS bundles I/O into the gp3 storage rate. For db.r6g.large with 100 GB storage, RDS Multi-AZ runs about $373/mo (instance $350.40 + storage $23) while Aurora Standard runs about $222/mo ($211.70 instance + $10 storage). Aurora wins easily — but add 100M I/O requests/mo and Aurora gains another $20 in I/O charges. At 500M I/O the I/O charge alone is $100/mo. RDS pulls ahead on write-heavy OLTP and batch ETL where Aurora's per-I/O pricing punishes throughput. For read-heavy workloads with moderate I/O, Aurora's single-instance model and cheaper storage almost always wins.
Aurora meters I/O at $0.20 per million on the Standard storage tier, and most teams have no idea what their I/O volume actually is until the first bill lands. Every page read counts as one I/O request, every transaction commit triggers multiple writes. A modestly busy OLTP database doing 50 TPS sustained generates 100-500M I/O requests/mo, adding $20-100 to the monthly bill not in the original estimate. The fix when I/O is high: Aurora I/O-Optimized, which charges 30 percent more for instance hours and about 125 percent more for storage but includes unlimited I/O. Break-even is around 25-30 percent of base instance cost in monthly I/O charges. If your I/O bill exceeds about $60/mo on a $200 instance, I/O-Optimized starts paying for itself.
Serverless v2 prices on Aurora Capacity Units (ACU), not fixed instances. 1 ACU = 2 GB memory plus corresponding compute, billed at $0.12 per ACU-hour. The cluster auto-scales between configurable min and max ACU based on real load, so you pay only for what you use. Right pick when load is bursty or unpredictable — dev and staging environments idle most of the day, multi-tenant SaaS with variable customer usage, internal analytics that runs heavy queries for hours then sits idle. Loses to provisioned when load is sustained and well-understood: the per-ACU rate is roughly 1.4x what an equivalent provisioned instance costs at full utilization. 4 ACU all month costs about $350 on Serverless v2 vs about $211 on db.r6g.large provisioned. Crossover: if average utilization is under about 70 percent of the smallest provisioned instance that handles peak, Serverless v2 likely saves money.
RDS Multi-AZ runs a synchronous-replicated standby in a different AZ. On primary failure, AWS promotes the standby by updating DNS, completing in 60-120 seconds. The standby is invisible to your application — you cannot route reads to it. Aurora replicates the storage layer across 3 AZs with 6 copies of every page. Compute instances are stateless front-ends to that shared storage. Primary failure triggers failover to one of the (configurable, 0-15) reader instances, typically in 30 seconds because no storage rebuild is needed. Aurora readers actively serve traffic from the same shared storage as the writer. Cost implication: RDS Multi-AZ doubles instance cost for an invisible standby; Aurora Standard with one reader costs roughly the same as the writer alone plus storage, and the reader is queryable. For active-active read scaling, Aurora's model is structurally cheaper per useful instance.
No. Engine choice, workload size, storage GB, Multi-AZ flag, I/O volume, mode toggle, and ACU usage all run locally in your browser. The page fires an anonymous pageview beacon and CTA-click events so we can measure whether the calculator is useful — no inputs, no email (unless you submit one to the cheat-sheet form), no IP stored raw.