Explanation
Why the waste happens and who it affects.
Their node-hours are still often billed at On-Demand rates, either because commitment programs were built around EC2 or because teams expect to change node types. ElastiCache reserved nodes bill a discounted hourly rate for one- or three-year terms, and AWS surfaces missing coverage through Cost Optimization Hub and the Trusted Advisor check for ElastiCache reserved node purchase recommendations.
The inflexibility is smaller than it looks. All ElastiCache reserved nodes are size flexible within a node family and Region, so a reservation follows the cluster when it scales up or out within that family, and Redis OSS reservations also apply to Valkey nodes, so an engine migration does not strand them. Database Savings Plans add a more flexible commitment option for ElastiCache for Valkey usage.
Billing model
The pricing dimensions that drive this cost.
- On-Demand node-hours
- Each node, including replicas, is billed per node-hour at the On-Demand rate for its node type and engine
- Reserved node
- A one- or three-year commitment to a node type in a Region, with No Upfront, Partial Upfront or All Upfront payment, billed for every hour of the term whether or not a matching node runs
- Size flexibility
- Reservations apply to any size in the same node family and Region using normalized units; Redis OSS reservations can also cover Valkey nodes
- Database Savings Plans
- A 1-year, no-upfront hourly spend commitment that covers ElastiCache for Valkey usage on Generation 7 and newer nodes and serverless, along with other AWS database services
How to detect
4 checks to find it in your estate.
- Review the Trusted Advisor check Amazon ElastiCache reserved node purchase recommendations (check ID c1z7kmr13n) and the Purchase reservations recommendations for ElastiCache reserved nodes in Cost Optimization Hub
- Use the Cost Explorer reservation coverage report filtered to ElastiCache to find node families and Regions where running node-hours are mostly On-Demand
- List active reservations with describe-reserved-cache-nodes and compare them with running nodes per family and Region, including reservations that expired recently and were not renewed
- Confirm the baseline is stable by checking node counts and node types over several months, excluding clusters that are scheduled for rightsizing, engine changes or retirement
How to fix
5 ways to remove the waste.
- Purchase reserved nodes for the steady baseline of node-hours in each node family and Region, relying on size flexibility rather than matching exact node sizes
- Resolve pending rightsizing and Graviton or Valkey migrations first, or buy reservations in the target family, so the commitment is not sized to a configuration that is about to change
- When moving from Redis OSS to Valkey, keep existing Redis OSS reservations; they apply to Valkey nodes in the same family and, because Valkey uses fewer normalized units, cover more Valkey capacity
- Consider Database Savings Plans for Valkey usage when node families, deployment models or other database services are expected to change during the term, accepting a 1-year term with no upfront option
- Track reservation expirations and renew or replace them before usage silently reverts to On-Demand rates
Documentation
Vendor references for pricing and configuration.