AWS Database Savings Plans: Complete Guide (2026)

AWS database costs can spiral quickly, especially when you're running Aurora, DynamoDB, or RDS across multiple environments. Until December 2025, your only discount options were Reserved Instances, which lock you to specific configurations, or nothing at all for serverless offerings like Aurora Serverless v2 and DynamoDB on-demand.

Database Savings Plans change this equation entirely. For the first time, you can get discounts on DynamoDB on-demand throughput, Aurora Serverless, and other previously non-discountable database services.

Here's what makes this guide different: I provide a decision framework for choosing between Database Savings Plans and Reserved Instances, something no other resource offers. You'll know exactly when each option makes sense for your workloads.

By the end, you'll understand how Database Savings Plans work, which services qualify, how the discount structure varies by deployment type, and have a clear framework for deciding between Database Savings Plans and Reserved Instances. Let's start with the fundamentals.

What Are AWS Database Savings Plans?

Database Savings Plans are a flexible pricing model introduced by AWS in December 2025 at re:Invent. They reduce database costs by up to 35% when you commit to a consistent amount of usage (measured in $/hour) over a 1-year term.

Unlike Reserved Instances that require commitment to specific instance types, regions, and configurations, Database Savings Plans automatically apply to eligible usage regardless of:

• Database engine
• Instance family
• Instance size
• Deployment option (provisioned vs serverless)
• AWS Region
• Availability Zone

The key difference from RIs is the commitment type. With Database Savings Plans, you're committing to a dollar amount per hour across your entire database portfolio. With Reserved Instances, you're committing to specific instance configurations. This distinction gives Database Savings Plans significant flexibility advantages, especially if you're modernizing your database architecture.

How the Hourly Commitment Model Works

The hourly commitment model is central to how Database Savings Plans operate. You commit to spending a specific dollar amount per hour for your 1-year term.

Commitment limits:

• Minimum: $0.001/hour
• Maximum: $5,000/hour

Each hour, your commitment automatically applies to eligible database usage across all supported services. Any usage beyond your commitment gets billed at on-demand rates.

Critical concept: Each hour's commitment is independent. Unused commitment in any hour does NOT carry over to future hours. This is a "use it or lose it" model on an hourly basis, just like other Savings Plans types.

Here's a practical example with a $10/hour commitment:

• Hour 1: You have $8 of eligible usage. You pay $8 at the Savings Plans rate. The remaining $2 of commitment is unused and lost.
• Hour 2: You have $12 of eligible usage. You pay $10 at the Savings Plans rate. The remaining $2 is charged at on-demand rates.

This hourly independence means you should size your commitment based on your baseline usage, not your peak.

Key Flexibility Benefits

Database Savings Plans provide four flexibility dimensions that Reserved Instances simply can't match:

1. Cross-region flexibility: Move workloads between AWS regions without losing your discount
2. Cross-engine flexibility: Switch database engines (e.g., RDS MySQL to Aurora PostgreSQL) while maintaining savings
3. Cross-instance flexibility: Change instance families and sizes freely
4. Cross-service flexibility: Move between covered services (RDS, Aurora, DynamoDB, ElastiCache, etc.)

This flexibility is particularly valuable if you're modernizing from one database engine to another, adopting serverless databases, or have unpredictable growth patterns across regions.

Now that you understand how Database Savings Plans work, let's look at which AWS database services are covered.

Database Services Covered by Savings Plans

Database Savings Plans cover nine AWS database services, but eligibility varies by service and deployment type. Understanding these nuances is critical before purchasing.

The services covered include both relational and NoSQL databases, plus specialized services like ElastiCache and Neptune. However, several important restrictions apply that competitors often gloss over.

Eligible Services and Usage Types

Here's the complete breakdown of eligible services and their coverage:

Database Savings Plans are available in all AWS regions except China Regions. As new eligible database offerings, instance types, or Regions become available, Savings Plans automatically apply to that usage.

