---
title: Amazon RDS and Aurora Cost Optimization
description: RDS and Aurora cost optimization: Serverless v2 fit, I/O-Optimized vs Standard, Graviton rightsizing, Multi-AZ design, RIs, Database Savings Plans, storage.
url: https://www.joinhorizon.co/services/aws-rds-cost-optimization/
category: cloud
updated: 2026-10-27
---

# Amazon RDS and Aurora Cost Optimization

> Databases are the hardest line on the AWS bill to cut, because nobody wants to touch production. We find the savings that do not need a migration first, then model the ones that do against your own CloudWatch data.

## Where Database Spend Hides

RDS and Aurora bills have more dimensions than EC2: instance class, deployment option, storage type, I/O, backup storage, and the engine itself. Teams rarely revisit any of them after launch, because the database is the one component nobody wants to break. That makes it one of the better places to find savings, as long as the work is sequenced so the risky changes come last.

## Who This Is For

This work is typically worth it when:

- RDS or Aurora is one of your top two or three AWS line items.
- Instance classes, replica counts, and storage settings have not been reviewed since the databases were created.
- You run many databases across production, staging, and per-team environments.
- You are weighing Aurora Serverless v2, I/O-Optimized, or a commitment and want the break-even worked out on your own data.
- Your Aurora I/O charges are noticeable on the bill and nobody has checked the share.

It is a poor fit when you have one or two small databases (the calculators will cover it) or a database migration is already planned that will change the engine or sizing anyway.

## Savings That Need No Migration

