AWS expanded its Savings Plans portfolio with Database Savings Plans, a spend-based discount model for managed database services that can cut costs by up to 35%. This is the first time the Savings Plans model has extended beyond compute, and it changes how DB teams can commit to long-term database spend.

Usage.ai added native support for Database Savings Plans in January 2026.

What Are AWS Database Savings Plans?

Instead of committing to a specific instance class, engine, or Region (like Reserved Instances require), you commit to a consistent hourly spend amount for a one-year term. AWS automatically applies discounts across all eligible usage up to that committed amount, every hour, without manual action.

The model mirrors how Compute Savings Plans work but applied to the database layer for the first time. It covers both provisioned and serverless database usage.

How the commitment works

• Commit to a dollar amount per hour for 1 year
• AWS applies discounts to eligible usage each hour, prioritizing where it delivers the most value
• Usage beyond the committed amount is charged at standard on-demand rates
• A single plan can cover an RDS instance in one Region and an Aurora instance in another no separate RIs needed

Payment options

Database Savings Plans are No Upfront only billed as monthly charges over the 1-year term. There's no All Upfront or Partial Upfront option, which is a structural difference from Compute and EC2 Instance Savings Plans. AWS offers a separate "Advance Pay" billing feature for pre-payment of monthly charges, but this isn't a payment option on the Savings Plan itself.

Which AWS Services Are Covered?

Database Savings Plans apply across these managed database services:

• Amazon Aurora: Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families), Aurora Serverless v2, Aurora DSQL
• Amazon RDS: Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families)
• Amazon DynamoDB: On-demand throughput (up to 18% savings); provisioned capacity (up to 12% savings)
• Amazon ElastiCache: Valkey engine only (Gen 7+ provisioned and Serverless). Standard Redis and Memcached still require Reserved Nodes.
• Amazon DocumentDB: Gen 7+ provisioned instances and DocumentDB Serverless
• Amazon Neptune: Gen 7+ provisioned instances and Neptune Serverless
• Amazon Neptune Analytics: Added March 2026
• Amazon Keyspaces: On-demand and provisioned throughput
• Amazon Timestream: InfluxDB instances (LiveAnalytics not covered)
• Amazon OpenSearch: Serverless and Gen 7+ provisioned instances (expanded March 2026)
• AWS DMS: Gen 7+ replication instances and DMS Serverless

Older instance families (db.m5, db.r5, db.r6g, etc.) are not eligible and still require Reserved Instances.

If you want to understand how these two commitment types compare across every relevant factor, we covered the full decision framework here AWS Savings Plans vs Reserved Instance

How Database Savings Plans Differ From Reserved Instances

Reserved Instances require you to specify at purchase the exact instance class, database engine, deployment type, and AWS Region. All four must match the running workload for the discount to apply. Change any one of them and the RI no longer applies.

Modern database environments regularly resize, upgrade instance generations, migrate engines, or shift from Single-AZ to Multi-AZ. Each is a routine decision, but each can strand an RI and create unexpected cost exposure.

Database Savings Plans decouple the discount from configuration. Committed spend follows actual usage rather than a specific setup that may change.

A few key structural differences:

• Flexibility: RIs break on config changes; Savings Plans follow spend through routine changes
• Max discount: RIs offer up to 40%+ for 3-year All Upfront; Database Savings Plans offer up to 35% (serverless) or up to 20% (provisioned Gen 7+)
• Term: RIs support 1-year or 3-year; Database Savings Plans are 1-year only
• Billing order: RIs are applied first each billing hour; Savings Plans apply second, to remaining eligible usage
• Coverage automation: RIs must match configuration exactly; Savings Plans apply automatically across eligible spend

For DynamoDB, it's worth noting you cannot combine Database Savings Plans with DynamoDB reserved capacity on the same workload.

What's the Financial Impact?

Discount ranges by deployment model:

• Serverless (Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, OpenSearch Serverless) up to 35%
• Provisioned Gen 7+ instances (Aurora, RDS, ElastiCache Valkey, DocumentDB, Neptune, DMS, Timestream InfluxDB) up to 20%
• DynamoDB / Keyspaces on-demand throughput up to 18%
• DynamoDB / Keyspaces provisioned throughput up to 12%

Beyond the headline discount, the stronger financial argument is reducing stranded RI cost. When an RI becomes stranded because an instance was resized or upgraded, you keep paying for the RI while also paying on-demand rates for the new configuration. For large database environments with frequent change, the avoided waste from stranded RIs can equal or exceed the small discount difference between the two commitment models.

What Changes If You're Currently Using Reserved Instances?

Existing RIs continue functioning normally for the remainder of their term with no disruption, no immediate action required.

The decision point comes at renewal. Teams should evaluate how often their databases resize, change capacity modes, or shift deployment models. If the answer is frequently, the flexibility of a spend-based commitment is likely worth the small discount difference compared to an RI.

For the full breakdown of how Usage.ai automates RI and Savings Plan optimization How Usage.ai Works: RIs, SPs & Zero-Risk Savings

Getting Started: A Practical Sequence

1. Audit your current database inventory Catalog every managed database service on AWS service type, instance family and generation, engine, deployment model, Region, and current coverage status.

2. Identify eligible workloads RDS and Aurora need Gen 7+. ElastiCache needs Valkey. DynamoDB, Neptune, DocumentDB, Keyspaces, Timestream, and DMS are broadly eligible. Ineligible workloads stay on RIs or on-demand.

3. Analyze consumption patterns Look at hourly spend data over at least 90 days to understand stability and set a reasonable commitment level. Usage.ai automates this using your AWS Cost and Usage Report data.

4. Model commitment options Evaluate expected coverage ratio, projected savings, and financial risk at different commitment levels. Manual spreadsheet modeling works for small environments but breaks down quickly at scale.

5. Purchase and monitor Buy through the AWS console or API. Monitor coverage levels regularly. Usage.ai tracks this continuously and surfaces adjustment recommendations before gaps become cost issues.

Reserved Instances required predicting exactly what you'd run, on which engine, in which Region, for the next one to three years. Database Savings Plans replace that with a simpler question: how much are you likely to spend?

Most DB teams can answer that confidently. And with spend-based commitments now covering the full managed database stack, the operational overhead of tracking instance-specific commitments drops significantly.

How is your team currently handling database commitment strategy sticking with RIs, moving to Savings Plans, or running a mix? Would love to hear how others are thinking about this transition.

Read the complete deep dive here → AWS Database Savings Plans Explained for DB Teams