By Alexey Baikov
CTO and Co-founder

Read More >

AWS recently extended its Savings Plans model to databases. Services such as Aurora, RDS, DynamoDB, ElastiCache, etc. are now eligible for flexible, hourly commitment-based discounts of up to 35%.

For anyone who’s spent time staring at database line items that are almost entirely on-demand, this is welcome news. Database commitments have been one of the messier corners of AWS cost management, and the gap between how well compute commitments work and how limited the database options were has been real.

But a few months into conversations with customers about this, I want to share a clear-eyed picture of what it actually unlocks today, and where the constraints are steeper than the announcement suggests.

The coverage problem is more specific than it looks

The first thing customers discover is that eligibility is narrower than the service list implies.

Coverage is concentrated around specific instance generations, primarily 7th and 8th gen, and certain Graviton families. Not all variants within a service qualify. Not all families within a generation are supported. In many environments, only a fraction of the total database footprint is actually eligible under the current rules.

This matters more than it sounds. According to our own research, only about 33% of database spend across AWS accounts is currently covered by any commitment at all. The rest runs on On-Demand. Database Savings Plans were supposed to help close that gap. But if a significant portion of your database fleet is on older instance types, the new plans won’t apply to them. The coverage ceiling is set by your infrastructure, not your willingness to commit.

There’s also the RI and Savings Plans overlap to contend with. It’s inconsistent across services: Redshift is RIs only, Neptune is Savings Plans only, RDS supports both. AWS Cost Explorer surfaces limited visibility into what’s actually covered versus what’s still exposed on on-demand. Getting an accurate picture of true effective coverage takes more effort than it should.

Activating Savings Plans may require an infrastructure decision first

Taking full advantage of Database Savings Plans often requires infrastructure changes, not just a commitment decision in the billing console.

Because eligibility is tied to newer instance generations, getting started with Database Savings Plans is straightforward for customers already running supported infrastructure. The first savings are accessible quickly, and for that slice of the fleet, the commitment is easy to justify.

The harder part is maximizing coverage. In one environment we analyzed, the savings potential with Database Savings Plans on existing infrastructure was $5.3K per month. After upgrading eligible instances to supported generations, that figure rose to $10.2K per month. Nearly double, from the same commitment model, applied to a modernized fleet. But the upgrade itself takes time, carries operational risk, and requires engineering capacity. Whether the financial upside justifies that effort is a real calculation, not an obvious yes.

This isn’t a criticism of the AWS design. Newer instance families are more efficient, and AWS has good reasons to tie its commitment model to them. But it does mean that for many customers, the realistic near-term savings from Database Savings Plans are lower than the headline numbers suggest, and the path to higher coverage runs through engineering work.

The commitment structure has real limitations

The third constraint is the commitment model itself.

Database Savings Plans currently offer 1-year terms only. For database workloads that tend to be stable and long-lived, this is workable, but it does limit the financial optimization options compared to what’s available on the compute side. There’s also limited stacking flexibility with existing Reserved Instances, which matters for customers who already have RI coverage and are trying to layer in Savings Plans without overcommitting.

Discount levels vary significantly by service and configuration: up to 35% for serverless deployments, up to 20% for provisioned instances, and only up to 12% for DynamoDB and Keyspaces provisioned capacity. Whether the discount justifies a commitment depends heavily on which services dominate your database spend.

What this actually means for your database spend

None of this makes Database Savings Plans a weak product. They are a real improvement over the status quo, and for customers with newer infrastructure already in place, they can deliver meaningful savings with relatively low effort.

The challenge is that most environments aren’t fully ready to activate them at scale. The combination of eligibility constraints, RI interactions, and infrastructure dependencies means that treating Database Savings Plans like Compute Savings Plans (where you can commit a broad hourly amount and let it apply flexibly across your fleet) will lead to lower coverage and higher on-demand exposure than expected.

At Zesty, we approach this as an ongoing management problem. Our Commitment Manager evaluates eligibility at the workload level, models the financial tradeoff of upgrading instances to unlock additional coverage, and manages a portfolio of micro Savings Plans that adjusts continuously as workload demand changes. When usage grows, new micro-plans are added. When usage drops, they expire naturally rather than locking in commitment that no longer applies. The goal is to stay as close as possible to the right coverage level without overcommitting, which in a landscape with real eligibility constraints matters more than ever.

Database Savings Plans are a step in the right direction. Getting the most out of them requires understanding exactly where the ceiling is, and building toward it deliberately.

Want to understand what your actual savings potential looks like given your current database footprint? Book a call today.