RDS cost optimization gets neglected because databases feel risky to touch, so oversized instances and the wrong storage and engine choices quietly compound. The good news is that the same discipline that works on compute works here: read real utilization, rightsize, then commit on the clean baseline, and choose the engine configuration deliberately rather than by default. Done in that order, RDS savings are large and low-risk.
This article links up to our complete guide to AWS cost optimization, the pillar for this cluster. RDS sits in the Cut step of our See, Cut, Lock, Run method, and the sequencing rule is the same one we apply to EC2 rightsizing: never buy a reservation before the instance is the right size.
Rightsize the database instance first, then buy an RDS Reserved Instance on the smaller footprint. A reservation on an oversized database locks the waste in for one to three years.
Step 1: Rightsize the instance against real utilization
Databases are sized for peak and then forgotten, so most RDS fleets carry idle headroom. Pull CPU, memory, connections and IOPS over at least two weeks through CloudWatch and Performance Insights, and read the percentiles, not the average. AWS Compute Optimizer now produces RDS rightsizing recommendations as a starting point. Size against the 95th percentile of demand with sensible headroom, and watch memory and connection count as carefully as CPU, since databases are often memory and connection bound rather than CPU bound. Where read traffic is the pressure, a read replica can offload it more cheaply than scaling the primary up.
Step 2: Fix the storage, not just the instance
Storage is the quiet part of the RDS bill. Three moves matter. First, choose the right storage type: general purpose gp3 volumes let you provision IOPS and throughput independently of size, which is usually cheaper than the older io-based approach for typical workloads. Second, stop over-provisioning IOPS you never use; size them to measured demand. Third, manage snapshots and backups, which accumulate indefinitely and bill for storage; set retention deliberately and clean up manual snapshots, a topic we cover in snapshot and backup cost optimization.
Step 3: Reserve on the clean baseline
RDS Reserved Instances commit you to a database instance class in a region for one or three years in exchange for a substantial discount over on-demand. Because databases are typically long-lived and stable, they are excellent reservation candidates, often better than compute. But buy only after rightsizing, and cover the steady core rather than the peak. The same coverage and laddering discipline from Savings Plans vs Reserved Instances applies: stagger terms, watch utilization, and re-rate at renewal. Note that Savings Plans do not cover RDS, so reservations remain the commitment tool here.
Want your database spend optimized?
Our AWS cost audit reads RDS utilization, sizes the instances and storage correctly, models the reservation mix, and quantifies the saving before you touch production. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Step 4: Choose the right Aurora configuration
Amazon Aurora can be cheaper or more expensive than standard RDS depending on configuration, so the choice should be deliberate. Aurora offers two storage configurations: the standard configuration, where you pay separately for I/O, and Aurora I/O-Optimized, which bundles I/O into the instance and storage price. For I/O-heavy workloads, I/O-Optimized can be markedly cheaper and gives predictable billing; for light-I/O workloads, the standard configuration is usually cheaper. Measure your I/O profile before choosing.
Aurora Serverless v2 scales capacity in fine-grained increments and can cut cost for spiky or intermittent workloads that would otherwise pay for a provisioned instance around the clock, though steady high-utilization databases are usually cheaper on a provisioned instance with a reservation. Graviton-based database instances (the db.r7g and db.m7g families) offer better price-performance than their Intel equivalents for many engines and are often a simple, low-risk swap.
| Situation | Best fit |
|---|---|
| Steady, high-utilization database | Provisioned instance, rightsized, with a Reserved Instance |
| Spiky or intermittent workload | Aurora Serverless v2 |
| I/O-heavy Aurora workload | Aurora I/O-Optimized configuration |
| Read-heavy primary | Add read replicas before scaling up |
| Intel database on older family | Move to Graviton (db.r7g / db.m7g) |
RDS and Aurora features, families and configurations above reflect AWS offerings as of May 2026. Verify current options and pricing in the RDS console before changing production databases, as features and rates change.
The AWS Cost Optimization Field Guide includes the RDS utilization queries and the reservation model we use to size database commitments. It is the downloadable companion to this guide.
The short version
Rightsize RDS instances against p95 utilization including memory and connections, fix storage by moving to gp3 and managing snapshots, reserve the steady core on the clean baseline since Savings Plans do not cover RDS, and choose the Aurora configuration deliberately by measuring your I/O profile. When you want database spend optimized across the estate without risking production, that is what our AWS cost optimization service delivers.