RDS Cost Optimization: 12 Ways to Cut Database Spend

Twelve Ways to Cut RDS and Aurora Spend

1. Stop idle non-production databases

Development, staging, and test databases run 730 hours a month unless someone stops them. RDS can stop an instance for up to seven days before it restarts automatically; scheduled stop and start outside working hours cuts a non-production database to about a quarter of its always-on cost. Audit for instances with no connections in the last week first; those should not be stopped but removed.

2. Delete orphaned snapshots

Manual snapshots and final snapshots from deleted instances persist indefinitely at $0.095 per GB-month, and accounts routinely carry terabytes of them. List snapshots whose source instance no longer exists and whose age exceeds any recovery requirement, and delete them. Set automated backup retention to what recovery actually needs, typically 7 to 14 days, rather than the 35-day maximum.

3. Remove forgotten read replicas

Each replica bills as a full instance plus its own storage copy. Replicas created for migrations, reports, load tests, or a feature that was later retired keep billing until someone notices; check each replica's read traffic and remove the ones nothing reads.

4. Get off Extended Support

Since March 1, 2026, an engine version past its standard-support window bills $0.20 per vCPU-hour in US East on top of the instance rate: about $292 a month on a 2-vCPU instance, $584 if Multi-AZ, often more than the database itself. Upgrade engine versions on a schedule that stays inside standard support, using blue/green deployments for production, and the surcharge and the unsupported-engine risk both disappear.

5. Make Multi-AZ a per-database decision

Multi-AZ provisions a synchronous standby with its own storage, doubling the two largest lines. Production databases that cannot tolerate a failover outage need it. Development, staging, test, reporting, and anything restorable from a snapshot within its recovery objective usually do not. Review each Multi-AZ instance against its real availability requirement; converting the ones that do not need it is a configuration change with no data migration.

6. Right-size on memory and query latency, not CPU

Databases are rarely CPU-bound, so CPU-based recommendations understate the risk of a downsize and overstate the opportunity on memory-bound workloads. Measure memory utilization, read and write IOPS, connections, and query p95 latency over at least four weeks, step down one class at a time with a rollback ready, and watch latency rather than utilization afterward. The method is the one in our guide to rightsizing in the cloud safely; databases are where it matters most.

7. Move to Graviton classes

db.m6g, db.r6g, and db.t4g classes run MySQL, PostgreSQL, and MariaDB at 10 to 20 percent below their Intel equivalents for comparable performance, and the switch is a class change with a short restart. For most open-source engine workloads it is the easiest 10 to 20 percent on the instance line.

8. Move storage to gp3 and size IOPS deliberately

gp3 at $0.115 per GB-month includes 3,000 IOPS (12,000 at 400 GB and above) and lets IOPS and throughput be provisioned independently; io1 and io2 at $0.125 plus $0.10 per provisioned IOPS are for workloads that genuinely need tens of thousands of consistent IOPS. Migrate gp2 and over-provisioned io volumes to gp3, and provision extra IOPS only where measured demand exceeds the baseline.

9. Choose the right Aurora configuration

Aurora Standard bills $0.20 per million I/O requests on top of instance and storage, which can be the largest line for write-heavy workloads; Aurora I/O-Optimized removes the I/O charge for about 30 percent higher instance and storage rates, and AWS suggests it pays off when I/O exceeds roughly a quarter of the cluster's cost. Check the ratio per cluster and switch the ones that qualify; it is a configuration change.

10. Let Aurora Serverless v2 scale to zero

Serverless v2 bills per ACU-hour (about $0.12 in US East) and can now scale to zero capacity when idle. Intermittent workloads, development databases, and low-traffic tenants that were provisioned instances or left at a nonzero minimum ACU pay for capacity nobody uses; set the minimum to what idle genuinely needs and let the cluster sleep.

11. Keep the application tier in the same zone

An application tier in a different Availability Zone from the primary pays $0.01 per GB each way on every query. Zone-aware placement, or routing reads to a replica in the application's zone, removes a transfer line most database owners have never seen.

12. Then, and only then, commit

