AWS Database Savings Plan Part 2

AWS Database Savings Plan – Part 2: A Practical FinOps Perspective

By Ran Blumenfeld, FinOps & CSM lead, TeraSky

re: Invent 2025 arrived, and a long-standing expectation across the global FinOps community was finally met: AWS announced the Database Savings Plan.
In the first part of this series, I provided a general overview of the program, explained what it covers, and highlighted the key differences compared to the Compute Savings Plan launched in 2019. I also examined the practical value of the program for Amazon RDS services and Aurora Serverless.

In this second part, I review how the Database Savings Plan applies across twelve additional AWS services, outline service-specific limitations, and provide a practical perspective on whether committing makes sense when compared to existing alternatives, where applicable.

Categorizing the Remaining Services

The remaining twelve services can be grouped into three categories, based on pricing characteristics and the availability of alternative commitment models.

1. Serverless Services

This category includes:

• Aurora DSQL
• ElastiCache for Valkey Serverless
• Amazon DocumentDB Serverless
• Neptune Serverless
• AWS DMS Serverless

Historically, serverless database services did not offer discounted annual commitment models. From that perspective, the Database Savings Plan is welcome news for customers using these services who are willing and able to commit to a baseline level of usage. In most cases, this is a reasonable buy recommendation.

That said, each service has nuances that require careful evaluation before committing.

Aurora DSQL

Discount: A flat 18% across the ten supported regions.

Key consideration: Pricing is based on DPU consumption. A conservative approach is to analyze the lowest sustained DPU usage over the past 30 days, determine the desired coverage level, and size the hourly commitment accordingly.

ElastiCache for Valkey Serverless

Discount: 30% in most regions. In a small subset of regions, the discount is 29% for ElastiCache Processing Units, while the full 30% applies to GB-hours.

Key consideration: Eligibility is limited to Valkey Serverless only. Redis and Memcached are excluded. As with all serverless services, usage volatility should be carefully evaluated before entering a one-year commitment.

Amazon DocumentDB Serverless

Discount: 30%.

Key consideration: The discount applies equally to both Standard and I/O Optimized storage. Commitment sizing should therefore be based on minimum sustained hourly spend rather than average or peak usage.

Neptune Serverless

Discount: 30%.

Key consideration: The discount applies equally to both Standard and I/O Optimized cluster configurations. As a result, the primary recommended input for sizing a Database Savings Plan commitment should be the minimum sustained usage over time, rather than

AWS DMS Serverless

Discount: 20%.

Key consideration: The same discount applies across both deployment options. However, the AWS pricing page currently lists multiple usage rates that appear to describe identical usage types. These points suggest less a pricing nuance and more a documentation inconsistency, which introduces avoidable ambiguity. As a result, extra caution is advised when modeling Database Savings Plan commitments for this service, and assumptions should be validated carefully.

2. Services with Existing Commitment Alternatives

This category includes services where Reserved Instances or other commitment-based pricing models already exist:

• Amazon DynamoDB
• ElastiCache (instance-based)
• Neptune (instance-based)

For these services, the Database Savings Plan should be evaluated in relation to existing options, considering both the depth of the discount and the level of risk exposure.

Amazon DynamoDB

Here, AWS appears to have overcomplicated the model, or at least the pricing presentation. Discounts vary by usage model:

• 18% for On-Demand throughput (six usage types)
• 12% for Provisioned throughput (six usage types)

Discount rates are consistent across regions.

Why is this problematic? If the discount is identical across all usage types within a category, the added granularity introduces unnecessary complexity. If certain usage types are excluded, the model becomes even harder to reason about. What could have been simple instead creates room for confusion and costly mistakes.

Historically, DynamoDB discounts were available only through Provisioned Capacity commitments, offering substantially higher savings: approximately 54% for one-year terms and 77% for three-year terms. While these commitments require a partial upfront payment, the upfront component typically represents less than 50% of the total commitment value.

It is also important to remember that Provisioned Capacity commitments are purchased separately for Read Capacity Units (RCUs) and Write Capacity Units (WCUs), in minimum increments of 100 RCUs, and are scoped per region, not globally.