Use our Aurora pricing calculator to estimate Aurora costs that Database Savings Plans would discount.

Important Eligibility Restrictions

Several restrictions can catch you off guard if you're not careful:

Generation 7+ instances only: Database Savings Plans only cover newer instance generations. Older generations like db.r5, db.r6g, or db.m5 are NOT covered. If you're running older instances, you'll need to upgrade before Database Savings Plans benefits apply.

ElastiCache restriction: Only Valkey instances are eligible. Redis and Memcached are NOT covered by Database Savings Plans. This is a significant limitation if your caching layer uses Redis or Memcached.

Timestream restriction: Only InfluxDB instances are eligible. Standard Timestream usage is not covered.

What's NOT covered (across all services):

• Storage charges
• Backup charges
• I/O charges
• Data transfer charges

These restrictions mean you should audit your current database fleet before purchasing. Use our ElastiCache pricing calculator to understand Valkey pricing and how Savings Plans apply.

Understanding which services qualify, let's examine the actual discount rates you can expect.

Database Savings Plans Discount Structure

Database Savings Plans discounts vary significantly by deployment type. Serverless deployments get the highest discounts, while provisioned capacity for DynamoDB and Keyspaces gets the lowest. Understanding this structure helps you estimate actual savings for your specific workloads.

The maximum discount of 35% only applies to serverless deployments. If you're running provisioned instances, expect closer to 20%.

Discount Rates by Deployment Type

Here's how discounts break down by deployment model:

Specific service discounts:

• ElastiCache Serverless for Valkey: 30% discount
• ElastiCache for Valkey instances: 20% discount

The higher discounts for serverless deployments make Database Savings Plans particularly attractive if you're using Aurora Serverless v2 or DynamoDB on-demand. This is the first time these services have had any discount option available.

Use our DynamoDB pricing calculator to model on-demand vs provisioned costs and understand how Database Savings Plans affect each.

How Database Savings Plans Compare to Other Savings Plans Types

AWS offers four types of Savings Plans. Here's how Database Savings Plans compare:

Key differences to understand:

1. Term length: Database Savings Plans are limited to 1-year terms, while other Savings Plans offer both 1-year and 3-year options
2. Payment options: Database Savings Plans only offer No Upfront payment. If you want upfront payment for additional savings, you'll need to use the separate Advance Pay billing feature
3. Lower maximum discount: At 35% maximum, Database Savings Plans offer lower discounts than Compute (66%) or EC2 Instance (72%) Savings Plans
4. Broader flexibility: Like Compute Savings Plans, Database Savings Plans apply across regions, instance families, and sizes

For a complete overview of all Savings Plans types, see the AWS Savings Plans guide. If you're also running EC2 workloads, the Compute vs EC2 Savings Plans comparison helps you choose between those options. For ML-specific workloads on SageMaker, see the SageMaker AI Savings Plans guide.

While Database Savings Plans offer up to 35% savings, Reserved Instances can offer up to 77%. Let's compare these options to help you decide which makes sense for your workloads.

Database Savings Plans vs Reserved Instances

The Database Savings Plans vs Reserved Instances decision is the most important choice you'll make for database cost optimization. Reserved Instances offer higher discounts but lock you to specific configurations. Database Savings Plans offer more flexibility but lower savings.

Understanding this tradeoff helps you make the right choice for each workload. In many cases, a hybrid approach using both options delivers the best results.

Reserved Instance Discount Comparison

Reserved Instances still offer significantly higher discounts than Database Savings Plans:

RDS Reserved Instances:

DynamoDB Reserved Capacity:

Database Savings Plans: 12-35% depending on deployment type

The discount gap is substantial for stable workloads. A 3-year All Upfront RDS Reserved Instance offers 63% savings compared to 20% from Database Savings Plans for provisioned instances. For DynamoDB, the gap is even larger: 77% vs 18%.

