Blog
← Blog

AWS Database Savings Plans: Panacea or Pain in the Bum?

March 31, 2026

AWS Database Savings Plans: Panacea or Pain in the Bum?

AWS announced Database Savings Plans in December 2025 as a panacea to your database spending woes: commit to a fixed hourly dollar amount, and get up to 35% off usage across almost every managed database service you run — Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, Keyspaces, Timestream, DMS, and (since March 2026) OpenSearch. One commitment, sixteen services, no upfront payment.

That sounds amazing, but unfortunately, you're gonna be hard pushed to cut 35% — or even 20% — off your database spending, thanks to some sneaky little caveats that Amazon doesn't make immediately obvious.

The pitch: sixteen services, one commitment

Open the Database Savings Plans pricing page and you'll find usage broken across the services covered by the plan:

  • Aurora and RDS Instances
  • Aurora Serverless v2
  • Aurora DSQL
  • DynamoDB
  • ElastiCache for Valkey Instances
  • ElastiCache for Valkey Serverless
  • Amazon DocumentDB Instances / Serverless
  • Neptune Instances / Serverless / Analytics
  • Keyspaces
  • Timestream
  • DMS Instances / Serverless
  • Amazon OpenSearch Service

You're basically just committed to spending a certain dollar amount per hour for the whole year. And it doesn't matter if you spin up new databases, spin down old ones, move workloads between services, or switch regions — the saving remains. Unfortunately, the devil's in the detail — because it only covers specific instance types.

The catch: only newer and more expensive instance families

The pain in the bum that AWS doesn't advertise is that it only supports Gen 7 and newer instance families. Scan the full RDS/Aurora list and you won't find a single row for:

  • db.t4g — AWS's own recommended burstable family for dev/test and small production workloads, and Graviton2-based, not some ancient relic
  • db.t3 / db.t3g
  • db.m5 / db.r5
  • db.m6 / db.r6 (non-Graviton or earlier Graviton generations)

There's also a floor on size, not just generation — no savings for us peasants on the smaller instance types. Scan the eligible Gen 7+ families and the smallest size you'll find is .large; there's no .medium, .small, or .micro variant anywhere in the m7g/r7g/m8g/r8g/m9g lineup. If you're running anything that's excluded from the plan it will never apply to that instance.

And this isn't an RDS oddity — AWS's own Savings Plans FAQ states plainly that Database Savings Plans only offer coverage for Generation 7 and newer instances. So the same exclusions apply to DocumentDB, Neptune, OpenSearch, and DMS too. Any usage on those services that's still pre-Gen-7 gets zero benefit from a Database Savings Plan commitment, just like RDS.

ElastiCache adds an extra restriction on top: coverage is Valkey-only, so even a Gen 7+ Redis OSS or Memcached node doesn't qualify — you need both the newer generation and the Valkey engine. Timestream has its own narrow scope too, limited to InfluxDB instances specifically.

That last point about T-class is worth mulling over. T-class instances are how a huge number of teams run dev, staging, QA, and small production databases — precisely the "not core revenue, but still on the AWS bill every month" workloads that make ideal Savings Plan candidates. Under Database Savings Plans, none of that spend is eligible, no matter how large a commitment you buy — and the same logic extends to any pre-Gen-7 instance sitting inside DocumentDB, Neptune, OpenSearch, or DMS.

Serverless Savings Baby

The two services that dodge this entirely are DynamoDB and Keyspaces — they're throughput/capacity-based rather than instance-based, so there's no "generation" to be excluded from. And every serverless offering gets the same free pass: Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, DMS Serverless, and OpenSearch Serverless are all covered from the first hour you spin them up, with no instance-generation check to clear. If your workload lives on any of these, the generational cliff simply doesn't apply to you.

Compute Only!

There's another caveat here that's just as easy to miss as the generation cliff: Database Savings Plans only ever discount compute usage. Storage and backup costs sit outside the plan entirely, no matter how eligible the instance sitting next to them is.

That is a big deal because storage and backup can be a bit slice of the total — provisioned IOPS on RDS/Aurora, snapshot storage, continuous backups, and for DynamoDB specifically, on-demand storage and backup charges. None of that gets touched by your commitment, even if the compute portion is fully Gen 7+ and otherwise perfectly eligible.

DynamoDB is worth calling out on its own here, since it's easy to assume "DynamoDB is covered" means the whole bill is covered. It isn't — only the request/throughput (compute) side gets discounted. Storage and backup keep billing at full price no matter how large a commitment you buy.

Things to think about before you commit

Database Savings Plans are a fixed 1-year commitment. There's no early exit and no ability to reduce it if your workload composition doesn't match what you assumed. That makes the coverage gap a real financial risk, not a footnote:

  • If your stack is mostly Gen 7+ already, this is close to a no-brainer — flat 20%+ savings with total flexibility to change instance type, engine, or region without losing the discount.
  • If you're spending a lot on t4g, t3, m5, or r5, that portion gets zero benefit from a Database Savings Plan commitment. You'd either need to upgrade those instances to a Gen 7+ family first (itself a cost change, before any discount applies) or accept that your commitment will be sized against a smaller pool of eligible usage than your total database bill suggests.
  • There's no t-class equivalent in the Gen 7+ range — AWS hasn't shipped a burstable t7g/t8g/t9g family, so "just upgrade the generation" isn't a drop-in option here the way it is for Aurora r7g → r8g. Moving off T-class means moving to a non-burstable family entirely, which is a different cost and performance profile, not a like-for-like swap.
  • If a decent portion of your bill is already spent on the eligible serverless services, the sizing exercise is much simpler, but baseline only the compute portion of that spend. Strip out storage and backup charges first (DynamoDB storage/backup, snapshot storage, and the like), then find the level your remaining serverless compute usage never drops below, month over month, and commit against that floor.

The practical takeaway

Before sizing a Database Savings Plan commitment, don't just total your eligible-sounding database spend from Cost Explorer — cross-reference it against the actual instance types you're running. A commitment built against your full database bill, without checking generational eligibility first, will systematically overestimate your effective coverage. The gap between "total database spend" and "Database Savings Plan-eligible database spend" is exactly the kind of thing that's invisible until the first invoice lands with a lower discount than expected.

Curious whether your own AWS account has hidden non-eligible instances sitting inside what looks like Database Savings Plan-covered spend? Jungle Cleaner checks for exactly this kind of coverage gap automatically.