Skip to content
How we work Results Pricing About FAQ
Sign Up

ElastiCache cost optimization: rightsizing, Valkey, and reserved instances

Cristian Măgherușan-Stanciu
3 min read
#aws #elasticache #redis #valkey #cost-optimization #finops

ElastiCache is where I find the most extreme overprovisioning

Of all the AWS services I optimize, ElastiCache is where I most often find caches provisioned far beyond anything the workload needs. Databases at least tend to grow into their instances. Caches get sized once, generously, and then nobody revisits them.

On one client the ElastiCache clusters were provisioned at 20x to 300x the capacity they actually used. That is not a typo. The smallest available ElastiCache instance was still 2x to 30x larger than what those workloads needed, so even dropping to the floor of the instance range left plenty of headroom. Rightsizing that footprint, together with converting it to Graviton, cut the cost by about 90%, roughly 10x cheaper than before.

A 200-cluster engagement, lever by lever

The clearest example is a recent engagement across a client with more than 200 Redis cache clusters. Three levers were on the table: rightsizing, converting the engine from Redis to Valkey, and purchasing reserved instances. The order and the contribution of each one is the whole point of this post.

Over a few weeks the work took their ElastiCache cost down by more than 6x, from about $600 a day to under $100 a day. That is over $15,000 a month, about $180,000 a year.

ElastiCache daily cost, before and afterDaily cost falls from about $600 to about $140 after rightsizing and the Valkey conversion, then to under $100 after reserved instances.~$600/day~$140/day<$100/dayBeforeRightsizing+ Valkey+ Reservedinstances
Most of the reduction came before any commitment purchase.

Here is how that broke down:

  • Rightsizing and the Valkey conversion did the heavy lifting, bringing the cost down to about $140 a day.
  • The reserved instance purchases contributed only the last $45 a day.

If we had done what most teams do, purchased reserved instances against the existing oversized footprint and called it a day, we would have committed to paying for capacity the workload never needed, and left the large majority of the savings on the table. You rightsize first, then commit to what is left.

Valkey is a straightforward 20% off Redis

Valkey deserves a specific mention because it is one of the cleaner wins available on ElastiCache right now. Valkey is an open-source, Redis-compatible fork of Redis 7.x from before Redis Labs relicensed the project away from open source. On ElastiCache, switching the engine from Redis to Valkey is about 20% cheaper for the same cache, and the conversion runs without downtime for most configurations.

I did this at scale for a client across all their ElastiCache clusters, and combined with rightsizing some of the resources and purchasing reserved instances, it cut their ElastiCache cost in half.

Rightsize on real metrics, not guesses

The reason rightsizing produces numbers like these is that the starting point is so far from reality. To size a cache correctly you need its actual usage: memory in use versus provisioned, CPU, and the engine metrics over a representative window. I gather that per cluster, pick the smallest instance type that comfortably fits the real workload with room to spare, and apply the Graviton equivalent where available, since it is cheaper for the same capacity.

The Graviton conversion is a free win on managed services like ElastiCache: you change the instance type and pay less for equal or better performance, with a lower carbon footprint as a side effect.

Then, and only then, you buy reserved instances against the right-sized footprint, so every dollar you commit to is a dollar you will actually use.

If you run a sizeable ElastiCache footprint and suspect it is oversized, book a discovery call or reach out on LinkedIn.

-Cristian