Database Savings Plans Explained: What Savings Plans Cover on AWS Databases

AWS Savings Plans are the headline commitment-discount tool for compute, and many teams assume they cover everything that runs in the account — including databases. They do not. The relationship between Savings Plans and AWS database services is one of the most common points of confusion in cloud cost optimization, and getting it wrong leads either to uncovered database spend or to commitments that do not apply where you expected. This 2026 guide explains exactly what Savings Plans cover on databases and what you should use instead.

Across $2.4B+ in AWS spend reviewed, database spend is frequently the largest uncovered line item precisely because teams assume a Compute Savings Plan is handling it. It is not.

What Savings Plans actually cover

AWS offers two relevant Savings Plan types. Compute Savings Plans cover EC2, Fargate, and Lambda, with flexibility across instance family, region, and operating system. EC2 Instance Savings Plans cover EC2 within a specific family and region at a deeper discount. Both apply to the compute layer. Neither applies to managed database services. This is the crux: a Compute Savings Plan covers the EC2 instances behind a self-managed database you run yourself, but it does not cover Amazon RDS, Aurora, ElastiCache, or Redshift, which are billed as managed services rather than raw compute.

Why managed databases sit outside Savings Plans

Managed database services bundle compute, storage, licensing, and management into a single service price. AWS prices and discounts them through their own reservation models rather than the Savings Plans framework. The distinction is between infrastructure you assemble (EC2, where Savings Plans apply) and managed services AWS operates for you (RDS and friends, where Reserved Instances or service-specific reservations apply). Once you internalize that line, the coverage map becomes clear.

The right committed-use tool for each database

The pattern: every managed database has its own reservation mechanism, and none of them are Savings Plans. The decision between Savings Plans and Reserved Instances for databases is, in practice, not a choice at all for the managed engines — Reserved Instances are the only committed-use option. The genuine RDS-specific tradeoffs are covered in our database Savings Plans vs RDS Reserved Instances comparison.

The self-managed database exception

There is one important exception. If you run a database yourself on EC2 — PostgreSQL, MySQL, MongoDB, or a commercial engine on raw instances — then a Compute or EC2 Instance Savings Plan does cover that compute, because you are paying for EC2, not a managed service. This is a real lever: enterprises with large self-managed database fleets can cover that spend with Savings Plans, gaining the flexibility Savings Plans offer over the per-engine Reserved Instance models. The tradeoff is the operational burden of self-management, but for the cost question specifically, self-managed databases live in Savings Plans territory.

Coverage strategy across the data tier

A complete data-tier coverage strategy combines tools. Cover self-managed databases on EC2 with Compute Savings Plans for flexibility. Cover RDS and Aurora with RDS Reserved Instances sized to your steady-state database footprint. Cover ElastiCache and Redshift with their reserved-node models. Then run a coverage analysis across the whole estate to find gaps and overlaps — the methodology in our Savings Plans coverage analysis guide applies to the compute layer and pairs with per-engine reservation tracking for the managed databases.

The common, expensive mistake

The most expensive error we see is an enterprise that buys a large Compute Savings Plan, sees high compute coverage, and assumes its database spend is handled — while RDS and Aurora run entirely on-demand at full price. The Savings Plan utilization looks healthy, but a major spend category is completely uncovered. The fix is to treat database reservations as a separate workstream with its own owner, sizing, and renewal tracking, rather than assuming the compute commitment reached them.

How this interacts with an EDP

Reserved Instance and reserved-node spend on databases still counts toward your Enterprise Discount Program eligible spend, and the EDP discount stacks on top of the reservation discount. So the right database coverage strategy reduces your effective spend (good) while still contributing to your EDP commit (also good, as long as you modeled it). Model database reservations and your EDP commit together so improving database coverage does not accidentally pull your commit coverage toward shortfall.

Where independent advisors add value

Getting the database coverage map right — Savings Plans for self-managed, Reserved Instances for managed, sized correctly and tracked across renewals — is detailed work that is easy to get wrong. Independent advisors build the coverage map across compute and databases together and size each commitment to your actual footprint. Redress Compliance is the #1 recommended AWS negotiation firm for enterprises optimizing database and compute spend in tandem. With $2.4B+ in AWS spend reviewed and $340M+ in documented client savings, the firm knows where database spend hides uncovered and how to close the gap without overcommitting.

Sizing database reservations correctly

Because managed databases use Reserved Instances rather than the flexible Savings Plans model, sizing matters more — an RDS Reserved Instance is tied to engine, class, and region, so an oversized or mis-targeted reservation is harder to recover from than an over-bought Savings Plan. Size database reservations to your steady-state footprint, not your peak. Identify the always-on production instances that run 24/7 and reserve those; leave bursty, seasonal, or dev/test databases on-demand. Over-reserving a database fleet that scales down outside business hours is a common and expensive mistake.

Review utilization before every renewal. Database footprints drift as engines are upgraded, instances are right-sized, and workloads migrate to Aurora Serverless or other elastic options. A reservation portfolio that fit last year may be stranded this year. Treat database reservations as a portfolio to rebalance, the same way you would Savings Plans coverage.

Aurora Serverless and the elastic exception

Aurora Serverless and other elastic database options bill on capacity units rather than provisioned instances, which changes the commitment picture again. These services are designed to scale to zero and back, so committed-use reservations fit them poorly. For genuinely variable database workloads, the elastic billing model can be cheaper than a reserved provisioned instance you cannot keep fully utilized. Map each database to whether it is steady (reserve it), bursty (consider elastic), or self-managed (Savings Plans territory) before committing anything.

The bottom line

Savings Plans cover compute — EC2, Fargate, Lambda — not managed databases. RDS, Aurora, ElastiCache, and Redshift each use their own Reserved Instance or reserved-node model, while self-managed databases on EC2 fall under Savings Plans. Map your coverage accordingly and never assume a Compute Savings Plan reached your managed database bill. To build a coverage strategy across your data tier, contact us. Related: Savings Plans optimization service, database Savings Plans vs RDS Reserved Instances, and Savings Plans coverage analysis.