AWS RDS Reserved Instances: Database Cost Optimisation Guide

Why Database Teams Overlook RDS Reserved Instances

Most enterprises approach RDS cost optimisation with a single metric in mind: instance size. But Reserved Instances only cover the compute hourly rate—the third of your RDS bill that's actually predictable. Storage, backups, I/O operations, and data transfer each have separate pricing. This three-bucket cost model means that committing to a 3-year RI on an oversized database can lock in years of waste.

The second issue is architectural churn. A database instance purchased with a 3-year commitment becomes a fixed point in your infrastructure. If that database is migrated to Aurora Serverless in year two, or moved to a different engine entirely, the RI becomes sunk cost. Database teams rarely plan RI strategies around application roadmaps—and procurement teams often don't ask.

Understanding the Three RDS Cost Buckets

Every RDS bill has three distinct components:

• Instance compute hours (RI-eligible): The hourly rate for running the database engine. This covers db.t4g.medium, db.r6g.large, and other instance types.
• Storage costs (NOT RI-eligible): Priced per GB per month, separate from compute. Applies whether you have 100 GB or 1 TB.
• I/O, backups, and data transfer (NOT RI-eligible): Per-request I/O, backup storage, and egress charges accumulate independently.

A critical mistake: buying an RI to "save money on RDS" without addressing storage. A database on undersized gp2 storage might waste more in backup overhead and slow query performance than it saves through the RI discount.

RDS cost optimisation requires a three-part strategy: right-size the compute instance, optimize storage class (gp3 often replaces gp2 at 20-40% lower cost), and negotiate data transfer as part of broader AWS commercial strategy.

RDS Reserved Instance Discount Tiers

AWS offers three payment options for RDS RIs, each with different discount percentages and upfront costs:

Payment Option	Commitment Length	Discount vs On-Demand	Cash Upfront	Best For
All Upfront	1-Year	~50%	Full 12 months	Databases certain to run continuously
All Upfront	3-Year	~69%	Full 36 months	Stable, foundational databases
Partial Upfront	1-Year	~36%	50% of annual cost	Moderate commitment tolerance
Partial Upfront	3-Year	~60%	33% of total cost	Balances cash flow and discount
No Upfront	1-Year	~30-40%	None	Uncertain workloads, testing phases

Key Points on Discount Structure

The 69% maximum discount (3-year All Upfront) compresses down to ~30% for 1-year No Upfront. This reflects both the commitment length and the time value of money paid upfront. If your database will run less than 12 months continuously, RIs are financially indefensible—you'll pay full price for months of zero utilisation.

Partial Upfront options are popular in large enterprises because they spread cash impact while retaining most of the discount. A 3-year Partial Upfront RI on a db.r6g.xlarge costs roughly one-third of the total RI price upfront, then hourly payments cover the remainder. This works well for databases you're confident about but prefer to budget across 36 months rather than pay a lump sum.

Instance Size Flexibility: The Underutilized Advantage

One of the most powerful—and rarely used—features of RDS RIs is instance size flexibility. An RI purchased for a specific database engine family can apply to different instance sizes within that family. This applies to:

• Aurora (MySQL or PostgreSQL-compatible)
• MySQL
• MariaDB
• PostgreSQL
• Db2 (BYOL Oracle)

For example, an RI for Aurora PostgreSQL db.r6g.xlarge (4 vCPU) can cover a db.r6g.2xlarge (8 vCPU) if your workload needs to scale during peak periods, or it can split coverage across two db.r6g.large instances (2 vCPU each) if you've deployed read replicas.

This flexibility only works within the same engine family and Availability Zone(s). You cannot use an Aurora MySQL RI against a PostgreSQL instance, and regional RIs (which do exist) have different rules. Enterprise database teams should always confirm instance family rules with AWS before purchasing.

What RDS Reserved Instances Do NOT Cover

This cannot be emphasised enough: RIs only cover the compute instance hourly rate. Everything else is extra:

