To cut an Amazon ElastiCache bill, right-size nodes to the working set first, then pick the engine and capacity model that fit your traffic, and only then buy reserved nodes. Reserved nodes save up to roughly 55 percent on the node hour for a three-year all-upfront term, but the discount only helps if the node is already the right size. ElastiCache Serverless suits spiky or new workloads; steady fleets are cheaper on right-sized provisioned nodes with reservations. ElastiCache for Valkey is priced below Redis OSS on the same sizes and is a drop-in for most workloads. The order matters: committing before sizing locks in waste.
Last updated: June 2026 · Written by Fredrik Filipsson and reviewed by Morten Andersen · See, Cut, Lock, Run method
Amazon ElastiCache is AWS's managed in-memory cache and data store, offered for Redis OSS, Valkey, and Memcached, and billed mainly on the node hour for provisioned clusters or on data and request volume for serverless. The cost trap is the same one that catches every memory service: a cache sized for an imagined peak runs idle most of the day, and a reservation bought on top of that oversized node simply discounts the waste. This article is part of our complete guide to AWS cost optimization, the cluster pillar it links up to.
What drives the cost of Amazon ElastiCache?
ElastiCache cost is driven mostly by node size, node count, and how long nodes run, not by how much data you actually cache. A provisioned cluster bills the node hour for every node in every shard and replica, around the clock, whether the cache is full or nearly empty. So a cluster of large memory-optimized nodes that sits at 20 percent memory utilization costs the same as one running hot. The secondary drivers are data transfer between Availability Zones, backup storage beyond the free allowance, and, for ElastiCache Serverless, the gigabyte-hours of data stored plus the ElastiCache Processing Units consumed. Confirm current node rates and serverless dimensions for your Region against the ElastiCache pricing page, since rates vary by Region and change over time.
How do I right-size ElastiCache nodes?
Right-sizing ElastiCache means matching node memory and node count to the real working set and throughput, not to a headroom guess. Start from the metrics, then change one dimension at a time:
- Read the memory metrics. In Amazon CloudWatch, check
DatabaseMemoryUsagePercentageandBytesUsedForCacheover a representative two to four weeks. A cluster consistently below 40 percent memory use is a candidate to move down a node size. - Check CPU and engine load. Look at
EngineCPUUtilizationfor Redis and Valkey, not just host CPU, because the engine is single-threaded per shard. Low engine CPU with low memory use confirms the node is oversized. - Right-size the node family. Move memory-bound caches to R-family nodes and throughput-bound caches to M-family, then step down one size and observe. Most caches are memory-bound, so the R family usually wins on cost per gigabyte cached.
- Tune the cluster shape. For Redis and Valkey, prefer fewer, right-sized shards over many tiny ones, and drop redundant replicas in non-production. Each replica is a full node you pay for.
- Set a maxmemory eviction policy. Use an eviction policy such as
allkeys-lruso the cache holds the hot working set rather than growing until it forces a larger node.
Right-sizing here mirrors the broader discipline in our AWS cost optimization service: cut idle capacity before you commit. For the streaming side of a data platform, the same sizing logic applies in how to cut Amazon Kinesis and Data Streams costs, the sibling guide in this cluster.
Right-size the node, confirm it holds the working set for a week or two, then buy the reserved node against that stable size. Reserve first and you have paid up front to keep a node you were about to shrink.
Should I use ElastiCache Serverless or provisioned nodes?
Use ElastiCache Serverless when traffic is spiky, unpredictable, or new, and provisioned nodes when traffic is steady and well understood. Serverless removes the idle node problem by billing on data stored in gigabyte-hours and on ElastiCache Processing Units, so you stop paying for a peak-sized node that runs cold overnight. The trade is that for a steady, high-utilization workload, a right-sized provisioned node with a reservation is usually cheaper per unit of work than serverless. The table below frames the choice.
| Decision criterion | ElastiCache Serverless | Provisioned nodes |
|---|---|---|
| Traffic shape | Spiky, bursty, or unknown | Steady and predictable |
| Billing basis | Data stored plus processing units | Node hour, fixed per node |
| Commitment discount | None available | Reserved nodes up to ~55 percent |
| Idle cost | Near zero when idle | Full node hour even when idle |
| Best for | New apps, dev and test, variable peaks | Production caches with a stable working set |
The verdict: start new and variable workloads on Serverless to avoid over-provisioning, and move steady production caches to right-sized provisioned nodes so you can capture the reserved-node discount.
Paying for cache nodes that run cold?
Our AWS cost audit reads your ElastiCache utilization, right-sizes every cluster to its real working set, picks serverless or provisioned per workload, then proves the saving before any reservation. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →How do ElastiCache reserved nodes work, and how much do they save?
ElastiCache reserved nodes discount the node hour in return for a one-year or three-year commitment to a node family and Region. The discount depends on term length and payment option: a three-year all-upfront commitment delivers the deepest saving, up to roughly 55 percent against on-demand, while one-year and partial or no-upfront terms save progressively less. Reserved nodes cover only the node hour, not data transfer, backup storage, or serverless usage, so the prerequisite is a right-sized, stable cluster. Buy reservations against the steady core of your fleet and leave variable capacity on demand, the same commitment logic explained in our AWS Savings Plans vs Reserved Instances comparison. Verify current reserved-node rates and terms against the ElastiCache pricing page before purchase.
Does switching from Redis to Valkey lower the cost?
Yes, ElastiCache for Valkey is priced below ElastiCache for Redis OSS on equivalent node sizes, and AWS positions it as a drop-in replacement for most Redis workloads. Valkey is the community fork of Redis that AWS now offers as a first-class ElastiCache engine, and because it speaks the same commands and protocol, applications using standard Redis features can often move with only a configuration change. The saving is on the node rate itself, so it stacks on top of right-sizing and reserved nodes. Test command and client-library compatibility against a non-production cluster before cutting over production, since edge-case modules and commands can differ.
The AWS Cost Optimization Field Guide includes the cache right-sizing and reservation checklist we run before recommending any ElastiCache commitment, so the discount lands on the fleet you actually keep.
Frequently asked questions
How much do ElastiCache reserved nodes save?
Reserved nodes discount the node hour against on-demand in exchange for a one-year or three-year commitment. The deepest discounts, up to roughly 55 percent, come from a three-year all-upfront term; one-year and no-upfront terms save less. The saving applies only to the node hour, not to data or backup storage, so right-size before you reserve.
Should I use ElastiCache Serverless or provisioned nodes?
Use Serverless for spiky, unpredictable, or new workloads where you would otherwise over-provision for the peak. Use provisioned nodes for steady traffic where you can size to the real working set and buy reserved nodes against it. Serverless removes idle capacity but bills on stored data and processed requests, so a steady fleet is usually cheaper on reserved provisioned nodes.
Do reserved nodes apply to ElastiCache Serverless?
No. Reserved nodes apply to provisioned node families only. Serverless bills on data stored in gigabyte-hours and on ElastiCache Processing Units, and there is no reserved-node instrument for it. To save on Serverless you rely on trimming the application's data footprint rather than a reservation.
What is the difference between Redis and Valkey on ElastiCache for cost?
ElastiCache for Valkey is priced below ElastiCache for Redis OSS on the same node sizes, and AWS positions Valkey as a drop-in for most Redis workloads. If your application uses standard Redis commands, moving to Valkey can lower the node rate with no architectural change. Verify command and client compatibility before switching a production cluster.
The short version
ElastiCache cost is a node-hour problem first. Right-size every cluster to its real working set, choose Serverless for variable traffic and right-sized provisioned nodes for steady traffic, consider Valkey to lower the node rate, then buy reserved nodes against the stable baseline for up to roughly 55 percent off. The discount is only real once the node is the right size. When you want every cache sized correctly and the AWS bill proven down, that is the work our AWS cost optimization 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: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.