- **Commitments.** Steady instance classes get [Reserved Instances](https://aws.amazon.com/rds/reserved-instances/). Spend that will move across engines, families, or Regions gets a Database Savings Plan, which AWS launched in December 2025: up to 35% on serverless usage and up to 20% on provisioned instances, on a one-year term. A workload uses one or the other, not both.
- **Snapshots and backups.** Manual snapshots never expire on their own. We inventory them, set retention by environment, and remove orphans from deleted databases.
- **Non-production schedules.** Dev and staging databases that run around the clock can be stopped outside working hours, or moved to Aurora Serverless v2 with a 0 ACU minimum so they pause when idle (resume takes about 15 seconds, 30 seconds or more after a day; RDS Proxy, Global Database, and replication prevent pausing).
- **Storage.** gp3 includes 3,000 IOPS (12,000 on volumes of 400 GB and larger), and the storage autoscaling maximum threshold is set on purpose, since allocated storage cannot be reduced in place.

## Instance Rightsizing on Graviton

Graviton classes usually list below their x86 equivalents. In our RDS pricing data (us-east-1 list price, 2026-10-17), db.r8g.large is $0.239/hr against $0.25/hr for db.r6i.large on PostgreSQL. We rightsize on memory first: buffer-cache hit rate, `FreeableMemory`, and read IOPS tell you whether the working set still fits after a downsize. CPU alone does not.

## Aurora Serverless v2: Only Where the Math Works

Serverless v2 suits databases whose load is spiky, idle for long stretches, or hard to predict, such as dev and staging, per-tenant databases, and internal tools. You set a minimum and maximum ACU range, and Aurora scales within it. The minimum matters for cost and for speed: a higher minimum keeps more memory warm and scales faster, a lower one costs less when idle. On Aurora versions that support it, [a minimum of 0 ACUs enables automatic pause](https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/) after an idle period you set, between 5 minutes and 24 hours. Setting the minimum to 0.5 or higher turns pause off. Steady, busy production databases usually cost less on provisioned Graviton instances with a commitment.

Serverless v2 bills by ACU-hour, so the deciding number is the **average** ACU level across the month. At $0.12 per ACU-hour, a db.r6g.large ($0.26/hr) breaks even at about 2.2 average ACUs, which is roughly a quarter of its 16 GiB memory. Our [Aurora Serverless v2 vs provisioned comparison](https://www.joinhorizon.co/compare/aws-aurora-serverless-vs-aurora-provisioned/) has the full break-even table and a worked comparison against standard RDS. We pull `ServerlessDatabaseCapacity` or the provisioned instance's utilization from CloudWatch and put each cluster on one side of the line.

## Aurora Storage: Standard vs I/O-Optimized

Aurora Standard charges $0.10/GB-month plus $0.20 per million I/O requests (us-east-1 list price, 2026-10-17). I/O-Optimized charges $0.225/GB-month and higher instance rates, with no I/O charges. AWS's guidance is that I/O-Optimized pays off once I/O passes 25% of the Aurora bill. We calculate that share per cluster from the Cost and Usage Report, because one write-heavy cluster can justify the switch while its neighbors should stay on Standard. This is a per-cluster decision. Aurora Standard is the default for a reason: clusters with modest I/O stay cheaper on it. The [Aurora pricing breakdown](https://www.joinhorizon.co/blog/amazon-aurora-pricing-io-optimized-serverless-v2-global/) covers every billing dimension.

## Storage, Backups, and Replicas

**Storage type.** For RDS, gp3 storage includes a baseline of IOPS and throughput, so volumes that sit on gp2 or on provisioned IOPS they do not use are worth checking. Provisioned IOPS (io1/io2) should be justified by measured IOPS, not by habit.

**Storage autoscaling.** It protects against outages, but allocated storage cannot be shrunk in place. We set the maximum threshold on purpose and alert on free space, so one bulk load does not raise the bill permanently.

**Backup retention.** Automated backup retention and manual snapshots are billed beyond the free allotment. We set retention by environment: long where compliance needs it, short in dev and staging. We also remove manual snapshots whose source database no longer exists.

**Read replica consolidation.** Replicas added for a past peak keep costing every hour. We look at replica lag and read traffic per replica, and at whether an Aurora reader or a Multi-AZ DB cluster standby already covers failover, then consolidate where the numbers allow.

## High Availability Without Paying Twice

| Option | Standbys | Standbys serve reads | Pays for |
| --- | --- | --- | --- |
| RDS Multi-AZ DB instance | 1, in a second AZ | No | Two instances and two copies of storage |
| RDS Multi-AZ DB cluster | 2, across three AZs | Yes | Three instances |
| Aurora with a reader | 1 or more readers | Yes | Each reader instance; storage is shared and replicated across three AZs |

If you already pay for read replicas and a Multi-AZ standby, one of these shapes usually covers both needs. See [AWS RDS vs Aurora](https://www.joinhorizon.co/compare/aws-rds-vs-aurora/) for the engine-level comparison.

## What We Cannot Promise

Savings depend on the workload, how steady its load is, your I/O pattern, and your availability requirements. We do not promise a percentage. Downsizing carries risk if the working set no longer fits in memory. Serverless v2 costs more than provisioned for steady busy databases. I/O-Optimized costs more for low-I/O clusters. Commitments only pay off if the covered usage keeps running for the term. Multi-AZ and replicas buy availability, so cutting them is a recovery-time decision, not only a cost one.

The only figures we cite are from our published [SaaS cost optimization case study](https://www.joinhorizon.co/case-study/saas-cost-optimization-30-percent-reduction/): a total AWS bill moving from $85k to $58k a month ($27k a month, or $324k a year, a 32% reduction) with p99 unchanged. It is a composite based on anonymized client work. In it, an Aurora primary was cut from db.r6g.8xlarge to db.r6g.2xlarge and two replicas from db.r6g.4xlarge to db.r6g.xlarge, using Aurora blue/green deployment, and the Aurora instances moved onto Reserved Instances. Database rightsizing was one of three tracks, alongside Reserved Instance coverage and NAT Gateway data transfer. It is an example of the process, not a benchmark for your databases.

## Deliverables and Engagement Boundaries

**You get:**

- An assessment report covering every RDS and Aurora resource: class, engine version, deployment shape, storage, I/O share, backup retention, and commitment coverage.
- A prioritized backlog with an estimated monthly dollar value per item, calculated from your own Cost and Usage Report and CloudWatch data, plus the risk and effort of each.
- Implementation of the items you approve, either as runbooks and infrastructure-as-code changes for your team or hands-on changes under your change control.
- Governance: budgets, anomaly alerts, free-storage and commitment-utilization alerts, and a review checklist.

**Boundaries:**

- We do not buy a commitment without your written approval of the term, amount, and payment option.
- We do not change a production instance class or topology without a rollback plan and your sign-off.
- Engine migrations, schema work, and query tuning are scoped separately. See [RDS consulting](https://www.joinhorizon.co/services/aws-rds-consulting/) for those.
- This page covers RDS and Aurora. For the whole bill, see [AWS cost optimization services](https://www.joinhorizon.co/services/aws-cloud-cost-optimization-services/), and for an ongoing operating model, [FinOps consulting](https://www.joinhorizon.co/services/finops-consulting/).

## Tools and Guides

Model your current setup first. If you want a quick look at the whole account, start with the free [AWS cost audit](https://www.joinhorizon.co/aws-cost-audit/).

**Calculators**

- [RDS pricing calculator](https://www.joinhorizon.co/tools/aws-rds-pricing-calculator/)
- [Aurora pricing calculator](https://www.joinhorizon.co/tools/aws-aurora-pricing-calculator/)
- [Aurora vs RDS pricing calculator](https://www.joinhorizon.co/tools/aws-aurora-vs-rds-pricing-calculator/)
- [RDS max connection calculator](https://www.joinhorizon.co/tools/aws-rds-max-connection-calculator/)

**Guides and comparisons**

- [Aurora pricing: I/O-Optimized, Serverless v2, Global Database](https://www.joinhorizon.co/blog/amazon-aurora-pricing-io-optimized-serverless-v2-global/)
- [RDS vs Aurora: when to use which](https://www.joinhorizon.co/blog/aws-rds-vs-aurora-when-to-use-which-database/)
- [High-scale PostgreSQL cost optimization](https://www.joinhorizon.co/blog/high-scale-postgres-aws-cost-optimization/)
- [Aurora Serverless vs Aurora provisioned](https://www.joinhorizon.co/compare/aws-aurora-serverless-vs-aurora-provisioned/)
- [AWS RDS vs Aurora](https://www.joinhorizon.co/compare/aws-rds-vs-aurora/)

## Features

### Graviton Instance Rightsizing
Move from older x86 classes to Graviton db.r8g / db.m8g where the engine version supports it, and size on memory and buffer-cache hit rate rather than CPU alone.

### Aurora Serverless v2 Fit Analysis
Break-even math on your real ServerlessDatabaseCapacity history: Serverless v2 saves money only below a specific average ACU level, and we tell you which side of it you are on.

### I/O-Optimized vs Standard
Per-cluster I/O share from Cost and Usage Report data. AWS positions I/O-Optimized as the cheaper choice once I/O charges pass 25% of Aurora spend.

### Multi-AZ Design
Multi-AZ DB instance, Multi-AZ DB cluster, or Aurora readers: we match the HA shape to your recovery target so you are not paying for a standby that does nothing you need.

### Commitments: RIs and Database Savings Plans
Reserved Instances for stable instance classes and Database Savings Plans (up to 35% on serverless, up to 20% on provisioned instances, one-year term) for spend that moves across engines, families, or Regions.

### Storage and Backup Hygiene
gp3 baselines, storage autoscaling thresholds, snapshot retention policies, and orphaned manual snapshots, the small lines that add up across dozens of databases.

## Why FactualMinds

### No-Migration Savings First
Commitments, storage class, snapshot cleanup, and non-production schedules come before anything that touches the engine or the connection string.

### Published Results
Our published SaaS case study took a total AWS bill from $85k to $58k per month (32%), including database rightsizing and Aurora Reserved Instances. It is one engagement, not a forecast for yours.

### AWS Select Tier Services Partner
AWS Select Tier Services Partner with 50+ AWS certifications on staff.

### Math You Can Check
Our RDS and Aurora pricing calculators and the Serverless v2 break-even table are public, built on the same rate data we use in engagements.

## FAQ

### When does Aurora Serverless v2 cost more than a provisioned instance?
Serverless v2 bills per ACU-hour ($0.12 on Aurora Standard, us-east-1 list price, 2026-10-17), and each ACU is about 2 GiB of memory. A db.r6g.large is $0.26/hr, so Serverless v2 is cheaper only if the cluster averages below 0.26 ÷ 0.12 = about 2.2 ACUs across the month. A database that needs 16 GiB most of the day runs near 8 ACUs, which costs about 3.7× the provisioned instance. Serverless v2 wins for spiky, idle-heavy, dev, and per-tenant databases, especially with a 0 ACU minimum and automatic pause on supported Aurora versions. Resume takes about 15 seconds (30 seconds or more after a day paused), and RDS Proxy, Aurora Global Database, and logical or binlog replication keep a cluster from pausing.

### Should we switch Aurora to I/O-Optimized?
I/O-Optimized removes per-request I/O charges in exchange for higher instance and storage rates ($0.225 vs $0.10 per GB-month in us-east-1). AWS states that customers whose I/O spend exceeds 25% of their Aurora bill can save up to 40% with I/O-Optimized. Below that share, Aurora Standard is usually cheaper. We calculate the share per cluster from your Cost and Usage Report before recommending a change.

### Multi-AZ DB instance or Multi-AZ DB cluster?
A Multi-AZ DB instance keeps one standby in a second Availability Zone that does not serve reads, and you pay for both instances and both copies of storage. A Multi-AZ DB cluster runs one writer and two readable standbys in three Availability Zones, so the standbys can take read traffic. If you already run read replicas for scale, a Multi-AZ DB cluster can replace them; if you only need failover, a Multi-AZ DB instance is the simpler choice.

### Reserved Instances or Database Savings Plans for RDS?
Database Savings Plans save up to 35% on serverless usage and up to 20% on provisioned instances, with a one-year, no-upfront commitment measured in $/hour, and apply across Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, and DMS, across engines, instance families, sizes, and Regions. Three-year RDS Reserved Instances can go deeper for a specific instance class held for the full term. A given workload is covered by an RI or a Database Savings Plan, not both, so we usually cover the stable floor with RIs and the moving part with a Database Savings Plan.

### Does RDS storage autoscaling save money?
It prevents outages, not cost. Storage autoscaling grows allocated storage when free space falls to 10% or less for at least five minutes, in steps of at least 10 GiB or 10% of current storage, up to a maximum threshold you set, and only when at least six hours have passed since the last storage modification. Allocated storage cannot be shrunk in place, so a runaway log table or bulk load can raise the storage bill permanently. We set the maximum threshold deliberately and alarm on FreeStorageSpace.

### What could go wrong in a database cost project?
The usual failures are buying RIs on an instance class you are about to change, moving a steady workload to Serverless v2 and paying more, switching to I/O-Optimized on a low-I/O cluster, and downsizing on CPU when the working set no longer fits in memory. Every recommendation we make comes with the metric and the threshold behind it.

### Is my database spend big enough for an engagement to pay off?
There is no fixed cutoff. It is typically worth it when RDS and Aurora are one of your top two or three AWS line items, when instance classes have not changed since launch, or when you run many databases across environments. A single small database is usually better handled with the pricing calculators. We say so on the first call if an engagement would not pay for itself.

### Can you promise a savings percentage on our databases?
No. Savings depend on how oversized the instances are, how steady the load is, your I/O pattern, and the availability you need. Our published case study reports a 32% reduction on a total AWS bill, with database rightsizing as one of three tracks, but that is one engagement and not a forecast. We estimate dollars per item from your own Cost and Usage Report and CloudWatch data.

### Is rightsizing a production database risky?
It can be, which is why we size on memory, buffer-cache hit rate, and peak load rather than average CPU, and keep a rollback path. For Aurora and RDS, blue/green deployments let us build and validate the target configuration before cutover. A downsize that no longer fits the working set in memory is the failure we check for first.

### How many read replicas do we actually need?
Often fewer than were provisioned. Replicas added for a past traffic peak, or only as a failover target, keep costing every hour. We check replica lag, read traffic per replica, and whether an Aurora reader or a Multi-AZ DB cluster standby already covers failover, then consolidate where the numbers allow. Each replica removed is its own change with its own rollback.

---

*Source: https://www.joinhorizon.co/services/aws-rds-cost-optimization/*