<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Redis on LeanerCloud</title><link>https://leanercloud.com/tags/redis.html</link><description>Recent content in Redis on LeanerCloud</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 20 Aug 2026 02:08:40 +0200</lastBuildDate><atom:link href="https://leanercloud.com/tags/redis/index.xml" rel="self" type="application/rss+xml"/><item><title>ElastiCache cost optimization: rightsizing, Valkey, and reserved instances</title><link>https://leanercloud.com/blog/2025-09-30-elasticache-cost-optimization-case-study.html</link><pubDate>Tue, 30 Sep 2025 15:23:51 +0000</pubDate><guid>https://leanercloud.com/blog/2025-09-30-elasticache-cost-optimization-case-study.html</guid><description>&lt;h2 id="elasticache-is-where-i-find-the-most-extreme-overprovisioning"&gt;ElastiCache is where I find the most extreme overprovisioning&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description></item></channel></rss>