Use our RDS pricing calculator to compare RDS RI costs against Database Savings Plans for your specific configuration.

Flexibility vs Discount Tradeoff

The core tradeoff is flexibility vs maximum discount:

The flexibility premium costs 10-40+ percentage points in discount. Whether that tradeoff makes sense depends entirely on your workload characteristics.

Decision Framework: When to Choose Each

This decision framework helps you choose the right option for each workload. No other resource provides this level of actionable guidance.

Choose Database Savings Plans if you:

• Use serverless databases (Aurora Serverless v2, DynamoDB on-demand)
• Want flexibility to move between services and instance types
• Plan to adopt new technologies without managing separate commitments
• Need simplified cost management across database services
• Are modernizing from one engine to another (e.g., RDS Oracle to Aurora PostgreSQL)
• Have a mix of provisioned and serverless deployments
• Have unpredictable growth patterns across regions
• Are running Gen 7+ instances

Choose Reserved Instances if you:

• Have stable, predictable workloads on specific instance types
• Want to maximize savings through longer 3-year commitments
• Are running older instance generations (pre-Gen 7)
• Need the highest possible discount and won't change configurations
• Use Redis or Memcached on ElastiCache (not covered by Database Savings Plans)

Hybrid approach: Many organizations use both. Reserved Instances for stable production workloads where maximum discount matters, and Database Savings Plans for newer, more flexible workloads or serverless services.

Migration Strategy for Existing RI Customers

If you have existing Reserved Instances, here's how to transition to Database Savings Plans:

1. Don't break existing RI commitments: Let them run their term. There's no benefit to early termination.
2. Purchase Database Savings Plans for NEW usage immediately: Cover new workloads not currently covered by RIs
3. Transition as RIs expire over 1-3 years: Replace expiring RIs with Database Savings Plans where flexibility matters
4. Track RI expiration dates: Use Cost Explorer to plan your transition timeline

Important: Database Savings Plans discounts cannot be combined with Reserved Instances on the same workload. However, you can purchase RIs for one workload and Database Savings Plans for another. AWS applies RIs first, then Savings Plans cover remaining eligible usage.

Once you've decided Database Savings Plans are right for your workloads, understanding the commitment terms is essential.

Commitment Terms and Payment Options

Database Savings Plans have more restrictions on terms and payment options than other Savings Plans types. Understanding these constraints helps you plan your commitment strategy effectively.

The key limitations are the 1-year term only and No Upfront payment only. These restrictions reduce flexibility compared to other Savings Plans types but simplify the decision-making process.

1-Year Term Limitations

Database Savings Plans are currently available with a 1-year term only. This differs from Compute, EC2 Instance, and SageMaker Savings Plans, which offer both 1-year and 3-year options.

Implications:

• Lower maximum discount compared to what 3-year terms would offer
• More frequent renewal decisions (annually vs every 3 years)
• More flexibility to adjust commitment levels each year
• AWS may add 3-year terms in the future, but no announcements have been made

The 1-year limitation is actually an advantage if you're uncertain about future database usage. Shorter commitment means less risk if your architecture changes significantly.

No Upfront Payment Only

Database Savings Plans only offer the No Upfront payment option:

• No upfront payment required
• Commitment charged monthly
• Full commitment billed regardless of actual usage

This differs from other Savings Plans types and Reserved Instances, which offer All Upfront, Partial Upfront, and No Upfront options with increasing discounts for more upfront payment.

Alternative for upfront payment: If you prefer to prepay, AWS offers the Advance Pay feature in the Billing and Cost Management console. This is a separate billing feature that allows prepayment for AWS usage, which can be combined with Database Savings Plans.

Return and Cancellation Policy

AWS provides a limited return window for Savings Plans purchased in error:

Eligibility requirements:

• Purchased within the last 7 days
• Purchased in the same calendar month
• Hourly commitment is $100 or less

