AWS RDS Cost Optimization: The Complete Playbook for 2026

The Six Levers That Actually Move an RDS Bill

Every RDS cost optimization technique reduces to one of six levers. Getting the order right matters more than any single technique, because some levers only work correctly once the others have already been pulled.

• Rightsizing: matching instance class to actual CPU, memory, and connection load instead of launch-time guesses

• Idle resource removal: read replicas, Multi-AZ standbys, and dev/staging instances running 24/7 for workloads that no longer need them

• Storage and IOPS: storage type (gp2 vs gp3), provisioned IOPS, and Aurora's I/O billing model

• Query efficiency: queries that generate avoidable IOPS charges and inflate CPU utilisation, making an instance look bigger than it needs to be

• Commitment discounts: Reserved Instances and Database Savings Plans, which discount whatever capacity you have already decided to run

• Data transfer: egress, cross-region replication, and NAT Gateway processing charges that rarely show up until someone groups Cost Explorer by usage type

The first four levers change how much capacity you need. The fifth discounts that capacity. Pull the fifth lever before the first four, and you lock in a discount on waste instead of a discount on a right-sized bill.

Related: our diagnostic guide to why your AWS RDS bill is high

Fix Waste Before You Buy Discounts

The single most expensive sequencing mistake in RDS cost optimization is buying a 1-year or 3-year commitment before rightsizing. xlarge does not save you 69%: it locks in 69% off a bill that was already twice as large as it needed to be, for three years, with an early-termination penalty if you change your mind. The correct sequence is: rightsize compute and storage first, eliminate idle replicas and oversized Multi-AZ standbys second, fix the queries generating avoidable IOPS third, and only then commit to Reserved Instances or a Database Savings Plan against the resulting, correctly-sized footprint.

Run this sequence once a quarter, because the right answer drifts as traffic and query patterns change. A commitment purchased against last quarter's footprint is already stale by the time it activates if the underlying workload has shifted.

Use AWS Compute Optimizer Instead of Guessing

AWS Compute Optimizer now generates rightsizing recommendations for RDS MySQL, PostgreSQL, MariaDB, and both Aurora MySQL- and PostgreSQL-compatible editions, using 14 days of CloudWatch utilisation history it already has access to. Instead of manually pulling CPU and memory metrics per instance, Compute Optimizer scores every instance as Optimized, Over-provisioned, or Under-provisioned, and recommends a specific target instance class with the projected utilisation at that size. It is free, requires no agent, and needs only to be enabled once at the account or AWS Organizations level.

The catch: Compute Optimizer looks at CPU, memory, and network, but not query-level I/O efficiency, so pair its recommendations with a pg_stat_statements review before downsizing an instance that is CPU-idle but I/O-heavy from unindexed queries. A rightsizing recommendation on an instance with a fixable query problem will still be undersized once the query gets fixed and load patterns change.

# Enable Compute Optimizer for RDS (one-time, account-level)
aws compute-optimizer update-enrollment-status --status Active

# Pull RDS rightsizing recommendations
aws compute-optimizer get-rds-database-recommendations \
  --query 'rdsDatabaseRecommendations[*].{
    ID:dbInstanceArn,
    CurrentClass:currentDBInstanceClass,
    Finding:finding,
    Recommended:instanceFindingRecommendationOptions[0].dbInstanceClass
  }' \
  --output table

Related: a pg_stat_statements-driven query review

Reserved Instances vs. Database Savings Plans

AWS launched Database Savings Plans in December 2025, and it changes the commitment-discount decision for RDS. Reserved Instances still offer the higher ceiling: up to 69% off On-Demand on a 3-year All Upfront term, but the discount is locked to a specific instance family, size, region, and engine. Change instance families or move workloads between regions, and the reservation stops matching.

Database Savings Plans discount up to 35% for a 1-year hourly-spend commitment, with no upfront payment, and the discount follows the workload automatically: it applies across Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, and more, regardless of engine, instance family, size, Availability Zone, or region. r8g, shift a workload from PostgreSQL to Aurora PostgreSQL-Compatible, or relocate a region, and the commitment keeps applying without a stranded reservation.

• Choose Reserved Instances when: the instance family, size, and region are genuinely stable for 3 years and you want the maximum discount ceiling

• Choose Database Savings Plans when: you expect to change instance families, migrate engines, or move regions within the commitment term, and 35% flexible beats 69% rigid

• Mix both when: your baseline, stable production footprint gets Reserved Instances and everything still in flux (recent migrations, instances you rightsized in the last quarter) gets a Savings Plan

Migrate to Graviton for an Immediate Price-Performance Gain

m6g/m7g/m8g) are AWS's Arm-based alternative to the equivalent Intel and AMD classes, and they deliver better price-performance at the same or lower on-demand rate on RDS and Aurora. The safest first move is non-production and read replicas: replicas can be swapped to a Graviton class and validated under real replication load with zero risk to the primary, and most PostgreSQL and MySQL workloads run unmodified on Arm, since the compatibility risk is almost always in third-party extensions rather than the core engine. small tier (750 hours/month, through December 31, 2026) specifically for testing compatibility before committing production instances.

