Why RDS costs are so hard to control
EC2 is easy to understand: you pay for running instances, you stop them to save money. RDS is more complicated. A managed database instance bundles compute, storage, I/O, backup storage, and optionally Multi-AZ standby and read replicas into a single hourly charge. The pricing is opaque by design — AWS wants you to think of RDS as a managed service, not a collection of individually priced components.
The result: most teams have no idea what they are actually paying for with RDS. They know the instance type and approximate hourly rate, but they miss the storage I/O charges, the backup storage overages, the Multi-AZ cost for a dev database that never needs failover, and the read replicas from a load test six months ago that nobody deleted.
A systematic RDS cost optimization audit typically surfaces 30-50% savings for teams that have been running for more than a year. Here is how to run one.
Step 1: Find idle RDS instances
The highest-value target in any RDS cost audit is instances that are running but serving zero traffic. These are pure waste — you are paying full price for a managed database that nobody is using.
How to identify idle RDS
- ✓Go to CloudWatch and check DatabaseConnections — zero connections for 7+ consecutive days is a strong signal
- ✓Check CPUUtilization — sustained under 2% for two weeks suggests no real workload
- ✓Check ReadIOPS and WriteIOPS — zero for 7+ days means no data is being read or written
- ✓Look at FreeStorageSpace over time — if it is not changing, no data is accumulating
Before deleting any RDS instance, take a final snapshot. Snapshots cost $0.095/GB/month — a 100GB snapshot costs $9.50/month, compared to $175/month for a running db.r5.large. If you need to restore later, you can recreate the instance from the snapshot in minutes.
Step 2: Eliminate unnecessary read replicas
Read replicas are created for specific purposes: distributing read traffic, running analytics queries without impacting the primary, or preparing for a migration. But they are often created for a temporary purpose and then forgotten.
Every read replica costs the same as the primary instance — a db.r5.large read replica costs $175/month, identical to the primary. If you have two read replicas from a load test that ran three months ago, that is $350/month in ongoing charges for replicas that serve no traffic.
How to audit read replicas
- ✓Go to RDS > Databases and filter by Role = Replica
- ✓Check ReplicaLag in CloudWatch — if replication lag is not changing, the primary is receiving no writes and the replica is idle
- ✓Check ReadIOPS on the replica — zero means no queries are being routed to it
- ✓If a replica was created more than 30 days ago and has no read traffic, it is almost certainly safe to delete
Step 3: Right-size instance types
Database instances are often provisioned for peak load or for 'just in case' headroom. Over time, the workload changes — a service that was expected to grow sometimes does not, or a query optimization reduces CPU requirements by 60%. The instance type never gets reviewed.
Right-sizing signals to look for
- ✓Average CPU utilization under 20% over 30 days (with peak under 40%)
- ✓FreeableMemory consistently above 50% of total memory
- ✓DatabaseConnections well below the max_connections limit
- ✓ReadIOPS and WriteIOPS well below the provisioned IOPS limit
Going from db.r5.large (2 vCPU, 16GB) to db.r5.medium (2 vCPU, 8GB) saves roughly $87/month. Going down a full size class — from db.r5.xlarge to db.r5.large — saves $175/month. For databases where the workload supports it, the savings compound across your entire RDS fleet.
AWS Compute Optimizer now includes RDS recommendations. Enable it and check the RDS section for machine-learning-based sizing suggestions based on your actual utilization patterns.
Step 4: Disable Multi-AZ on non-production instances
Multi-AZ deployment doubles the cost of an RDS instance. It provisions a standby replica in a different Availability Zone, maintains synchronous replication, and automatically fails over if the primary becomes unavailable. It is the right choice for production databases where downtime has real business impact.
It is not the right choice for dev, staging, or QA databases where a few minutes of downtime is acceptable. A db.t3.medium with Multi-AZ costs $0.136/hr ($99/month). The same instance without Multi-AZ costs $0.068/hr ($50/month). If you have five non-production RDS instances with Multi-AZ enabled, disabling it saves $245/month.
How to disable Multi-AZ
Go to RDS > Databases, select the instance, and click Modify. Under Availability, change from Multi-AZ to Single-AZ. Apply immediately (there will be a brief failover event) or apply during the next maintenance window. For non-production databases, applying immediately is fine.
Step 5: Audit backup retention and storage
RDS automated backups are included in the storage cost for the first backup equal to the database size. Backups beyond that threshold cost $0.095/GB/month. A database with 500GB of storage and 30 days of backup retention can accumulate 15TB of backup storage over time — costing $1,425/month in backup storage alone.
Backup retention settings to review
- ✓Production: 7-14 days is the right balance for most teams — longer than that rarely adds recovery value
- ✓Staging: 3-7 days is enough — if staging breaks, you restore from production data anyway
- ✓Dev: 1-3 days — dev databases should be disposable by design
- ✓Check for manual snapshots that were created and never deleted — these persist indefinitely
Step 6: Consider Aurora Serverless v2 for variable workloads
For dev and staging databases that are idle overnight and on weekends, Aurora Serverless v2 is a fundamentally better cost model. It scales capacity down to 0.5 ACUs (roughly 1GB RAM) when connections drop and scales up in seconds when traffic arrives. The minimum cost is $0.06/hr at 0.5 ACUs — compared to $0.068/hr for a db.t3.micro that is running but idle.
The real benefit is that Aurora Serverless v2 can scale to near-zero during nights and weekends rather than running at full cost. For a staging database that is idle 70% of the time, Aurora Serverless v2 can reduce that portion of the bill by 80-90%.
Automating RDS cost monitoring
The steps above are a one-time audit. RDS waste accumulates continuously — every sprint, someone creates a new dev database, a new read replica for a load test, a new staging instance for a feature branch. Without automated monitoring, you are back to the same audit problem six months from now.
Driftak monitors RDS instances across all your AWS accounts and flags idle databases, forgotten read replicas, and instances with zero connections. Alerts escalate through Slack, email, and Telegram so problems get attention before they compound into months of waste. The first scan of an account that has been running for a year typically surfaces $300-$600 in RDS waste that nobody knew was there.