Managed Cache Cost Traps: What We Found in 50 Customer Accounts

Managed caching layers are the cloud bill line item that rarely gets scrutinized. They sit in a middle tier between compute and storage, they're not obviously overprovisioned the way a 96-core database instance is, and they tend to be owned by the backend team rather than the infrastructure team. Which means nobody's particularly looking at them during cost reviews.

We've now done deep-dive cost analysis on caching infrastructure across 50 customer accounts, ranging from early-stage startups to mid-market engineering organizations. The patterns are depressingly consistent. Here's what we found.

Finding 1: Multi-AZ Replication Running Where It Adds No Value

Multi-availability-zone replication roughly doubles the cost of a managed cache cluster. It's the right choice for production session stores, rate-limiting data, and anything that would cause user-visible failures if the cache were unavailable. It is not the right choice for non-production environments, read-through caches with tolerable miss rates, or pre-warmed caches that can rebuild from the underlying database within minutes.

Across our 50 accounts, 31% of caching clusters had multi-AZ enabled in environments where a cache outage would cause zero user impact. Development environments with a single engineer's traffic. Staging environments that get exercised for a few hours before a release. Load test clusters that exist for 72 hours and then get forgotten.

The average waste per account in this category: $340/month. Not dramatic for any individual account, but consistent enough that it shows up in the aggregate as a meaningful line item. The fix is straightforward — audit every caching cluster for its environment tag and disable multi-AZ where the SLA doesn't require it. Most teams haven't done this audit because it wasn't a priority, not because it's difficult.

Finding 2: Node Sizing That Made Sense Three Years Ago

Cache nodes get sized at initial provisioning based on expected workload. Then the workload evolves — sometimes growing, often shrinking in specific dimensions. The node sizing doesn't get revisited unless someone explicitly schedules that review, and most teams don't.

The specific pattern we see most often: a team provisioned a large memory-optimized cache node to handle a particular data shape that has since changed. The application now stores smaller objects or has moved some hot data to an in-process cache. The managed cache cluster is still running on the large node, using 20-30% of available memory, and paying for 100% of it.

Memory utilization below 40% on a cache node is a reliable signal to investigate downsizing. In our sample, 44% of caching clusters were running below that threshold. The average downsizing opportunity was two node generations — not a marginal reduction, but a 60-75% cost reduction for those specific clusters.

There's a legitimate concern about cache eviction when you downsize. If your hit rate is high because the node has memory to spare, downsizing can reduce hit rates and increase database load. The right approach is to monitor the eviction rate and memory fragmentation ratio for 48 hours after resizing, not to avoid resizing altogether.

Finding 3: Orphaned Clusters Still Running After Service Deprecation

This one is embarrassing to write about because it's so preventable. In 22 of the 50 accounts we analyzed, at least one caching cluster was running with zero connections. Not low connections — zero. These were clusters provisioned for services that had been deprecated, migrated, or absorbed into a different architecture. The compute kept running because nobody had cleanup authority or because the deprecation ticket closed without including infrastructure teardown as a task.

The average monthly cost of an orphaned cluster: $180. That's not huge, but it's pure waste with zero justification. And the count adds up. One account had four orphaned clusters totaling $890/month that had been running unused for over a year.

Detection is simple: any caching cluster that has had zero connections for more than 72 hours should trigger an investigation ticket, not an automatic deletion (false positives exist for pre-production environments), but definitely an investigation.

Finding 4: Backup Retention Longer Than Necessary

Managed caching platforms support automated backups, and most teams configure backup retention at the maximum available window, often 35 days. For a session cache, 35 days of backups provides essentially no operational value — if a cache cluster fails, you restore from the latest snapshot or simply let the cache warm up again. You're not rolling back a cache to its state from three weeks ago.

Backup storage costs are not enormous, but they're also not zero. Teams running large caching clusters with weeks of backup retention are paying for restorability they will never use. The standard recommendation: reduce backup retention to 3-7 days for non-critical caches, and document the reasoning so future engineers don't restore it to 35 days "just to be safe."

The Common Thread: Nobody Owns Cache Cost Review

Every one of these four findings points to the same root cause: caching infrastructure doesn't have a clear owner for cost review. The backend team owns the application logic that uses the cache. The infrastructure team owns the provisioning. Finance owns the budget. Nobody owns the intersection of "is this cluster appropriately sized for its current workload and environment."

The accounts that had the cleanest caching cost profiles — in our sample, the top 20% — all had one thing in common: some form of monthly infrastructure review that explicitly covered non-compute services including caching. Not a long meeting. Often just a 15-minute pass over a utilization report. But someone was looking.

KernelRun surfaces caching layer utilization alongside compute and storage in a single view, and flags clusters that match any of the four patterns above. The goal isn't to automate the decisions — downsizing a production cache node carries real risk that should involve a human. The goal is to make sure the question gets asked on a regular cadence.