New AWS Database Savings Plans: 

The Latest AWS launch Revealed

On 2 December 2025, AWS announced Database Savings Plans: a new way to commit to a minimum hourly database spend in exchange for discounted pricing on a broad range of AWS managed databases.

The model is simple:

• You commit to a certain $/hour of database usage for one year.
• AWS applies discounted rates automatically to eligible usage each hour.
• Any usage above your commitment is billed at standard on-demand prices.

At launch, Database Savings Plans are offered as 1-year, No Upfront commitments.

The crucial difference from older models is that your commitment is not tied to a specific database engine, instance family, size, or Region. As long as the usage is for eligible database services, the discount can apply.

At launch, AWS highlighted discounts of up to roughly 35% off eligible serverless-style database usage, and up to around 12–20% off most provisioned instances, depending on service and deployment model.

Exec TL;DR (for founders, product & engineering leaders)

• AWS has launched AWS Database Savings Plans, a new pricing model that gives up to ~35% discounts on serverless databases, and roughly 12–20% on most provisioned capacity, in exchange for a 1-year, no-upfront $/hour spend commitment.
• One commitment can cover Aurora, RDS, DynamoDB, ElastiCache for Valkey, DocumentDB, Neptune, Keyspaces, Timestream (InfluxDB-based instances) and DMS, across Regions (excluding China), engines and deployment models.
• From a CFO/COO perspective, this is a straightforward way to reduce AWS database costs without freezing your architecture roadmap, as long as you size the commitment correctly and review it regularly.

Practically, this becomes one of your highest-ROI levers for AWS cost optimisation in data and AI platforms – if you treat it as part of your ongoing FinOps process, not a one-off purchase.

Which services are covered?

One of the biggest benefits is breadth. A single Database Savings Plan can apply to many services that typically appear in a modern data platform:

• Amazon Aurora
• Amazon RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
• Amazon DynamoDB
• Amazon ElastiCache for Valkey
• Amazon DocumentDB (with MongoDB compatibility)
• Amazon Neptune
• Amazon Keyspaces
• Amazon Timestream (InfluxDB-based instances)
• AWS Database Migration Service (DMS)

Database Savings Plans apply only to Generation 7 and newer instances for these services, along with eligible serverless options (such as Aurora Serverless, ElastiCache Serverless for Valkey, DocumentDB Serverless and Neptune Serverless), plus DynamoDB and Keyspaces throughput. For ElastiCache, coverage currently focuses on Valkey rather than Redis OSS or Memcached.

Coverage is global across commercial AWS Regions (excluding the China Regions). That means a single commitment can sit across the top of multiple database engines, provided they are in scope.

For a startup that already uses RDS for core relational workloads, DynamoDB for hot paths, and Valkey on ElastiCache for performance, this makes it much easier to coordinate discounts across your full managed database stack.

How is this different from previous options?

Before Database Savings Plans, most teams leaned on a mix of Reserved Instances (RIs) and Compute Savings Plans. Now, there are four Savings Plan types in total: Compute, Database, EC2 Instance, and SageMaker AI Savings Plans.

The key comparison many teams will care about is AWS Savings Plans vs Reserved Instances for databases.

1. Service scope

Compute Savings Plans apply to EC2, Fargate and Lambda. They do not touch your managed database usage directly. Database Savings Plans, by design, focus specifically on Aurora, RDS, DynamoDB, ElastiCache for Valkey and the other managed database services listed above.

2. Architectural flexibility

With traditional RIs you commit to a specific engine, instance family and Region. If you move from RDS MySQL in eu-west-1 to Aurora PostgreSQL in us-east-1, you risk losing part of that benefit.

Database Savings Plans are far more forgiving. You can change engines, instance types, sizes, and Regions (within the commercial Regions in scope), while your commitment continues to discount eligible usage.

3. Term length

Database Savings Plans currently have a 1-year term only. While RIs and some other Savings Plan types support 3-year options, AWS has intentionally started Database Savings Plans with a shorter, more flexible commitment window.

For the same underlying usage, AWS applies either a Database Savings Plan discount or an existing Amazon RDS Reserved Instance / Amazon DynamoDB reserved capacity discount, not both. You can run them side by side across different portions of your workloads, but they do not stack on the same usage.

Why this matters for startups and scaleups

From a business perspective, Database Savings Plans improve cloud database cost management in three important ways:

1. Lower unit cost without freezing your roadmap. You can modernise from RDS to Aurora, experiment with serverless, or introduce DynamoDB and ElastiCache for Valkey, while still benefiting from the same commitment.
2. More predictable database spend. A fixed hourly commitment gives finance a stable baseline against which to plan, even if usage shifts between services and Regions.
3. Better alignment with how startups actually evolve. Early-stage teams rarely know the exact database mix they will need 12–18 months out. A flexible spend commitment lets you evolve your stack without constantly rewriting discount strategies.

