Often the single largest AWS line item

AWS RDS cost optimization

Managed databases are often the largest line on an AWS bill, and the easiest to over-provision. Right-sizing, Graviton, and storage choices routinely cut RDS spend by 20 to 40 percent.

Why the waste happens

  • Instances are sized for a launch-day peak that never returns, then never scaled back down.
  • Databases stay on Intel (r5, m5) instead of Graviton (r6g, m6g), which is typically 10 to 20 percent cheaper for the same performance.
  • Multi-AZ is left enabled on dev, test, and staging databases that do not need failover.
  • Provisioned storage and IOPS are set high once and forgotten; old-generation gp2 volumes are never moved to gp3.
  • Idle read replicas and long backup-retention windows quietly add cost.

How to spot it

  • Instances with consistently low CPU utilization and few active connections.
  • Non-Graviton instance classes (names without a g, like db.r5 or db.m5).
  • Multi-AZ enabled on databases tagged non-production.
  • gp2 storage volumes, or provisioned IOPS far above actual usage.

The fix

  • Right-size to the smallest class that holds your real peak, then buy Reserved Instances for the steady baseline.
  • Migrate to Graviton (r6g/m6g/m7g) for a same-performance discount with a minor-version change.
  • Disable Multi-AZ on non-production databases; enable it only where failover is required.
  • Move gp2 storage to gp3 and align provisioned IOPS with measured demand; trim backup retention to policy.

Find every RDS issue in one scan

Cloud Cost Analyzer evaluates every RDS and Aurora instance against rules for under-utilization, over-sizing, non-Graviton classes, non-prod Multi-AZ, storage generation, backup retention, and idle read replicas, each with an estimated monthly saving and the specific change to make.

$ cca scan --provider aws

Read-only, runs in about 5 minutes. Free tier, no credit card.

RDS cost FAQ

How can I reduce my AWS RDS costs?+

The highest-impact moves are right-sizing over-provisioned instances, migrating to Graviton instance classes (typically 10 to 20 percent cheaper), disabling Multi-AZ on non-production databases, moving gp2 storage to gp3, and buying Reserved Instances for steady-state workloads.

Is migrating RDS to Graviton risky?+

For most engines it is a modify-instance-class change with a short failover, not a data migration. Test in a non-production copy first. The pricing benefit is usually 10 to 20 percent for equivalent performance.

Should non-production databases use Multi-AZ?+

Usually not. Multi-AZ roughly doubles the instance cost to provide automatic failover, which dev, test, and staging environments rarely need. Reserve it for production databases with an availability requirement.

More cost guides

NAT Gateways

Idle gateways and avoidable data-processing charges, one per AZ.

EBS volumes

Orphaned volumes, old snapshots, and gp2 you never moved to gp3.

Load balancers

ALBs and NLBs with no targets or near-zero traffic, still billing.

S3 storage

Cold data sitting in Standard with no lifecycle policy.

EC2 instances

Idle and oversized instances, previous-gen types, 24/7 dev boxes.

Aurora

Oversized instances, Serverless v1, and I/O-Optimized breakevens.

ElastiCache

Idle cache clusters and oversized, non-Graviton nodes.

CloudFront

Idle distributions and price classes wider than your audience.

DynamoDB

On-demand billing on steady workloads, and unused indexes.

Lambda

Over-provisioned memory and x86 functions that could be arm64.

See what you are overpaying for

Point a read-only CLI at your account and get a ranked fix list with dollar amounts. Free tier, no credit card.