Once a read replica has run clean on Graviton for a full traffic cycle (including peak load and any batch or reporting jobs), promoting the primary to the same class is a routine instance-class change, not a migration.

# Change a read replica to a Graviton instance class
aws rds modify-db-instance \
  --db-instance-identifier prod-postgres-replica \
  --db-instance-class db.r7g.xlarge \
  --apply-immediately

# Verify the engine and extensions after the switch
aws rds describe-db-instances \
  --db-instance-identifier prod-postgres-replica \
  --query 'DBInstances[0].{Class:DBInstanceClass,Engine:Engine,Version:EngineVersion}'

Aurora I/O-Optimized: Fix the Bill When I/O Is the Real Problem

This one only applies if you are on Aurora, or are evaluating an Aurora migration. Standard Aurora bills every read and write request separately, on top of storage and compute. Aurora I/O-Optimized removes per-request I/O charges entirely, in exchange for roughly 30% higher compute pricing and roughly 125% higher storage pricing.

That trade only pays off past a specific threshold: when I/O charges already account for more than about 25% of your total Aurora bill, switching to I/O-Optimized typically saves 20-40% overall, because the eliminated per-request charges outweigh the higher fixed rates. Below that threshold, I/O-Optimized costs more than Standard for the same workload, since you are paying a premium for I/O elimination you are not generating enough I/O to justify. Pull your Aurora billing breakdown in Cost Explorer, isolate the I/O line item as a percentage of total Aurora spend, and only switch if it clears 25%.

AWS allows switching to I/O-Optimized once every 30 days and back to Standard at any time, so this is a low-risk test to run directly against your own billing data rather than a rule of thumb.

Related: our guide to migrating off end-of-life engine versions, including the RDS-to-Aurora path

Storage: The Two-Command Fix Most Teams Still Haven't Made

If any instance is still on gp2 storage, migrating to gp3 is close to a free win: gp3 includes 3,000 IOPS and 125 MB/s throughput in the base price, where gp2 caps baseline IOPS at 3 per GB and charges separately once you exceed it. The migration runs live, with no downtime and no maintenance window. We cover the full gp2-to-gp3 math and the storage-waste checklist (retained snapshots, backup retention on non-production databases) in detail elsewhere; the two commands below are the fix itself.

# Check which instances are still on gp2
aws rds describe-db-instances \
  --query 'DBInstances[?StorageType==`gp2`].{ID:DBInstanceIdentifier,AllocatedGB:AllocatedStorage}' \
  --output table

# Migrate to gp3 — live, no downtime
aws rds modify-db-instance \
  --db-instance-identifier prod-postgres \
  --storage-type gp3 --iops 3000 --storage-throughput 125

Related: the full gp2 vs gp3 breakdown and storage-waste checklist, the Database FinOps guide

Cut Data Transfer Costs With VPC Endpoints

09/GB for the first 10 TB. 02/GB. 045/GB processing fee on top of whatever the destination costs.

01/hour per Availability Zone it is deployed in, and keeps traffic on the AWS private network instead of routing through a NAT Gateway or the public internet. For any application server and RDS instance that sit in the same VPC but cross a NAT Gateway path today, a VPC endpoint is usually the cheaper route within the first few TB of monthly traffic. The audit: filter Cost Explorer by Usage Type for DataTransfer-Out-Bytes and DataTransfer-Regional-Bytes, grouped by linked account, to see whether this line item is worth fixing before you invest in anything else on this list.

# Find data transfer charges tied to RDS traffic
aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY \
  --filter '{"Dimensions":{"Key":"USAGE_TYPE_GROUP","Values":["EC2: Data Transfer - Internet (Out)"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --metrics BlendedCost

Putting It Together: A Priority Matrix

Not every lever deserves the same urgency. Sequence the work by effort against impact rather than tackling it alphabetically.

• This week (low effort, immediate impact): run Compute Optimizer, migrate any remaining gp2 storage to gp3, and remove read replicas with near-zero connections

• This month (moderate effort): migrate non-production instances and read replicas to Graviton classes, and audit data transfer charges for a NAT Gateway to VPC endpoint swap

• This quarter (requires modeling): decide between Reserved Instances and Database Savings Plans against your rightsized footprint, and, if you run Aurora, test I/O-Optimized against your actual I/O share of the bill

A mid-size SaaS company running this sequence against $11,400/month in combined RDS and Aurora spend: Compute Optimizer flagged two over-provisioned instances (saving $1,150/month after rightsizing), three non-production replicas moved to Graviton classes at equivalent performance for 12% less ($240/month), and a Database Savings Plan replaced On-Demand pricing on the now-correctly-sized fleet (saving $2,600/month). Total: $11,400 to $7,410 per month, without a single Reserved Instance purchase or Aurora migration. Optimization gets you here. Keeping it here as traffic and instance mix keep changing is what Database FinOps is for.

Related: the Database FinOps guide, our database engineering service