AWS Database Savings Plans can reduce eligible database costs by up to 35% in exchange for a fixed hourly spending commitment over one year. They apply across a broad range of provisioned and serverless database services, regardless of AWS Region, database engine, instance family, size or deployment option.
Hykell now supports AWS Database Savings Plans as part of its automated AWS rate optimization service. The objective is straightforward: continuously manage the combination of Database Savings Plans and Reserved Instances so customers capture more savings without creating unnecessary commitment risk or manual work.
Support is initially available through Hykell’s Early Access Program.
What are AWS Database Savings Plans?
AWS Database Savings Plans are a flexible commitment-based pricing model for eligible AWS database usage.
Instead of committing to a particular database engine, instance family, size, deployment model or Region, the customer commits to a consistent amount of discounted database spend per hour for a one-year term.
AWS automatically applies the discounted rates to qualifying usage until the hourly commitment is consumed. Eligible usage above the commitment is charged at standard On-Demand rates.
This flexibility means a business can, for example:
- Move from Amazon RDS for Oracle to Amazon Aurora PostgreSQL
- Change from an Aurora db.r7g instance to db.r8g
- Move a workload between AWS Regions
- Switch between eligible provisioned and serverless database options
The discounted rate can continue to apply, provided the new usage is eligible for Database Savings Plans.
According to AWS Database Savings Plans pricing, the model provides:
- Savings of up to 35% compared with eligible On-Demand database pricing
- A one-year commitment term
- No upfront payment
- Automatic application across eligible provisioned and serverless database usage
- Flexibility across supported engines, instance families, sizes, deployment options and Regions
Which AWS services are covered by Database Savings Plans?
AWS currently lists eligible usage across the following services and categories:
- Amazon Aurora and Amazon RDS instances
- Amazon Aurora Serverless v2
- Amazon Aurora DSQL
- Amazon DynamoDB
- Amazon ElastiCache for Valkey instances
- Amazon ElastiCache for Valkey Serverless
- Amazon DocumentDB instances and serverless usage
- Amazon Neptune instances
- Amazon Neptune Serverless
- Amazon Neptune Analytics
- Amazon Keyspaces
- Amazon Timestream
- AWS Database Migration Service instances
- AWS Database Migration Service Serverless
- Amazon OpenSearch Service
Eligibility is not uniform across every database engine, instance generation or pricing component.
For example, ElastiCache coverage applies to Valkey rather than every ElastiCache engine. For Amazon RDS for SQL Server, Database Savings Plans apply only to the eligible instance price. Microsoft Windows Server and SQL Server licensing charges remain billed at On-Demand rates.
AWS can expand or change eligible usage over time. Coverage should therefore be checked against the current AWS Database Savings Plans pricing page before making a purchase.
Database Savings Plans versus Reserved Instances
Database Savings Plans do not make Reserved Instances obsolete. They solve a different part of the AWS database cost optimization problem.
Reserved Instances generally provide deeper discounts when the workload fits their scope and remains stable. Database Savings Plans provide broader flexibility and can cover eligible serverless services that traditional Reserved Instances do not cover.
| Decision factor | Database Savings Plans | Reserved Instances or reserved capacity |
|---|---|---|
| Commitment basis | Fixed discounted spend per hour | Specific eligible service and configuration scope |
| Term | One year | Varies by AWS service and offering |
| Payment option | No Upfront | Options vary by service |
| Flexibility | Broad across supported services, engines, families, sizes, Regions and deployment models | Narrower and dependent on the reservation type |
| Serverless coverage | Covers selected eligible serverless database usage | Often unavailable or service-specific |
| Discount potential | Up to 35% | Can be higher for stable, well-matched usage |
| Best fit | Changing or mixed database portfolios | Stable and predictable database workloads |
The correct decision is rarely “Database Savings Plans or Reserved Instances” across an entire AWS estate.
A stronger strategy can use both:
- Reserved Instances for predictable usage where the additional discount justifies the narrower scope
- Database Savings Plans for eligible usage that requires broader flexibility
AWS does not apply a Database Savings Plan discount and a Reserved Instance discount to the same unit of usage. A reservation can cover one workload while a Database Savings Plan covers another, but the complete portfolio must be sized together.
Buying one commitment instrument changes the remaining usage available to the others.
Why Database Savings Plans are difficult to manage manually
Database Savings Plans provide broad flexibility, but the financial commitment is still fixed.
A Database Savings Plan cannot simply be resized whenever demand changes. The committed hourly amount must be paid throughout the one-year term.
This creates two basic failure modes:
- Commit too much and part of the hourly commitment goes unused.
- Commit too little and stable usage continues at On-Demand rates.
The calculation becomes more difficult when an AWS environment contains different database engines, Regions, serverless services, Reserved Instances, reserved nodes, seasonal demand, migrations and changing instance generations.
A purchase that looks efficient in isolation can weaken the overall commitment portfolio.
Adding Reserved Instances changes the usage absorbed by Database Savings Plans. A database migration can alter which discount instrument provides the best fit. AWS can also add newly eligible services or instance families, creating new optimization opportunities.
This is why database rate optimization is not a one-time purchasing exercise.
It requires continuous analysis of:
- Savings Plan coverage
- Commitment utilization
- Effective savings
- Existing Reserved Instances
- Upcoming expiration dates
- Workload changes
- Migration plans
- Usage volatility
- Overall commitment exposure
At a small scale, this analysis can be performed manually. Across several accounts, Regions and database services, the number of overlapping decisions quickly turns it into a permanent operational workload.
How Hykell optimizes AWS Database Savings Plans
Hykell treats eligible database usage as one connected commitment portfolio rather than optimizing each AWS service independently.
The automation identifies which usage can be covered, evaluates the available discount instruments and manages an appropriate combination of Database Savings Plans and Reserved Instances.
Where a Reserved Instance offers better economics for stable usage, it can remain part of the strategy. Where flexibility matters more, Database Savings Plans can provide coverage across a broader range of eligible database consumption.
Hykell uses commitment laddering rather than concentrating purchases into a single large commitment with one renewal date.
Commitments are introduced in smaller increments at different times, creating staggered expiration dates. As parts of the portfolio mature, the commitment level can be reassessed against current demand.
This approach is designed to deliver four outcomes:
- Higher effective savings across eligible AWS database spend
- Lower risk of unused or oversized commitments
- More flexibility as database architectures and usage patterns change
- Less manual work for FinOps, cloud and engineering teams
Hykell also monitors changes to AWS discount programs and eligible usage. When AWS expands Database Savings Plans coverage, the portfolio can be reassessed instead of waiting for a manual annual review.
Why commitment laddering matters
A single annual purchase creates a large, static commitment based on one moment in time.
That decision may look reasonable on the purchase date but become inefficient when usage declines, applications are migrated, database engines change or a newer AWS service becomes available.
Commitment laddering divides the same general commitment strategy into smaller purchases distributed over time.
This creates recurring adjustment points. Instead of waiting for one large annual expiration, parts of the portfolio mature at different times. The business can then adjust new purchases based on current usage.
Laddering does not remove the contractual commitment behind a Savings Plan. It reduces the amount of the portfolio exposed to a single forecasting decision.
For changing database estates, this distinction matters.
Who should consider AWS Database Savings Plans?
Database Savings Plans are most relevant for organizations with a dependable baseline of eligible AWS database spend, particularly when the environment spans multiple services or is likely to change during the following year.
They can be especially useful when:
- Aurora Serverless v2 represents meaningful spend
- Another eligible serverless database service has consistent usage
- Workloads may change database engine, instance family, size, deployment model or Region
- Existing Reserved Instances cover only part of the database estate
- The business is modernizing from commercial databases to AWS-native services
- FinOps teams need broader coverage without managing separate commitments service by service
- Database usage is distributed across multiple AWS accounts or Regions
Database Savings Plans are less suitable for highly volatile usage with no reliable hourly baseline.
No discount compensates for paying for a commitment that the business cannot use.
How much should you commit?
The correct Database Savings Plans commitment is not necessarily equal to your average eligible database spend.
Average spend can hide daily or hourly volatility. A workload averaging $100 per hour could regularly fall below that level, making a $100 hourly commitment too aggressive.
The safer starting point is the durable baseline: the amount of eligible database usage that is consistently present across the evaluated period.
The analysis should also account for:
- Existing Reserved Instances and reserved capacity
- Planned workload reductions
- Database migrations
- Instance-generation changes
- Seasonal demand
- New services entering production
- Services or pricing components that are not eligible
- Private AWS pricing arrangements
- Expected changes during the one-year term
AWS provides Savings Plans recommendations and a Savings Plan Purchase Analyzer through its billing tools. These are useful inputs, but they remain based on historical usage and assumptions selected by the customer.
The purchasing decision still requires judgment about what is likely to change next.
Frequently asked questions about AWS Database Savings Plans
How much can AWS Database Savings Plans save?
AWS states that Database Savings Plans can reduce eligible database costs by up to 35% compared with On-Demand pricing.
The actual saving depends on the services and usage covered by the hourly commitment.
How long is the commitment?
Database Savings Plans use a one-year term with no upfront payment.
The customer commits to a consistent amount of eligible discounted database spend per hour.
Do Database Savings Plans cover Aurora Serverless v2?
Yes. Eligible Amazon Aurora Serverless v2 usage is covered.
This is one of the significant differences between Database Savings Plans and traditional reservation-based database discounts.
Can Database Savings Plans and RDS Reserved Instances be used together?
Yes. They can exist in the same AWS commitment portfolio and cover different usage.
Their discounts cannot both apply to the same unit of usage, so the combined portfolio must be sized carefully.
Do Database Savings Plans apply across AWS Regions?
Yes. AWS states that eligible usage can remain covered when workloads move between Regions, subject to the applicable Database Savings Plans rates and eligibility rules.
Can a Database Savings Plan be modified after purchase?
No. The hourly commitment remains in place for the one-year term.
This makes conservative sizing, continuous monitoring and staggered purchasing important.
Do Database Savings Plans cover every Amazon RDS cost?
No.
Eligibility depends on the database service, engine, instance generation and pricing component. For Amazon RDS for SQL Server, Microsoft Windows Server and SQL Server licensing charges are excluded from the discount.
Are Database Savings Plans better than Reserved Instances?
Neither option is universally better.
Reserved Instances can provide higher discounts for stable, well-matched workloads. Database Savings Plans provide greater flexibility across supported services, configurations and Regions.
The best result often comes from using both instruments in a coordinated portfolio.
Does Hykell require changes to database resources?
No.
Hykell optimizes the commercial commitments applied to eligible AWS usage. It does not require application changes or database reconfiguration to manage the discount portfolio.
Join the Hykell Early Access Program
We are working with a limited group of customers to refine Hykell’s support for AWS Database Savings Plans before general availability.
If you run meaningful database workloads on AWS and want the commitment portfolio managed automatically, apply for Early Access.
- Already a Hykell customer? Contact your Hykell team to confirm eligibility.
- New to Hykell? Sign up for Early Access, and a Hykell AWS cost optimization specialist will review your database savings opportunity and eligibility.
Hykell’s objective is to make AWS commitment management automatic, flexible and commercially accountable. Database Savings Plans extend that approach to a much larger part of the AWS database estate.
