AWS RDS Cost Optimization

By Illusio Platform Engineering Team · Last reviewed: 2026 · 9 min read

Database infrastructure is the most critical asset in any SaaS architecture. Cost optimization must never jeopardize database resilience, automated backups, or Multi-AZ failover capabilities.

The Cardinal Rule: Never Sacrifice Resilience to Cut Costs

Some generic FinOps guides recommend disabling Multi-AZ replication on production databases to cut compute costs in half. We strongly advise against this. Saving a few hundred dollars on an RDS instance is never worth exposing a production database to hardware failure, maintenance window downtime, or unrecoverable data corruption.

Sustainable RDS cost reduction focuses on rightsizing instance classes, eliminating unused read replicas, right-sizing storage IOPS, and modernizing engine architectures.

1. Instance Rightsizing & Graviton Modernization

Evaluate CloudWatch Enhanced Monitoring telemetry over 30 days, specifically CPUUtilization, FreeableMemory, ReadIOPS, and WriteIOPS.

Databases running on older generation x86 instances (e.g. db.m5 or db.r5) should be migrated to AWS Graviton (db.m6g / db.r6g / db.r7g). Graviton database instances offer up to 20% lower hourly costs and 35–40% improved query throughput due to optimized memory architecture. Because RDS is a managed service, transitioning to Graviton requires only modifying the instance type during a planned maintenance window.

2. Storage Type Optimization: gp2 vs. gp3 vs. io1/io2

Many RDS instances still run on legacy General Purpose gp2 storage, where IOPS performance is tied directly to provisioned gigabytes (3 IOPS per GB). To achieve 3,000 IOPS on gp2, teams often provision 1,000 GB of disk space—paying for 800 GB of unused storage simply to avoid disk throttling.

Migrating to gp3 decouples storage capacity from IOPS. Baseline gp3 delivers 3,000 IOPS and 125 MB/s throughput for free at 20% lower cost per GB. Only workloads exceeding 12,000 continuous write IOPS require provisioned IOPS (io1/io2).

3. Auditing Read Replicas & Connection Pooling

Read replicas are frequently spun up to solve query latency problems that should have been addressed with database indexing or application-level connection pooling.

• Check Replica Utilization: If an RDS read replica runs at less than 10% CPU and zero replica lag, it may be redundant.
• Deploy RDS Proxy: Instead of scaling up instance sizes to handle hundreds of concurrent application connections, deploy Amazon RDS Proxy to pool connections efficiently.

4. Amazon Aurora Architecture Considerations

For Amazon Aurora (PostgreSQL/MySQL), billing is driven by instance compute, database storage, and I/O rate (per million requests):

• Aurora Standard vs. I/O-Optimized: For I/O-intensive workloads where I/O charges exceed 25% of total Aurora spend, switching to the Aurora I/O-Optimized configuration eliminates variable I/O fees entirely in exchange for a predictable compute fee.
• Aurora Serverless v2: Excellent for variable, bursty environments. However, ensure MinACU and MaxACU bounds are configured conservatively to prevent cost creep.

5. RDS Reserved Instances

Because databases are stateful and rarely undergo sudden architectural changes, production RDS instances are ideal candidates for 1-year or 3-year Reserved Instances (RI), delivering 30% to 60% discounts over on-demand rates once rightsizing is verified.