• Storage: gp2 and gp3 SSD volumes, magnetic storage all cost separately per GB/month.
• Backups: Automated backup storage exceeding your retention window; manual snapshots.
• I/O: Per-request I/O charges (especially high for io1/io2 provisioned IOPS).
• Data Transfer: Egress from RDS to the internet, cross-region replication, or third-party services.
• Enhanced Monitoring: CloudWatch metrics at sub-1-minute granularity.
• RDS Proxy: Connection pooling layer adds hourly charges per vCPU provisioned.

A case study: an enterprise purchases a 3-year RI for a large db.r6g.2xlarge PostgreSQL instance, saving 69% on compute. But they never address io1 provisioned IOPS (100 IOPS provisioned at roughly $0.10 per IOPS-month), which costs more than the compute instance on-demand price. The RI discount masks the real waste in I/O configuration.

Multi-AZ Deployments and the Hidden RI Cost

RDS Multi-AZ deployments run a secondary replica in a different Availability Zone for failover. From an RI perspective, each AZ counts as a separate instance. A Multi-AZ db.r6g.xlarge is billed as two instances (primary + standby). This means the RI discount applies to both.

But here's the commercial trap: if you buy an RI for a Single-AZ instance and later convert to Multi-AZ (for resilience or compliance), you're now running two instances with only one RI covering part of the cost. The second instance runs at on-demand rates—50-69% more expensive.

Enterprise procurement should clarify Multi-AZ architecture decisions upfront. If your database is already Multi-AZ and stable, an RI makes sense for both instances. If you're planning to add Multi-AZ in year two, either buy RI coverage for both now, or delay the RI purchase until architecture is fixed.

Deployment Scenario	Instances Running	RI Discount Coverage	Cost Implication
Single-AZ, no RI	1	None	On-demand rate for 1 instance
Single-AZ with 1-instance RI	1	100% of running instance	50-69% savings
Multi-AZ (primary + standby), 1-instance RI	2	50% of running instances	Partial savings; 1 instance still on-demand
Multi-AZ (primary + standby), 2-instance RI	2	100% of running instances	50-69% savings across both

Aurora Serverless v2: A Different RI Strategy

Traditional RDS instances (MySQL, PostgreSQL, MariaDB) and provisioned Aurora clusters have straightforward RI models. But Aurora Serverless v2 uses a different pricing model entirely: you're not buying instance hours; you're buying ACU-hours (Aurora Capacity Units).

ACU pricing is per-second, autoscaling based on actual usage. An RI on a db.r6g.2xlarge Traditional Aurora does not apply to Aurora Serverless v2. If your team is planning a migration from Traditional RDS to Serverless, RIs become a stranded cost after migration.

Database teams considering Serverless should delay RI commitments until after the migration is complete and you understand Serverless v2 ACU consumption patterns. Serverless v2 may actually be cheaper for variable workloads even without RIs, negating the discount advantage entirely.

Right-Sizing: The Foundation of Smart RI Decisions

The single biggest mistake in RDS RI procurement is buying commitments for over-provisioned instances. A database running at 20-30% CPU utilisation locked into a 3-year RI is committing to three years of waste.

Before buying any RI:

• Collect 6+ months of CloudWatch metrics: CPU, memory, I/O utilisation at peak and average. Weekly and monthly patterns matter.
• Review query performance logs: Are slow queries driving high I/O despite low CPU?
• Check connection count: Is the instance oversized because it's over-indexed on connection handling rather than compute?
• Validate storage design: Is backup overhead inflating perceived storage needs?
• Confirm application roadmap: Will this database exist in three years? Is migration planned?

If a database is running consistently at 40-60% CPU utilisation and that utilisation is stable month-to-month, it's a good RI candidate. If utilisation swings from 10% to 80% based on batch jobs, it's borderline—a Partial Upfront or 1-year RI limits risk.

