AWS RDS Cost Optimisation: Where Your Database Budget Is Actually Going

AWS RDS cost optimisation: where your database budget is actually going

RDS costs don't announce themselves. They accumulate; a snapshot policy nobody touched after initial setup, a dev database that got Multi-AZ enabled "just in case," a MySQL 5.7 instance that quietly tipped into Extended Support billing in March 2024.

The frustrating part is that none of this shows up together in a single Cost Explorer view. You have to know what to look for. Here's what we consistently find when scanning accounts, and what actually fixes it.

The Multi-AZ trap: paying for redundancy nobody's using

Multi-AZ RDS deployments cost approximately twice what Single-AZ costs - AWS provisions a full standby replica in a separate Availability Zone and charges instance hours and storage for both.

For production, that's the right call. For dev and staging, it's just money out the door.

We find Multi-AZ enabled on non-production instances constantly. Usually it happened because someone copied the production Terraform module and didn't change the flag. Nobody pushed back because it was "only" a few hundred dollars a month - until you add it up across accounts.

A db.r5.large in us-east-1 costs around $175/month Single-AZ. Multi-AZ takes that to $350. Five dev databases that don't need HA is $10,500/year. Not a rounding error.

Disabling Multi-AZ requires a maintenance window and a brief reboot, which is probably why it keeps getting deferred. The window is minutes. The savings are permanent.

Storage type: the quiet 58–87% overspend on io1 volumes

Migrating from io1 or io2 to gp3 storage saves 58–87% on RDS storage costs - driven by gp3 charging $0.005/IOPS versus io2's $0.065/IOPS, a 13x difference per provisioned IOPS (CloudFix, January 2026).

io1 launched in 2012. gp3 launched in December 2020. If you provisioned an RDS volume before 2021 and never went back to it, there's a good chance you're on io1 and paying 13x more per IOPS than you need to.

A 1 TB RDS volume with 10,000 provisioned IOPS: $775/month on io1, $115/month on gp3. That's $660/month per instance. gp3 also includes 3,000 IOPS free in the base price, so many databases don't need to provision extras at all.

The migration runs live. No downtime for most RDS engines - AWS converts the storage in the background while the instance stays up.

Snapshot accumulation: the cost nobody manages

RDS manual snapshots persist after instance deletion and accumulate indefinitely unless explicitly removed. Backup storage beyond your provisioned database size costs $0.095/GB-month — and one multi-account audit found 20,000+ orphaned snapshots from already-deleted instances across 100,000+ total (AWS Database Blog, 2023).

AWS gives you free backup storage up to 100% of provisioned DB size per region. After that, you pay. Teams running 35-day automated backup retention, plus manual snapshots created before each deployment, often go over without realizing it.

Manual snapshots from deleted instances are the worst part. They don't show up in the main RDS console. You have to filter specifically for manual snapshots and then cross-reference against instances that no longer exist. It's the kind of cleanup nobody schedules until the bill gets weird.

Aurora is messier. Cluster snapshots reference shared incremental storage chains, so you can't always delete the oldest ones and call it done. Dependencies matter, and figuring them out takes a script, not a click.

Extended Support: the billing change that arrived without a new line item

AWS began charging for RDS Extended Support at $0.10/vCPU-hour starting March 2024 for MySQL 5.7, and March 2025 for PostgreSQL 12. A db.r5.large running an end-of-life engine pays an additional $1,752/year in year one - doubling to $3,504/year by year three (AWS Documentation, 2026).

No new resource. No new feature. Just a higher bill, starting on a specific date, for every instance still running an unsupported engine version.

If you didn't upgrade MySQL 5.7 to 8.0 before March 2024, you've been paying Extended Support for nearly two years. PostgreSQL 11 has been billing since March 2024. PostgreSQL 12 since March 2025.

The per-vCPU rate makes larger instances expensive fast. A db.r5.2xlarge has 8 vCPUs - at $0.10/vCPU-hour that's $576/month just to keep the engine running. Then the rate doubles in year three.

The only fix is an upgrade. That takes testing and a maintenance window, which is exactly why teams keep deferring it. But every month of deferral has a price tag. PostgreSQL 13 end-of-life is February 2026. That one's already here.

Commitment gaps: On-Demand rates on workloads that have been running for years

61% of developers don't use Reserved Instances or Savings Plans, according to Harness's 2025 survey of 700 engineering leaders - despite AWS RDS Reserved Instances offering up to 69% savings and the new AWS Database Savings Plans (December 2025) offering up to 35% on a one-year no-upfront commitment.

AWS launched Database Savings Plans in December 2025. They cover RDS, Aurora, DynamoDB, ElastiCache, and DocumentDB under one flexible commitment - not tied to a specific instance family or region. Lower risk than traditional RIs, and the savings are real.

Most teams skip commitments because the analysis feels like a whole project. It's not. Pull your Reserved Instance Coverage report in Cost Explorer, see what percentage of eligible spend has no commitment attached, and work backward from there. Datadog's 2024 cloud cost analysis found that only 29% of organizations cover more than half of their eligible spend with discounts. Everything else runs at On-Demand.

Right-size before you commit. AWS Compute Optimizer added idle RDS detection in late 2024 using 14 days of utilization history. Run it first, act on the recommendations, then buy commitments against the corrected instance size.

What to do next

RDS waste is distributed. Multi-AZ flags on dev environments, io1 storage nobody migrated, snapshots from deleted instances, end-of-life engine charges, and open commitment gaps all show up in different places. None of them are hard to fix. Most just require someone to go look.

Five checks worth running this week:

Cloudtrim runs all five automatically. It scans RDS configurations daily, flags Multi-AZ on non-production instances, calculates gp3 migration savings per volume, surfaces orphaned snapshots, identifies Extended Support charges, and generates the CloudFormation or Terraform to fix the configuration issues. Infrastructure code you review and apply, not a list of suggestions.