With the estate right-sized, Multi-AZ decided, and the idle removed, cover the stable production baseline with Reserved Instances at up to 69 percent off for three years all upfront, or about 30 to 35 percent for one year with no upfront, or with a Database Savings Plan for flexibility across classes. Reservations cover instance hours only, so the storage, backup, and transfer levers above still matter afterward. The portfolio logic is in our guide to Reserved Instances, Savings Plans, and Spot; the database-specific rule is that a reservation bought before steps 1 to 11 locks the waste in for the term.

A Worked Example

A company runs 28 RDS instances across six accounts, about $31,000 a month. An inventory finds: nine non-production databases running always-on; 2.4 TB of snapshots whose source instances no longer exist; three read replicas with no read traffic; four instances on PostgreSQL 11, which entered Extended Support in March; nineteen Multi-AZ instances of which eleven are staging or reporting; and io1 storage on six instances provisioned for 10,000 IOPS that average 900.

Scheduling the nine non-production databases to working hours saves about $2,100 a month. Deleting the orphaned snapshots saves $230 and the three replicas $1,350. Upgrading the four PostgreSQL 11 instances removes about $1,750 of Extended Support. Converting the eleven non-production Multi-AZ instances to Single-AZ saves about $3,800. Migrating the six io1 volumes to gp3 saves about $900. Right-sizing four memory-bound production primaries one class down, with latency watched for a cycle, saves $1,600; two writer-heavy Aurora clusters move to I/O-Optimized for $1,100. Monthly spend falls from $31,000 to about $18,200, a 41 percent reduction, before a single reservation; a three-year reservation on the remaining stable production baseline then takes it under $14,000. The first $7,400 of savings required no change to any production database at all.

How Opslyft Does This

Steps 1 through 5 are inventory problems before they are optimization problems: the idle instance, the orphaned snapshot, the replica nothing reads, the engine that aged into Extended Support, and the Multi-AZ staging database are found by looking at every database resource across every account with its owner, its cost, and its history, which no single RDS console does. Atlas keeps that inventory, every instance, replica, cluster, and snapshot across AWS, with an owner and a cost on each, flags the ones with low utilization, no recent connections, or no surviving source, and traces a cost movement, Extended Support appearing on the 1st, a replica added on the 12th, to the change behind it. Its recommendations weigh each database's purpose and criticality and draw on query time, storage, and memory metrics rather than CPU alone, so the production primary and the staging copy at the same utilization get different advice, which is what makes a database recommendation safe to act on.

Explorer shows RDS and Aurora spend by instance, database, account, and team beside the EC2, EBS, and transfer around it, with the standby, replica, backup, I/O, and Extended Support lines broken out rather than folded into one RDS total, and tracked over time so the surcharge is visible the week it starts. Dimension Studio allocates shared clusters to the products and customers whose queries run on them, which turns a database bill into cost per customer. Monitor catches an RDS line that jumped, a snapshot policy that doubled backup storage, a replica that appeared, Extended Support switching on, with its root cause, routed to the owning team's Slack channel; Tickets turns each fix into an assigned item in Jira, ServiceNow, or Asana tracked to a measured saving; and Iris answers which teams' database spend grew fastest and why in plain English. The inventory step that found $7,400 in the example above runs continuously instead of once.

That is the pattern behind Purplle's first month, where idle and underutilized resources were surfaced with their cost impact within minutes of connecting and more than $200,000 was saved in a single month with no engineering time spent finding them.

The Bottom Line

Database spend grows because databases are set up carefully and then left alone, and the cheapest savings are the ones that need no migration: stop what is idle, delete what is orphaned, upgrade what has aged into a surcharge, and decide Multi-AZ per database rather than by template. Then right-size on the metrics that actually constrain a database, fix the storage and Aurora configuration, and commit the stable baseline last. Done in that order, database spend commonly falls by a third to a half, and the inventory that found it is the thing that keeps it from growing back. That continuous view is what Opslyft's cost control is built for; for the rest of the AWS bill, see our guides to AWS cost optimization and understanding AWS pricing across EC2, S3, EBS, and RDS.