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:
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.
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.
On-Demand vs Database Savings Plan Spend Over Time Low Medium High Month 1 Month 3 Month 6 Month 9 Month 12 Monthly Database Spend Time On-Demand Database Savings Plan Comparing on-demand and Database Savings Plan spend for a steady RDS workload over one year.
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:
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.
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.
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.
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.
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.
| Aspect | Reserved Instances (RIs) | Database Savings Plans |
|---|---|---|
| Service coverage | Applies to specific database instance families and configurations. | Applies across supported managed database services (Aurora, RDS, DynamoDB, ElastiCache for Valkey, etc.). |
| Flexibility | Tied to a particular engine, instance family, and Region; changes can reduce or lose the benefit. | Commitment is a $/hour spend; discounts follow eligible usage even as you change engines, sizes, and deployment models. |
| Region scope | Generally scoped to a single Region unless you buy specific regional options. | Applies across eligible commercial Regions (excluding China) for in-scope services. |
| Term options | 1-year and 3-year terms, with various payment options. | 1-year term only at launch, No Upfront only. |
| Management overhead | More granular; needs close tracking per engine, instance family, and Region. | Simpler portfolio view focused on total database spend and coverage versus commitment. |
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.
From a business perspective, Database Savings Plans improve cloud database cost management in three important ways:
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.
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:
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.
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:
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.)
Consider a SaaS platform that runs:
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.
Here is a lightweight workflow your team can run in under an hour to size an initial commitment safely.
In Cost Explorer:
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:
Total: $5,500/month, which is roughly $7.60/hour (5,500 divided by 30 days and 24 hours).
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.
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.
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.
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.
As you adjust the slider, AWS updates:
This helps you align the numbers with your roadmap (for example, upcoming region launches or planned migrations).
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.
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.
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.
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.
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.
If you commit too high:
To mitigate this, start with a conservative initial plan, then layer on smaller additional commitments once you have real data on growth and stability.
If you commit too low:
The fix is straightforward: review coverage and utilisation at least quarterly, and increase commitments in small steps as your platform matures and usage stabilises.
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.
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:
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.
Database Savings Plans are worth bringing into your next planning cycle if any of the following are true:
A practical playbook:
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.