This makes the plans a strong building block for any startup cloud cost control strategy – especially if you are already spending thousands per month on managed database services.

Where Database Savings Plans really shine (scenarios)

1. Modernising from RDS to Aurora

Suppose you are running a steady RDS for PostgreSQL cluster in production and planning to move to Aurora PostgreSQL for performance, reliability and operational benefits. You have been wrestling with Amazon RDS pricing for a while and want to improve your database unit economics.

With a Database Savings Plan:

• Your commitment can cover the original RDS instances and the new Aurora cluster during migration and cut-over.
• If you later introduce Aurora Serverless for bursty workloads, the same commitment can still apply to that usage.

This is exactly where you start to see meaningful Aurora Serverless savings without having to guess in advance which specific Aurora configuration you will be on 12 months from now.

2. DynamoDB-heavy workloads

Many modern applications offload hot paths to DynamoDB – for session state, feature flags, low-latency API reads, and more. As usage grows, the corresponding bill becomes a focus for DynamoDB cost optimisation.

Database Savings Plans can help by:

• Applying discounts to both on-demand throughput and provisioned capacity (with different discount levels per pricing model).
• Smoothing the cost impact of over-provisioning during experiments or new feature launches.

3. Caching and read-heavy apps

If you rely on Valkey on ElastiCache to offload reads from your primary databases, those clusters can consume part of your Database Savings Plan commitment. This lets you optimise your ElastiCache pricing model for latency and reliability first, while the plan drives effective per-GB and per-node costs down over time. (ElastiCache for Redis and Memcached are not currently covered.)

4. Multi-service, multi-Region platforms

Consider a SaaS platform that runs:

• Aurora in eu-west-1 for EU customers,
• DynamoDB in us-east-1 for global metadata, and
• Timestream (InfluxDB) for time-series metrics.

This is a classic pattern of multi-region database deployments. Because Database Savings Plans operate across supported services and Regions, a single plan can help manage the total spend across these workloads, as long as aggregate hourly usage sits in the right range relative to your commitment.

Simple cost-estimation workflow (with numbers)

Here is a lightweight workflow your team can run in under an hour to size an initial commitment safely.

Step 1 – Pull your last 30–60 days of DB spend

In Cost Explorer:

• Filter on the services where you have Database Savings Plans–eligible usage: Aurora, RDS, DynamoDB, ElastiCache (Valkey usage), DocumentDB, Neptune, Keyspaces, Timestream (InfluxDB-based instances), and DMS.
• Group by service and Region so you can see how “steady” each workload appears over time.

In Cost Explorer you will see these at the service level (for example “Amazon ElastiCache” and “Amazon Timestream”), so it is worth drilling into usage types and operations to isolate Valkey and Timestream InfluxDB usage where needed.

For example, you might find:

• RDS & Aurora: $3,500/month
• DynamoDB: $1,200/month
• ElastiCache for Valkey: $800/month

Total: $5,500/month, which is roughly $7.60/hour (5,500 divided by 30 days and 24 hours).

Step 2 – Decide your “safe” commitment

For a first purchase, it is rarely wise to commit to 100% of observed spend. A common pattern is to commit to 70–85% of the average steady-state hourly spend.

Continuing the example above, 80% of $7.60/hour is about $6.10/hour. So a sensible starting commitment might sit around $6/hour.

Step 3 – Apply discount bands and sanity-check

Very roughly, you might assume that half your spend is serverless-style or on-demand throughput (eligible for higher discounts), and the other half is on provisioned instances (eligible for slightly lower discounts). That could lead to a blended discount somewhere in the mid-20% range on the covered portion of spend.

Your finance team can now sanity-check whether a 1-year commitment at that level makes sense in the context of your product roadmap, runway, and expected growth.

Step-by-step: Using AWS console tools

AWS has integrated Database Savings Plans into the existing Savings Plans experience, so the workflow will look familiar if you have bought other plans before.

1. Use AWS recommendations as a starting point

1. Open the AWS Billing & Cost Management console.
2. In the left navigation, choose Savings and commitments → Savings Plans → Recommendations.
3. Select “Database Savings Plans” as the plan type.
4. Choose a lookback period (30 days is usually a good default; 60 days if you have ramped recently).
5. Set the term (1 year). Database Savings Plans are No Upfront only, so there is no payment option to choose for this plan type.

AWS will show a recommended hourly commitment, estimated savings, and projected utilisation and coverage. Treat this as an anchor that you adjust with your own context and risk appetite.

2. Fine-tune in the Purchase Analyzer

1. From the Savings Plans section, open the Purchase Analyzer.
2. Select “Database Savings Plans” as the plan type.
3. Adjust the lookback period and move the hourly commitment slider.