Step-by-Step RDS RI Procurement Process

Step 1: Inventory and Classify Databases

List all RDS instances across your AWS accounts. For each, determine:

• Engine type (Aurora, PostgreSQL, MySQL, etc.)
• Instance size and class (e.g., db.r6g.xlarge)
• Deployment mode (Single-AZ or Multi-AZ)
• Availability Zone(s) and region
• Current utilisation (CPU, memory, I/O)
• Lifecycle status (production, staging, dev/test)

Typically, development and test instances are poor RI candidates. Production instances with stable utilisation are ideal. Staging instances depend on whether they mirror production traffic.

Step 2: Validate Right-Sizing

For each production database, run a right-sizing assessment. AWS Compute Optimizer provides automated recommendations, but enterprise teams should validate:

• Is the instance consistently under-utilised? Consider downsizing.
• Is the instance hitting resource ceilings? Consider upsizing.
• Can you split read-heavy workloads onto read replicas with smaller instance sizes?
• Is storage configuration (gp2 vs gp3) aligned with performance needs?

Step 3: Define Commitment Duration

For each database, decide: 1-year or 3-year RI? This depends on:

• Strategic certainty: Is this database core to your business in three years?
• Architectural stability: Is the instance type, size, and region fixed?
• Financial risk tolerance: Can you absorb the upfront cost?

A conservative approach: 1-year RIs for databases on planned migration paths; 3-year RIs for foundational, non-negotiable infrastructure.

Step 4: Select Payment Option (All vs Partial vs No Upfront)

If you're committing to 3 years:

• All Upfront (69% discount): Pay everything now, maximum discount. Best if you have capital budget headroom.
• Partial Upfront (60% discount): Pay roughly one-third of the total RI price upfront, remainder as monthly charges. Spreads cash impact.
• No Upfront (30-40% discount): No cash outlay, pay monthly. Flexibility, lower discount.

Large enterprises often favour Partial Upfront because it amortises cost across the budget cycle and retains most of the discount advantage.

Step 5: Purchase and Monitor

After committing, monitor actual utilisation against the purchased capacity. If a database's usage drops significantly after the RI purchase, you have limited options: continue paying the discounted rate for unused capacity, or purchase Savings Plans to cover newer, smaller instances (within limits).

Integration with Broader AWS Cost Strategy

RDS RIs should not be purchased in isolation. They're one lever in a larger AWS cost optimisation toolkit that includes:

• AWS RI and Savings Plan optimisation across compute, storage, and database layers.
• AWS EDP negotiation strategy if you're spending $100K+ annually on AWS—RIs can be factored into overall EDP discount thresholds.
• AWS data transfer and egress negotiation to reduce per-GB costs that RIs don't cover.
• AWS Support plan negotiation to ensure your architect understands your RI strategy and can advise on architecture changes that affect RI utilisation.

If you're running a large, multi-vendor environment (AWS + Google Cloud + Azure), consider AWS Marketplace procurement strategy alongside RIs—ISV licenses on Marketplace can be offset against EDP commitments.

To understand how RDS cost optimisation fits into your broader AWS commercial strategy, download the AWS EDP negotiation playbook — it covers how database spend is factored into EDP commit negotiations.

The Pillar Comparison: RIs vs Savings Plans

Many enterprises ask: should we buy RDS RIs or Savings Plans? The answer depends on your flexibility. Read the full AWS Reserved Instances vs Savings Plans complete guide for a detailed comparison. In brief:

• RIs: Database-specific, instance-size-specific. Higher discount. Lower flexibility.
• Savings Plans: Compute-wide, instance-size-flexible. Lower discount (typically ~30% for 3-year). High flexibility.

For stable, single-database workloads, RIs win. For heterogeneous environments where instance sizes change quarterly, Savings Plans are safer.

Common Mistakes and How to Avoid Them

Mistake 1: Buying RIs for Databases Planned for Migration

