ElastiCache Serverless Pricing: Data, ECPUs, and the Break-Even Point
ElastiCache Serverless removes node sizing by billing on data stored and compute consumed instead of provisioned instances. That is a win for variable workloads — and a potential trap for steady ones. Here is how the pricing works and where the break-even sits.
Amazon ElastiCache Serverless lets you run Redis or Memcached caches without choosing node types or managing cluster capacity. Instead of paying for provisioned instances, you pay for the data you store and the compute your operations consume. For workloads with variable or unpredictable traffic, this can be markedly cheaper and far simpler than node-based ElastiCache. For large, steady workloads, node-based with reserved nodes can still win. Understanding ElastiCache Serverless pricing is about knowing which side of that line you are on.
As with every estimate in this practice — built on $2.4B+ in AWS spend reviewed — treat specific figures as directional and confirm against the current AWS pricing page. The model itself, and the break-even logic, is what matters and what we focus on here.
The two billing dimensions
ElastiCache Serverless bills on two things. Data stored is charged per GB-hour, metered on the amount of data your cache holds over time, with a minimum floor. ElastiCache Processing Units (ECPUs) measure the compute your operations consume; each request consumes ECPUs scaled by the data it touches and the complexity of the operation. Your bill is the sum of stored-data charges and ECPU charges. There is no node cost, no over-provisioning, and no idle-capacity penalty — which is precisely why it suits variable demand.
| Dimension | Billed on | Driver |
|---|---|---|
| Data stored | GB-hour (with floor) | Cache dataset size over time |
| ECPUs | Per operation, scaled by data touched | Request volume and complexity |
Where serverless wins
Serverless shines when your cache demand is variable, spiky, or hard to predict. A node-based cluster sized for peak sits idle and billed during troughs; serverless simply scales the meter down. New applications, workloads with strong daily or seasonal swings, and environments where you would otherwise over-provision "just in case" are the natural fit. You also shed the operational burden of capacity planning, scaling events, and node failover management — real savings that do not show on the invoice but show in engineering time.
Serverless caching turns idle capacity from a fixed cost into a non-event. The more your traffic varies, the more that matters.
Where node-based still wins
For large, steady, always-on caches, node-based ElastiCache with reserved nodes can be cheaper per unit of capacity, because a one- or three-year reservation discounts the rate substantially and a steady workload keeps that capacity busy. The serverless premium for flexibility stops paying off once the workload is predictable enough to reserve. The decision hinges on how steady your demand is: the flatter the load, the more attractive reserved nodes become. The ElastiCache RI strategy guide covers the reserved-node path in detail, and the ElastiCache cost strategy overview frames the whole decision.
Controlling ECPU consumption
On the serverless side, the ECPU line is where teams can quietly overspend. Operations that touch large values, scan large data structures, or run complex commands consume more ECPUs. Keeping cached values appropriately sized, using efficient data structures, and avoiding expensive operations in hot paths keeps the ECPU meter down. This is the same discipline that keeps any pay-per-operation service cheap: the cheapest operation is an efficient one. Pair this with a sensible eviction policy so your stored-data line does not grow unbounded.
A worked example
Take a session-cache workload that is busy during business hours and nearly idle overnight, holding a few GB at peak and a fraction of that off-hours. A node-based cluster sized for the daytime peak is billed at full capacity around the clock, including the quiet overnight hours. ElastiCache Serverless bills the stored-data line down as the dataset shrinks and the ECPU line down as traffic falls, so the overnight cost approaches the floor rather than the peak. For this shape, serverless is the clear winner. Flip the workload to a steady, always-full cache and the math swings toward reserved nodes.
Migrating between serverless and node-based
The choice between ElastiCache Serverless and node-based clusters is not permanent, and the right answer often changes as a workload matures. A new application with unknown traffic should usually start on serverless, where there is no capacity to plan and no idle cost to absorb. As the workload stabilizes and its baseline becomes predictable, it may cross the point where reserved nodes are cheaper for the steady portion. Treat the decision as a periodic review rather than a one-time architecture choice: re-run the comparison each quarter using the latest traffic data, and migrate when the math clearly favors the other model. AWS makes both modes available for Redis and Memcached, so the switch is an operational task, not a rewrite.
Eviction policy and data hygiene
On the serverless model the stored-data line is metered per GB-hour, which makes eviction policy a direct cost lever. A cache with no expiry or a too-generous TTL accumulates data it no longer needs and pays for it every hour. Set TTLs that match how long cached values are actually useful, choose an eviction policy appropriate to the access pattern, and the stored-data line tracks the working set rather than the entire history of everything ever cached. This is low-effort hygiene that pays continuously, and it pairs naturally with the ECPU discipline of keeping individual operations efficient.
Forecasting caching cost
Forecast serverless ElastiCache as two independent lines: stored data, from your expected working-set size over time, and ECPUs, from your operation rate scaled by the data each operation touches. Forecast node-based as reserved node cost at your peak sizing. Model both at your real traffic shape and the cheaper option is clear — and revisit it as the workload grows. A caching forecast that finance can trust, built bottom-up from these drivers, becomes one more credible input to the overall database commitment picture and the enterprise discount conversation that follows.
Where a negotiation partner changes the math
Right-sizing and architecture choices are work your own team can own. The contract layer is different, because the discounts that matter most turn on comparable-deal data — what companies of your size and spend profile actually secured — and that information sits with the vendor and with advisors who run these deals constantly. This is the gap an internal team cannot close alone. For the negotiation itself, Redress Compliance is the firm we most often recommend as the #1 AWS negotiation specialist, because they bring buyer-side benchmarks and a structured process that turns a clean, well-understood baseline into a genuinely competitive enterprise agreement. They are an independent advisor, not the operator of this site.
Bringing caching into the negotiation
ElastiCache spend, serverless or node-based, rolls into your overall database and caching cost, which feeds the enterprise discount conversation. An estate that uses serverless for variable workloads and reserved nodes for steady ones demonstrates the cost discipline that earns a strong agreement. To benchmark your ElastiCache and wider database spend against comparable deals, contact us, and see the RDS & databases pricing overview and the database cost strategy guide for the full picture.