As you adjust the slider, AWS updates:

• Projected cost vs on-demand.
• Coverage and utilisation curves.
• Under- and over-commitment indicators.

This helps you align the numbers with your roadmap (for example, upcoming region launches or planned migrations).

3. Purchase in the console

1. Go to Savings Plans → Purchase.
2. Choose the plan type “Database Savings Plan”.
3. Select the term (1 year). Database Savings Plans are No Upfront only, so there is no payment option to change.
4. Enter your chosen hourly commitment (for example, $6/hour in our example).
5. Review the estimated coverage and savings, then confirm the purchase.

The plan becomes active shortly after purchase. AWS indicates you can expect to see savings show up in your bill within about 8 hours of purchase, after which discounts apply automatically on an hourly basis to eligible usage.

Step-by-step: Automating with AWS CLI

Teams that manage infrastructure as code often want to drive Savings Plan purchases and reporting via automation. The Savings Plans API and AWS CLI make this possible.

1. Discover relevant offerings

First, use the CLI to list Savings Plan offerings that match the Database Savings Plan configuration you want (for example, Database plan type, 1-year term):

Important: CLI options for Database Savings Plans are evolving; always check the latest AWS CLI documentation for the exact parameters supported in your environment. The example below may need updating for your AWS Region or CLI version.

aws savingsplans describe-savings-plans-offerings \
  --plan-types Database \
  --max-results 20

From the output, select the offeringId that matches your desired configuration.

2. Create a Savings Plan

Then create the Savings Plan with your chosen commitment:

aws savingsplans create-savings-plan \
  --savings-plan-offering-id <your-offering-id> \
  --commitment "6" \
  --client-token "db-sp-prod-2025-01"

Here, --commitment "6" represents a $6/hour commitment in the offering’s currency.

3. Verify utilisation and coverage

Use the console and Savings Plans utilisation/coverage reports to check that your actual usage sits close to the committed amount. Low utilisation suggests over-commitment, while consistently high uncovered usage suggests room for an additional plan.

Guardrails: what to watch out for

1. Over-commitment risk

If you commit too high:

• You still receive the discount on covered usage, but utilisation will be low, and you effectively pre-pay for capacity you no longer use.
• This most often happens after major architectural changes, such as decommissioning large clusters or moving workloads off AWS.

To mitigate this, start with a conservative initial plan, then layer on smaller additional commitments once you have real data on growth and stability.

2. Under-commitment (money left on the table)

If you commit too low:

• You still get savings, but a significant slice of steady usage remains on on-demand pricing.

The fix is straightforward: review coverage and utilisation at least quarterly, and increase commitments in small steps as your platform matures and usage stabilises.

3. Term and Region considerations

Because Database Savings Plans are 1-year only, you are trading some depth of discount for flexibility. They apply across eligible Regions (excluding China), but you should be realistic about planned Region launches when sizing commitments. It is safer to leave headroom for unproven future workloads than to over-commit based on aggressive projections.

How this fits into your AWS FinOps strategy

Database Savings Plans should sit inside a broader, deliberate AWS FinOps strategy, not as a one-off optimisation ticket. For most startups and ISVs, that means:

• Policy. Define who can buy Savings Plans, at what thresholds, and with which approvals (for example, anything above $10/hour might require CFO sign-off).
• Data. Use tags, Cost Explorer and Savings Plans utilisation/coverage reports to understand which products and teams consume the discounts.
• Process. Run a quarterly optimisation cycle where you review coverage and utilisation, compare actual vs forecast growth, and decide whether to add, pause or adjust further commitments.

At Cloud Combinator, we typically plug these decisions into wider initiatives such as Optimised AI Environment, Data Platform Modernisation and Secure & Compliant Cloud Platform – ensuring that cost optimisation never undermines SLAs, reliability or compliance requirements.

When should you act?

Database Savings Plans are worth bringing into your next planning cycle if any of the following are true:

• Your managed database bill is above roughly $3,000–$5,000 per month and trending upwards.
• You are planning migrations (for example RDS to Aurora, or adding DynamoDB or ElastiCache for Valkey) but do not want to lock into specific instances for three years.
• You are under pressure to improve database unit costs while continuing to invest in data and AI features.

A practical playbook:

1. Run the 30–60 day analysis in Cost Explorer for all in-scope database services.
2. Use AWS Recommendations and Purchase Analyzer to propose a “safe” first commitment.
3. Start with a modest 1-year plan, then adjust quarterly as usage stabilises or grows.
4. Integrate utilisation and coverage checks into your regular FinOps and architecture reviews.

If you want help designing this as part of a broader FinOps and data strategy, this sits squarely within Cloud Combinator’s services for startups, including FinOps support, data platform modernisation, and building agentic AI systems on top of these databases.