A team commits to a 3-year RI for a legacy MySQL database, then begins a project to migrate to Aurora Serverless. The RI becomes dead weight. Solution: Align database lifecycle decisions with procurement. If migration is in the roadmap, delay the RI or buy only 1-year terms.

Mistake 2: Over-Provisioning to "Fill" the RI

A team buys a large RI, then decides to increase instance size to "use" the discount. This inverts right-sizing logic and often increases total cost. Solution: Right-size first, buy RI second. Not the reverse.

Mistake 3: Ignoring Storage Cost Optimization

A team saves 30% on compute via RI but continues running io1 provisioned IOPS at high settings, spending more on I/O than on the compute instance itself. Solution: Treat RI procurement as a moment to audit the entire cost stack: compute, storage, I/O, backup, transfer.

Mistake 4: Not Accounting for Multi-AZ Expansion

A Single-AZ RI is purchased; later, Multi-AZ is enabled for compliance reasons. Now only half the running instances are covered by the RI. Solution: Determine Multi-AZ strategy upfront. Buy RI coverage for both instances if Multi-AZ is planned.

Mistake 5: Buying RIs Without Vendor Strategy Alignment

A team independently purchases RDS RIs without considering whether it impacts EDP discount negotiations or AWS Marketplace strategy. RIs are technically cheaper, but they may reduce flexibility to negotiate larger discounts later. Solution: RDS RI procurement should flow through commercial/procurement, not just engineering.

Aligning with Enterprise Commercial Strategy

For enterprises with annual AWS spend above $500K-$1M, RDS RIs are part of a larger cost negotiation. AWS Enterprise Discount Plans (EDPs) tier discounts based on commitment levels. Buying RIs upfront counts toward that commitment, potentially unlocking additional percentage-point discounts across your entire AWS bill.

However, if you're mid-negotiation with AWS on discount levels, committing to RIs too early can lock you into less favourable overall terms. Work with your AWS account team to sequence EDP negotiations and RI procurement. Often, the optimal path is: negotiate EDP terms first, then buy RIs as part of the commitment fulfilment strategy.

For ISV procurement and multi-vendor licensing, review AWS Marketplace procurement strategy to ensure RDS (and other committed purchases) don't inadvertently reduce your leverage in broader negotiations.

Conclusion: When RDS RIs Make Commercial Sense

AWS RDS Reserved Instances deliver genuine savings—up to 69%—on database compute costs. But that discount only applies to one-third of your RDS bill. The other two-thirds (storage, I/O, backups, egress) remain on-demand pricing unless you address them separately.

Purchase RDS RIs when:

• Databases are right-sized and utilisation is stable (40%+ CPU, consistent month-to-month).
• The instance is core infrastructure with multi-year viability in your roadmap.
• Multi-AZ strategy is finalized (and you buy RI coverage for both instances if applicable).
• You have 6+ months of utilisation data confirming the instance size is appropriate.
• Procurement aligns with broader AWS commercial strategy (EDP negotiations, Marketplace strategy).

Avoid RDS RIs when:

• Database is over-provisioned or utilisation is volatile and unpredictable.
• Migration to Aurora Serverless or a different engine is planned within 18-24 months.
• You're early in a migration project and database footprint may shift significantly.
• Database is non-production (dev, test, staging) and can be shut down for cost control.

The most important step is right-sizing before you commit. An oversized database locked into a 3-year RI is cheaper than on-demand, but still expensive. The best RI is one you don't need to buy because the instance is perfectly sized to begin with.

For enterprise teams managing hundreds of RDS instances across multiple regions and accounts, procurement should be systematic: inventory, classify by lifecycle, right-size, then commit. Seat-of-the-pants RI purchases based on individual engineering decisions often result in suboptimal outcomes.

Need help auditing your RDS instances and developing a systematic RI strategy? Talk to our AWS database cost optimisation advisors about a tailored assessment and procurement plan.