Recommendation: Existing Provisioned Capacity commitments deliver discounts that are more than 4.5× higher than those offered by the Database Savings Plan. Even covering only half of the optimal baseline usage with Reserved Capacity typically results in materially higher savings.
For workloads operating exclusively in On-Demand mode, however, an 18% discount is still preferable to no discount provided usage variability is well understood.

ElastiCache (Instance-Based)

Eligibility is limited to Valkey and newer instance families only: c7gn, r7g, and m7g. Redis, Memcached, and instance generations 5 and 6 are excluded.

Discount: 20%.

By comparison, one-year Valkey Reserved Instances with no upfront payment offer approximately 32% savings. While the absolute delta may appear modest, it represents more than 50% higher effective savings. At the time of writing, RI pricing is published only for the m7g family.

Summary: The Database Savings Plan is relevant only for Valkey workloads. For other engines, Reserved Instances remain the primary savings mechanism. Migration to Valkey may also be worth considering, given its lower base price. Size flexibility further reduces the risk associated with RIs in this context.

Neptune (Instance-Based)

Neptune may be the most surprising service in this category. Although not publicly documented, Neptune Reserved Instances have been available by request for several years, even at relatively modest monthly spend levels. If you have been running Neptune for an extended period and were unaware of this option, it may be worthwhile to reassess the guidance you are receiving.

In recent customer engagements, one-year Neptune RI discounts ranged between 32–35%. Given that this option has never been broadly advertised, I assume that AWS may eventually retire it now that an alternative exists.

Discount via Database Savings Plan: 20%.

This represents a meaningful reduction compared to historical RI-based savings. Eligibility is also limited to db.r7g and db.r7i instance families. Customers running older generations should exercise caution before committing prematurely.

3. Less Common Services Without Prior Commitment Models

This category includes:

• Amazon DocumentDB instances
• Amazon Keyspaces
• Amazon Timestream
• AWS DMS (instance-based)

These services historically offered no commitment-based discounts. In the absence of stronger alternatives, Database Savings Plans are generally worth considering, assuming usage patterns are stable.

Based on analysis across roughly 100 customer environments, these services are relatively uncommon. As a result, the emphasis here is on discount structure rather than deep technical nuances:

• Amazon DocumentDB instances: 20% discount for 8th-generation DB instances
• Amazon Keyspaces: 18% for On-Demand throughput, 12% for Provisioned throughput
• Amazon Timestream: 20% across all deployment options
• AWS DMS Instances: 20% for single-AZ and multi-AZ deployments on generation 7 and newer instances

Part 2 Summary

Viewed holistically, the Database Savings Plan introduces a compelling construct: a single, dollar-based hourly commitment, starting as low as one cent per hour and scaling globally across twelve services.

For FinOps teams, this offers a low-friction approach to achieving meaningful savings through a one-year commitment, particularly for services that previously lacked a commitment model.

At the same time, deeper analysis often reveals opportunities for materially higher savings through existing mechanisms such as Reserved Capacity and Reserved Instances, without increasing operational or financial risk. Experienced FinOps practitioners can combine these models to achieve superior outcomes.

In practice, a blended strategy might be the best:

• Use Reserved Capacity or Reserved Instances where discounts are significantly higher, and workloads are stable (for example, DynamoDB and RDS).
• Use Database Savings Plans for more volatile, less common, or higher-risk services, or where no stronger alternative exists.

For smaller organizations early in their FinOps journey, Database Savings Plans provide a simple and accessible starting point. As cloud spend grows, more advanced analysis or expert guidance becomes increasingly valuable, enabling more sophisticated strategies and materially higher savings.

Final Notes and Further Reading

This article reflects my professional perspective, informed by hands-on FinOps experience and real-world customer environments. As with any AWS commitment model, the Database Savings Plan requires careful validation of eligibility by instance family, engine type, or applicable usage type.

For the most accurate and up-to-date information on which services are eligible for the Database Savings Plan, I strongly recommend reviewing the official AWS documentation: https://aws.amazon.com/savingsplans/database-pricing/