What happens when you return:

• 100% refund for any upfront charges (though Database Savings Plans are No Upfront only)
• Refunds reflected in bill within 24 hours
• Usage previously covered by the returned plan is charged at on-demand rates

Important limitations:

• Cannot cancel Savings Plans outside the 7-day/same-month window
• Cannot modify commitment terms after purchase
• Commitment continues for the full 1-year term regardless of usage

This return policy provides a safety net for smaller purchases but doesn't help with large commitments. Always use the Purchase Analyzer before committing to amounts over $100/hour.

With the terms understood, let's walk through how to actually purchase Database Savings Plans.

How to Purchase Database Savings Plans

AWS provides multiple tools to help you make informed purchase decisions. The process is straightforward, but using the right evaluation tools before purchasing can prevent costly mistakes.

Three purchase methods are available: AWS Console (recommended for most users), AWS CLI for programmatic purchases, and AWS Cost Explorer API for automation. Let's walk through the evaluation and purchase process.

Using Savings Plans Recommendations

AWS automatically generates recommendations based on your historical on-demand usage:

1. Navigate to Billing and Cost Management Console
2. Go to Savings Plans > Recommendations
3. Select Database Savings Plans
4. Configure your lookback period (7, 30, or 60 days)
5. Review the recommended hourly commitment for maximum savings

The recommendations analyze historical on-demand usage to identify the hourly commitment that delivers the highest overall savings. They include estimated monthly savings, coverage, and utilization metrics.

Limitations to be aware of:

• Recommendations don't account for planned changes or migrations
• They don't consider seasonal variations unless you use an appropriate lookback period
• Payer account recommendations optimize for organization-wide savings, not individual accounts

Use AWS recommendations as a starting point, not a final decision. Validate with your knowledge of upcoming workload changes.

Using the Purchase Analyzer

For custom modeling beyond recommendations, the Savings Plans Purchase Analyzer lets you model purchase scenarios before committing:

1. Navigate to Billing and Cost Management Console
2. Go to Savings Plans > Purchase Analyzer
3. Select Database Savings Plans
4. Configure your lookback period
5. Enter custom hourly commitment amounts
6. View projected Cost, Coverage, and Utilization impact

Use Purchase Analyzer when:

• Your purchasing strategy includes smaller, incremental commitments over time
• You expect future usage changes that could affect the ideal purchase amount
• You want to validate financial goals or purchasing strategies

The Purchase Analyzer shows three output charts:

• Cost Chart: On-demand cost vs estimated cost with Savings Plan
• Coverage Chart: Percentage of eligible usage covered over time
• Utilization Chart: How much of your commitment is being used

Step-by-Step Purchase Process

1. Review recommendations or run Purchase Analyzer simulations
2. Choose "Add to cart" for your selected commitment
3. Review order details on the Cart page
4. Submit order
5. Confirm in the Inventory view

Savings appear in your bill within 8 hours of purchase.

Before clicking 'purchase,' it's critical to size your commitment correctly.

Sizing Your Database Savings Plans Commitment

This is where most organizations make costly mistakes. Over-committing wastes money on unused commitment every hour. Under-committing leaves savings on the table but is the safer error.

The key principle is to commit to baseline usage, not peak. You can always add more Savings Plans later, but you cannot reduce an existing commitment.

Analyzing Your Database Spend

Before purchasing, analyze your current database spend:

1. Use Cost Explorer to identify consistent hourly database spend
2. Filter by database services to see only eligible usage
3. Look for baseline vs peak patterns in your usage
4. Identify seasonality or trends that affect your typical spend

Focus on your minimum consistent spend, not your average (which includes peaks). The goal is finding the floor of your usage.

Choosing the Right Lookback Period

The lookback period determines how much historical data informs your recommendation:

Considerations:

