Where Your RDS Bill Really Goes — and How to Cut It

Managed databases are one of the largest lines on many AWS bills, and one of the least reviewed. Nobody decides to overspend: an instance is sized up during an incident and never sized back down, a staging environment is created as a copy of production, a manual snapshot is kept "just in case". Each decision is reasonable on its own. Together they add up.

This is where we look first when reviewing Amazon RDS and Aurora spend — and, just as important, what we leave alone.

1. Tune before you right-size

The most effective cost reduction is often a performance fix. If a handful of inefficient queries keep CPU at 70%, the instance looks correctly sized — until the queries are fixed and the same workload runs comfortably on a class or two smaller. Look at pg_stat_statements (or Performance Insights) before you look at instance classes.

2. Right-size the instances

Then look at CloudWatch over at least a few weeks, including peaks: CPU utilisation, freeable memory, and read and write IOPS. Instances that rarely exceed 20–30% CPU and have plenty of free memory are candidates for a smaller class. Also compare instance families: Graviton-based classes usually offer better price-performance than their x86 equivalents for PostgreSQL and MySQL workloads. Memory matters more than CPU for most databases, so don't downsize below the point where the working set no longer fits in cache.

3. Check storage type and size

• gp2 to gp3. General-purpose gp3 storage decouples IOPS and throughput from volume size and is generally cheaper per GB than gp2. Many databases on gp2 were made larger than necessary simply to get more IOPS.
• Provisioned IOPS. io1 and io2 volumes are often provisioned for a peak that happens rarely. Compare provisioned IOPS with actual usage.
• Storage only grows. RDS storage autoscaling increases allocated storage but never shrinks it, and allocated storage cannot be reduced in place. If a large amount of data was deleted or archived, reclaiming the space means migrating to a new, smaller instance.

4. Aurora: watch the I/O line

Aurora Standard charges separately for I/O requests, and for I/O-heavy workloads that line can rival the instance cost. Aurora I/O-Optimized removes per-request I/O charges in exchange for higher instance and storage prices; AWS's own guidance is that it tends to pay off when I/O makes up more than about a quarter of your Aurora spend. Check the split in Cost Explorer before choosing.

5. Non-production environments

Development, test and staging databases rarely need what production needs:

• Multi-AZ doubles the instance cost and is almost never needed outside production.
• Smaller instance classes are usually fine for development and testing.
• Instances that are only used during working hours can be stopped outside them. Note that RDS restarts a stopped instance automatically after seven days, so this needs a schedule, not a one-off action.

6. Replicas, snapshots and old versions

• Read replicas created for a project or a report that no longer runs.
• Manual snapshots — unlike automated backups, they are kept until someone deletes them, and cross-region copies are billed again in every region.
• Old major versions. Engine versions past the end of standard support are automatically enrolled in RDS Extended Support, which is charged per vCPU-hour. An upgrade removes that line entirely.

7. Commit only after you right-size

For steady workloads, reserved instances give substantial discounts over on-demand prices. Buy them last: committing for one or three years to an oversized instance locks in the waste.