Skip to main content

RDS & Aurora Cost Optimization

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.

  1. The RDS and Aurora bill is split into instance, storage, I/O, and backup.
  2. Instances are rightsized to a Graviton class.
  3. Serverless v2 is used only where average ACUs beat the instance.
  4. Storage moves to I/O-Optimized or gp3 where the math says so.
  5. Multi-AZ is matched to the real availability target.
  6. The result is lower database spend without a new outage risk.

Last updated:

Built forAWS Solutions for DevOps & Platform EngineersFor CTOs
Industries servedSaaSStartups
Ask AI:ChatGPTClaudePerplexityGemini

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.

Savings That Need No Migration

  • Commitments. Steady instance classes get Reserved Instances. Spend that will move across engines, families, or Regions gets a Database Savings Plan, which AWS launched in December 2025 with savings up to 35% on a one-year term.
  • 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.
  • Storage. gp3 includes 3,000 IOPS, 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 for us-east-1, 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 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 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. 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. The Aurora pricing breakdown covers every billing dimension.

High Availability Without Paying Twice

OptionStandbysStandbys serve readsPays for
RDS Multi-AZ DB instance1, in a second AZNoTwo instances and two copies of storage
RDS Multi-AZ DB cluster2, across three AZsYesThree instances
Aurora with a reader1 or more readersYesEach 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 for the engine-level comparison.

Start With the Calculators

Model your current setup in the RDS pricing calculator and the Aurora pricing calculator before an engagement. If you need database design or migration work rather than cost work, see RDS consulting. For a published example of the full cost process, see our SaaS cost optimization case study, which took a monthly AWS bill from $85k to $58k.

Key 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%, 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 Choose 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 cost-optimization engagements average 35% AWS cost reduction. One SaaS client went from $85k to $58k per month (32%), and that case study is published in full.

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.

From Our Blog

In-depth guides and best practices from our certified AWS architects.

Frequently Asked Questions

When does Aurora Serverless v2 cost more than a provisioned instance?
Serverless v2 bills per ACU-hour ($0.12 in us-east-1 on Aurora Standard), 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.
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% 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. 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. 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.

Find the Savings in Your Database Fleet

Share a Cost Explorer export and CloudWatch read access, and we will map instance, storage, HA, and commitment savings per database.