• Exclude atypical days (maintenance windows, unusual traffic spikes) from your analysis
• If recent usage differs significantly from historical patterns, use shorter lookback
• If you have seasonal patterns, consider whether your selected period is representative

Targeting Optimal Utilization (80-90%)

The sweet spot for Savings Plans utilization is 80-90%:

• Why not 100%: Leaves buffer for hourly variability
• Under 80%: You're likely over-committed and wasting money
• 80-90%: Optimal balance between savings and risk
• Review quarterly: Adjust your strategy based on actual utilization

Sizing strategy:

1. Start with 70-80% of your consistent baseline usage
2. Add smaller commitments incrementally as patterns become clearer
3. Target 80-90%+ utilization to maximize value without overcommitting

This conservative approach ensures you're not paying for unused commitment while still capturing meaningful savings.

Once you've purchased, ongoing monitoring ensures you're getting the savings you expect.

Monitoring Savings Plans Utilization and Coverage

Purchasing Savings Plans is just the beginning. Ongoing monitoring ensures you're getting expected value and helps you plan for renewals and additional purchases.

Two key metrics matter: Utilization (are you wasting commitment?) and Coverage (how much usage is discounted?). Understanding the difference is crucial for optimization.

Utilization Report

The Utilization report shows whether you're using what you're paying for:

Access: Billing and Cost Management Console > Savings Plans > Inventory > Select Plan > View utilization report

Key metrics:

• Savings Plans Spend: Commitment spend over the lookback period
• On-Demand Spend Equivalent: Amount that would have been spent without Savings Plans
• Total Net Savings: Difference between commitment savings and on-demand cost estimate

Target: 80%+ utilization. If utilization is consistently below 80%, you've over-committed and should reduce your commitment at renewal time.

Coverage Report

The Coverage report shows what percentage of eligible usage is covered by Savings Plans:

Key metrics:

• On-Demand Spend Not Covered: Eligible spend still on on-demand pricing
• Average Coverage: Percentage of eligible usage covered
• Potential Monthly Savings: Additional savings opportunity

Coverage below 70% indicates opportunity for additional Savings Plans purchases. However, always balance coverage goals with utilization, as you don't want to over-commit chasing 100% coverage.

Setting Up Budgets and Alerts

Proactive monitoring catches issues before they appear on your monthly bill:

Utilization threshold alerts:

• Create a budget that alerts when utilization drops below 80%
• Configure daily, monthly, or quarterly budget periods
• Receive email or SNS notifications

Coverage threshold alerts:

• Alert when coverage falls below your target percentage
• Identifies opportunities for additional purchases

Configuration: Billing and Cost Management Console > Budgets > Create budget > Savings Plans budget

Set up these alerts immediately after purchase. Don't wait until you're reviewing monthly bills to discover utilization problems.

Multi-Account Organizations

In AWS Organizations, Savings Plans sharing works as follows:

• Default behavior: Benefits apply across all accounts in the Organization
• Option: Restrict benefits to only the purchasing account
• Management account: Sees aggregated utilization for entire Consolidated Billing family
• Cost Categories: Can be used to group accounts and purchase Savings Plans at group level

For organizations managing multiple AWS accounts, see the multi-account strategy guide for detailed guidance on structuring your approach.

Purchasing approaches:

• Centralized: Management account purchases based on organization-wide recommendations (maximizes savings)
• Decentralized: Each business unit purchases for their accounts (maintains budget accountability)
• Hybrid: Central purchases for shared workloads, teams purchase for team-specific usage

For most organizations, centralized purchasing with organization-wide sharing delivers the best overall savings.

With monitoring in place, let's review best practices to maximize your Database Savings Plans value.

Database Savings Plans Best Practices

Following these best practices helps you avoid common mistakes and maximize the value from your Database Savings Plans commitment. I've compiled these from AWS documentation, prescriptive guidance, and practical experience.

Before You Purchase

Complete this checklist before making any commitment:

