Last updated: June 2026
For RDS and ElastiCache the choice between Savings Plans and Reserved Instances is settled by eligibility: Savings Plans cover EC2, Fargate, Lambda, and SageMaker only, not RDS or ElastiCache. The commitment tools for the data layer are RDS Reserved Instances and ElastiCache Reserved Nodes, so the decision is whether to reserve, at what coverage, and on which term.
- Savings Plans never apply to RDS or ElastiCache. Do not plan around them.
- Use RDS Reserved Instances and ElastiCache Reserved Nodes for the data layer.
- RDS RIs offer size flexibility within an engine and family; ElastiCache nodes are tighter.
- Rightsize each database and cache first, then reserve the stable floor.
A Savings Plan is a commitment to a steady dollar-per-hour of compute spend, and a Reserved Instance is a commitment to a specific instance configuration in exchange for a discount. For RDS and ElastiCache the comparison resolves before it starts, because AWS Savings Plans cover EC2, Fargate, Lambda, and SageMaker only and do not apply to either service. This article is part of our commitment cluster; the pillar it links up to is the complete guide to cloud commitment management. Choosing and sizing these reservations is the Lock step in our See, Cut, Lock, Run method, and it always follows rightsizing the databases and caches first.
Do Savings Plans cover RDS or ElastiCache?
No. Per the AWS Savings Plans documentation, the program covers Amazon EC2, AWS Fargate, AWS Lambda, and Amazon SageMaker usage. Amazon RDS and Amazon ElastiCache are not eligible. That single fact reshapes the whole question: there is no Savings Plan you can buy that will discount an RDS database or an ElastiCache cluster, so the only commitment instruments available are RDS Reserved Instances and ElastiCache Reserved Nodes. The decision is therefore about how to reserve the data layer well, not about picking between two instruments.
How do the instruments compare for RDS and ElastiCache?
Here is the scorecard for the commitment options that actually apply to the data layer, with the Compute Savings Plan shown only to make the boundary explicit.
| Criterion | Compute Savings Plan | RDS Reserved Instance | ElastiCache Reserved Node |
|---|---|---|---|
| Covers RDS / ElastiCache? | No | Yes (RDS only) | Yes (ElastiCache only) |
| Commitment unit | Dollar per hour of compute | Specific DB instance class and engine | Specific cache node type |
| Indicative max discount | Up to ~66% on eligible compute | Up to ~65 to 69% (3-yr, all-upfront) | Up to ~55 to 60% (3-yr, all-upfront) |
| Flexibility | Floats across EC2, Fargate, Lambda | Size-flexible within engine and family and Region | Tied to node family and Region |
| Terms | 1 or 3 years | 1 or 3 years | 1 or 3 years |
| Best for | The EC2 / serverless layer | Steady production databases | Steady production caches |
Verdict: For RDS and ElastiCache, Reserved Instances and Reserved Nodes are the answer because Savings Plans are not eligible. Reserve the steady production floor of each on a three-year term where the workload is stable, and leave variable or short-lived databases on demand.
Not sure how much of your data layer to reserve?
Our commitment management service rightsizes RDS and ElastiCache first, then sizes Reserved Instances and Reserved Nodes to the stable floor with the right term and payment option. On the performance model you pay only from realized savings. No savings, no fee.
Book a commitment review →Are RDS reserved instances flexible like Savings Plans?
Partly, and the difference matters when you plan coverage. RDS Reserved Instances offer instance size flexibility: within the same database engine, instance family, and Region, the discount floats across sizes in proportion to a normalization factor, so scaling a db.r6g.large up to a db.r6g.xlarge keeps coverage applied. What they do not offer is the cross-service portability of a Compute Savings Plan, which floats freely across EC2, Fargate, and Lambda. ElastiCache Reserved Nodes are tighter still, tied to a node family and Region. The practical consequence is that the data layer needs its own coverage plan sized to its own stable floor, which is exactly the discipline in setting a commitment coverage target per service rather than one blanket number.
How should you commit across EC2, RDS, and ElastiCache together?
Treat the compute layer and the data layer as separate commitment programs. Put a Compute Savings Plan over the EC2, Fargate, and Lambda layer because it is eligible and flexible there. Cover the data layer with RDS Reserved Instances and ElastiCache Reserved Nodes sized to each service's steady production floor. In every case, rightsize first: an oversized db.r6g instance reserved for three years strands exactly as badly as an oversized EC2 fleet, and the fix is the same Cut-before-Lock order described in avoiding stranded commitments after rightsizing. Reserving the data layer cleanly is one of the higher-return moves on AWS precisely because the discounts are deep and the workloads are usually steady.
Eligible services, flexibility rules, and indicative discount ranges reflect AWS as of June 2026. Verify current eligibility and rates in the linked AWS documentation before buying, because pricing and reservation terms change.
The Commitment Strategy Playbook includes the per-service coverage worksheet that separates the compute layer from the data layer. It is the downloadable companion to this article.
Frequently asked questions
Do Savings Plans cover RDS or ElastiCache?
No. AWS Savings Plans cover EC2, Fargate, Lambda, and SageMaker only. They do not apply to Amazon RDS or Amazon ElastiCache. For those services the commitment instruments are RDS Reserved Instances and ElastiCache Reserved Nodes, so the choice is not Savings Plan versus RI, it is whether to buy the reservation at all.
What commitment discount can RDS and ElastiCache reservations give?
RDS Reserved Instances can discount roughly up to 65 to 69 percent versus on-demand on a three-year, all-upfront term, and ElastiCache Reserved Nodes roughly up to 55 to 60 percent, depending on engine, instance family, term, and payment option. Always verify current rates against the AWS pricing pages before buying.
Are RDS reserved instances flexible like Savings Plans?
Partly. RDS Reserved Instances offer size flexibility within an instance family and Region for the same database engine, so coverage can float across sizes, but they are not interchangeable across engines or families the way a Compute Savings Plan floats across EC2, Fargate, and Lambda. ElastiCache Reserved Nodes are tied to a node family and Region.
How should I commit across EC2, RDS, and ElastiCache together?
Use a Compute Savings Plan for the EC2, Fargate, and Lambda layer, and separate RDS Reserved Instances and ElastiCache Reserved Nodes for the data layer. Rightsize each layer first, then size each commitment to its own stable floor, because the instruments and their flexibility differ by service.
The short version
For RDS and ElastiCache the comparison is settled by eligibility: Savings Plans do not cover either service, so RDS Reserved Instances and ElastiCache Reserved Nodes are the commitment tools. Rightsize each, reserve the steady production floor on the right term, and keep the data layer's coverage plan separate from compute. When you want the data layer reserved correctly, that is exactly what our commitment management service delivers.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, AWS documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.