AWS RDS Cost Calculator

Amazon RDS has a reputation for bills that do not match estimates, and the reputation is earned for a specific reason: the estimate prices the database, and the bill prices the deployment. The database is one instance at one hourly rate. The deployment is that instance plus a synchronous standby in another zone, plus the storage that both of them carry, plus the backups that kept accruing after the instance was replaced, plus the read replica from the migration, plus, since March 2026, a surcharge that switches on by calendar when an engine version ages out of support. Each is a checkbox or a default; together they are why a $128 database costs $400.

The calculator below prices an RDS deployment the way AWS bills it, with every one of those lines as an input, so the estimate matches the invoice rather than the brochure. The page around it explains the pricing model, works an example, and is honest about what even a complete estimate cannot see, which is the orphaned snapshot and the forgotten replica that only a live inventory finds. Rates are from the official RDS pricing page for US East as of October 2026.

How Amazon RDS Pricing Works

Seven meters, one of which most people quote.

Two multipliers explain most surprises. Multi-AZ provisions a standby instance with its own storage copy, so instance hours and storage both double (triple for a two-standby cluster); it is the right default for production and the wrong default for everything else. And Extended Support is a calendar event: an engine version that was free to run on a Monday carries $0.20 per vCPU-hour on the Tuesday its standard support ends, which on a 2-vCPU Multi-AZ instance is about $584 a month for the same database.

A Worked Example

A production PostgreSQL database on a db.m6g.large with 100 GB of gp3 storage, which is the calculator's default. Single-AZ and on-demand, the instance is about $116 a month and storage $11.50: about $128. That is the number the estimate usually stops at.

Enable Multi-AZ with one standby and instance hours and storage both double: about $255. Add the read replica created for last quarter's migration and never removed: another $128. Set backup retention to 35 days on a database that churns, which keeps about 150 GB beyond the free allowance: $14. The app tier in another zone moves 500 GB a month across the boundary: $10. Total: about $407 a month, more than three times the $128 estimate, with no change to the database itself. Now suppose the engine is PostgreSQL 11 and standard support ended: Extended Support at $0.20 per vCPU-hour on 2 vCPUs across three nodes adds about $876, and the bill passes $1,280. Upgrade the engine and remove the replica and it falls back to about $280; reserve the primary and standby for three years and the compute line falls by about 60 percent on top.

What the Calculator Cannot See

A complete estimate still prices only what you knew to enter. Five things appear on RDS bills that nobody enters.

• Orphaned snapshots. Manual snapshots and final snapshots from deleted instances persist and bill at $0.095 per GB-month indefinitely. Accounts commonly carry terabytes of them.
• The forgotten replica. Read replicas created for migrations, reports, or load tests and never removed bill as full instances.
• Extended Support switching on. It arrives by calendar, not by decision, and the first sign is usually the invoice.
• Oversized classes. A db.r6g.xlarge at 8 percent CPU is paying for memory it may not need; the estimate prices what was provisioned, not what was used.
• Idle non-production. Development and staging databases run 730 hours a month unless someone stops them; RDS can stop an instance for seven days, after which it restarts automatically.

These are the database versions of the pattern in our guide to where cloud waste hides, and the reason an estimate, however complete, is a floor rather than a forecast.

From Estimate to Real Spend

The button under the result exists because the bill contains things the estimate cannot. Opslyft reads RDS cost from your actual AWS bill and shows it in Explorer by instance, database, and team, beside the EC2, EBS, and transfer around it, with the standby, replica, backup, and Extended Support lines broken out rather than folded into one RDS total, and tracked over time so the surcharge appearing is visible the week it starts. Atlas inventories every instance, replica, and snapshot with an owner and a cost, which is how the orphaned snapshots and the migration replica get a name next to them, and its recommendations weigh purpose and criticality and draw on query time and storage metrics, so a production database and a staging one at the same utilization get different advice. Monitor catches an RDS line that jumped with its cause and routes it to the owning team, and Tickets turns the fix, an engine upgrade, a replica removal, a snapshot retention rule, into an assigned item with the saving measured.

How to Pay Less for RDS

• Make Multi-AZ a per-database decision; production yes, everything else usually no.
• Upgrade engine versions before standard support ends, on a cadence, so Extended Support never switches on.
• Audit replicas and snapshots quarterly; set snapshot retention and remove what nothing reads.
• Right-size classes on CPU, memory, and query latency, and prefer Graviton (db.m6g, db.r6g) for 10 to 20 percent less.
• Stop non-production instances outside working hours.
• Reserve the steady production baseline after right-sizing, not before.
• Keep the application tier in the same zone as the primary to avoid paying cross-AZ transfer both ways.

For how RDS fits the rest of the AWS bill, see our guides to understanding AWS pricing across EC2, S3, EBS, and RDS and the AWS Pricing Calculator; for the general discipline, our AWS cost optimization guide.