1. Remove idle resources: Use AWS Trusted Advisor to identify and eliminate unused databases
2. Right-size instances: Use AWS Compute Optimizer recommendations for RDS/Aurora before committing
3. Upgrade to Gen 7+ if needed: Database Savings Plans only cover Gen 7+ instances, so plan upgrades before purchasing
4. Analyze usage patterns: Ensure historical usage represents expected future usage
5. Review service restrictions: Verify your ElastiCache engine is Valkey and Timestream type is InfluxDB

For broader cost optimization context, see the cost optimization best practices and cost optimization checklist.

Commitment Strategy

A disciplined approach to commitment sizing prevents costly mistakes:

1. Start conservative: Begin with a commitment covering 70-80% of your consistent baseline spend
2. Use incremental purchases: Add smaller commitments over time as usage patterns become clearer
3. Target high utilization: Aim for 80-90%+ utilization to maximize value without overcommitting
4. Review quarterly: Establish a regular cadence to review utilization and adjust strategy

Organizational approaches:

• Centralized: Purchase based on payer account recommendations for maximum savings and simplified management
• Decentralized: Allow each business unit to make purchasing decisions for budget accountability
• Hybrid: Combine both based on organizational needs

Common Mistakes to Avoid

These mistakes are predictable and preventable:

1. Over-committing based on peak usage

• Impact: Low utilization, paying for unused commitment every hour
• Solution: Target 70-80% of consistent baseline usage; let peaks remain on-demand

2. Ignoring instance generation requirements

• Impact: No discount applied to older generation (db.r5, db.r6g) usage
• Solution: Plan instance generation upgrades before or alongside Savings Plans purchase

3. Expecting Reserved Instance-level discounts

• Impact: Disappointment when provisioned instance discount is only 20%, not 35%
• Solution: Understand discount tiers: Serverless (35%), Provisioned (20%), DynamoDB throughput (12-18%)

4. Combining with Reserved Instances on same workload

• Impact: No benefit since RI discounts and Savings Plans cannot stack
• Solution: Use Database Savings Plans for new workloads or wait for RI expiration

5. Not accounting for migration plans

• Impact: Stranded commitment with low utilization
• Solution: Factor in known changes; use shorter lookback periods if major changes are planned

6. Forgetting about ElastiCache and Timestream restrictions

• Impact: No discount on Redis, Memcached, or non-InfluxDB Timestream
• Solution: Verify your ElastiCache engine (must be Valkey) and Timestream type (must be InfluxDB)

7. Using outdated lookback data

• Impact: Commitment doesn't match current needs
• Solution: Select a lookback period that best represents expected future usage

8. Not setting up monitoring

• Impact: Not aware of under-utilization until reviewing monthly bills
• Solution: Set up Savings Plans budgets with utilization thresholds immediately after purchase

Key Takeaways

Database Savings Plans represent a significant shift in how you can optimize AWS database costs. Here's what to remember:

1. Up to 35% savings with unprecedented flexibility across 9 database services, including the first-ever discounts for DynamoDB on-demand and Aurora Serverless v2
2. They complement, don't replace, Reserved Instances: Use the decision framework to choose the right option for each workload
3. Start conservative: Commit to 70-80% of consistent baseline, use incremental purchases, and monitor utilization
4. Understand the restrictions: Gen 7+ instances only, Valkey only for ElastiCache, InfluxDB only for Timestream
5. Transition from RIs gradually: Let existing commitments expire, purchase Database Savings Plans for new usage immediately

Your next step is to review your database usage in AWS Cost Explorer and run a Purchase Analyzer simulation for your highest-spend database workloads. Understand your baseline before committing.

For a complete overview of all four AWS Savings Plans types (Compute, EC2 Instance, Database, and SageMaker), see the complete guide to AWS Savings Plans.

What's your biggest challenge with AWS database costs? Drop a comment below and I'll help you work through it.

Frequently Asked Questions