Every RDS database running on-demand is paying a premium for flexibility that most production databases do not need. Reserved instances eliminate that premium by trading a scheduling commitment for a pricing discount. You agree to run a specific database type for 1 or 3 years AWS charges you 33-69% less for it.
Getting the most out of RDS RIs requires more than clicking "Purchase RI" in the console. The teams that extract maximum savings understand size flexibility mechanics, avoid reserving oversized instances, know which engines get flexibility and which don't, and monitor utilization so underused reservations get caught early.
What an RDS Reserved Instance Actually Is
An RDS RI is not a physical server or a specific database instance. It is a billing discount that AWS applies automatically when a running database's attributes match the reservation.
At purchase you specify: engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), instance family, deployment type (Single-AZ or Multi-AZ), region, term (1-year or 3-year), and payment option (No Upfront, Partial Upfront, All Upfront). AWS then applies the reserved rate to any matching running database in your account no tagging, no assignment, no config change required.
Key mechanic: the RI is a billing artifact, not a resource. Nothing changes about your database. If you delete the database, the RI keeps billing until the term expires. This is why buying the right RI matters, an unused RI that matches nothing is pure waste.
How Much Do RDS RIs Actually Save?
Savings range from ~33% on 1-year No Upfront to up to 69% on 3-year All Upfront, depending on engine and instance family. Using verified MySQL on Graviton4 rates in US East (Vantage.sh, May 2026, sourced from AWS API):
- db.r8g.large Single-AZ: $0.239/hr on-demand → $0.160/hr reserved. Saves $692/year.
- db.r8g.xlarge Single-AZ: $0.478/hr on-demand → $0.320/hr reserved. Saves $1,384/year.
- db.r8g.xlarge Multi-AZ: $0.956/hr on-demand → $0.640/hr reserved. Saves $2,768/year.
A fleet of 10 db.r8g.xlarge Single-AZ instances at 1-year No Upfront: $13,840/year in savings. Verify current rates at aws.amazon.com/rds/mysql/pricing — rates change.
The biggest absolute savings come from reserving your largest and most stable instances first. Prioritize by monthly on-demand cost, not by percentage savings.
For a full engine-by-engine pricing breakdown, the RDS Reserved Instances pricing guide covers every engine and payment option in detail.
Does RDS Have Convertible Reserved Instances?
No and this is one of the most common points of confusion for teams coming from EC2 RI management.
EC2 offers Standard and Convertible RIs. RDS offers only Standard. There are no Convertible RDS Reserved Instances. What RDS does offer is size flexibility, which is a different mechanic entirely. If you need flexibility to change configurations mid-term, use 1-year terms or evaluate the AWS Database Savings Plan.
Size Flexibility: Which Engines Get It and How It Works
Size flexibility lets a single RI cover multiple database sizes within the same family, using normalization units:
db.micro = 0.5 | db.small = 1 | db.medium = 2 | db.large = 4 | db.xlarge = 8 | db.2xlarge = 16 | db.4xlarge = 32
A db.r8g.xlarge RI (8 units) automatically covers 2x db.r8g.large (4 units each), or 4x db.r8g.medium (2 units each), or any combination totaling 8 units. It also covers 50% of a db.r8g.2xlarge the remaining 50% bills at on-demand.
Engines with size flexibility: MySQL, MariaDB, PostgreSQL, Aurora, Oracle BYOL.
Engines without size flexibility: Microsoft SQL Server (LI or BYOL), Oracle License Included. These require exact-size reservations. A db.r8g.xlarge SQL Server RI covers only db.r8g.xlarge SQL Server nothing else.
This distinction matters enormously for SQL Server and Oracle LI teams. Every size change requires a new RI purchase. For MySQL, PostgreSQL, and MariaDB, size flexibility provides coverage continuity even after downsizing or splitting instances.
The Six-Step Purchase Process
Step 1: Right-Size Before You Reserve Anything
Reserving an oversized database locks the waste in for 1-3 years. A 33% discount on an instance running at 40% utilization saves less than the same discount on a correctly-sized instance at 80%.
Run a 30-day CloudWatch analysis before purchasing any RI. Four metrics matter:
- CPUUtilization: P90 below 40% = over-provisioned on compute
- FreeableMemory: consistently above 25% of total RAM = over-provisioned on memory
- DatabaseConnections: check against the max_connections ceiling for the proposed smaller size
- BufferCacheHitRatio: above 99% = working set fits in current buffer pool, downsizing RAM may be safe
The financial case for right-sizing first: a db.r8g.xlarge RI saves $1,384/year. A db.r8g.large RI saves $692/year AND the base compute is $692/year cheaper. Right-sizing before reserving doubles the effective savings on that oversized instance.
Step 2: Check Extended Support Status Before Purchasing
If any target database is running MySQL 5.7 or PostgreSQL 11, stop. These are in Year 3 Extended Support since March 1, 2026 ($0.200/vCPU-hr surcharge). The Extended Support charge is not reduced by reserved instances.
For a db.r8g.xlarge MySQL 5.7 (4 vCPUs): Extended Support = 4 × $0.200 × 730 = $584/month. The RI saves $115/month. You are saving $115 while paying $584 unnecessarily. Upgrade to MySQL 8.0 or 8.4 first — the engine upgrade delivers 5× the savings of the RI.
Step 3: Audit Deployment Type Before Purchasing
Single-AZ and Multi-AZ RIs are purchased separately and cover only their matching type. A Single-AZ RI on a Multi-AZ instance saves nothing.
Audit your fleet first:
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,MultiAZ,DBInstanceClass]' \
--output table
While you're here: catch non-production databases incorrectly running Multi-AZ. Dev and staging almost never need HA. Converting them to Single-AZ before reserving saves the Multi-AZ premium on top of the RI discount.
A deeper look at when Multi-AZ is actually worth the cost RDS Multi-AZ vs Single-AZ: the cost of high availability.
Step 4: Buy at the Smallest Normalization Unit for Maximum Flexibility
For engines with size flexibility, purchasing at the smallest instance size you might ever need gives you the most flexible coverage at the same total commitment.
Example: you need 8 normalization units of r8g coverage.
- Option A: 1x db.r8g.xlarge RI
- Option B: 2x db.r8g.large RIs
Both cost the same total. But if you later right-size one xlarge to large, Option B continues covering both large instances with zero waste. Option A leaves excess units and partial on-demand billing.
Caveat: this only applies to engines with size flexibility (MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL). For SQL Server and Oracle LI, purchase exactly the size you are running.
Step 5: Choose the Payment Option That Matches Your Situation
No Upfront: Zero capital today. ~30-33% savings. 1-year only. Best for first-time RI purchases or lower-confidence workloads.
Partial Upfront: Moderate lump sum plus reduced monthly charges. ~35-50% savings. 1-year or 3-year. Best for most production databases.
All Upfront: Full term cost paid at purchase. ~45-69% savings. Best for your most stable, longest-running production databases.
Practical rule: start with 1-year No Upfront on your first RI purchase for any database. Review utilization after 12 months. If the RI was fully utilized and the database is still running in the same configuration, renew at Partial or All Upfront for the deeper discount.
Step 6: Monitor Utilization Monthly and Act on Underuse Early
An RI covering a running database generates savings. An RI whose matching database was deleted or resized generates waste. Monthly monitoring catches this early.
In AWS Cost Explorer: Reservations > Utilization Report, filter for Amazon RDS. A well-managed fleet should show above 90% utilization across the board. Any RI below 80% deserves immediate investigation.
CLI equivalent:
aws ce get-reservation-utilization \
--time-period Start=[start],End=[end] \
--granularity MONTHLY \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}'
When you find an underutilized RI: check if a matching instance exists elsewhere in the account. If not, consider launching a new database with matching attributes to consume the RI until expiry. For Standard RIs (which is all RDS offers), you cannot exchange them for different configurations the RI runs to term.
The Correct Order of Operations
Most teams optimize RI purchasing first and fix expensive underlying problems later. The right sequence:
- Eliminate Extended Support charges first. MySQL 5.7 or PostgreSQL 11 in ES Year 3? Upgrade before reserving.
- Convert non-production Multi-AZ to Single-AZ. Dev and staging don't need HA. Converting 10 instances saves $14,016/year before any RI is purchased.
- Right-size using 30 days of CloudWatch data. Downsize over-provisioned instances before committing.
- Migrate to current Graviton generation (r8g, m8g) if still on r7g or older.
- Purchase RIs on the clean, right-sized fleet. Start with 1-year No Upfront on highest-spend instances.
- Monitor utilization monthly. Catch underused reservations before they run to term.
Usage.ai Flex Reserved Instances executes this entire sequence automatically surfacing Extended Support exposure, identifying non-production Multi-AZ, evaluating utilization before recommending reservations, and purchasing the optimal RI within your approved parameters.
Recommendations refresh every 24 hours versus Cost Explorer's 72-hour cycle. If any reserved instance becomes underutilized, Usage.ai provides cashback in real money.
What's been the biggest source of wasted RI spend in your RDS fleet underutilized reservations, wrong deployment type, or reserving before right-sizing?
Read the full architecture and optimization breakdown here → How to Save on RDS Reserved Instances: A Quick Guide
Top comments (0)