Azure Cache for Redis
Does ZopNight manage Azure Cache for Redis?
Azure Cache for Redis bills hourly for a fixed tier and capacity no matter how much traffic the cache serves, and no stop operation exists. ZopNight reads tier and capacity via Resource Graph, watches 60 days of hit rates and memory usage, and flags oversized caches for rightsizing.
Rules that fire on Azure Cache for Redis
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only; Azure Cache for Redis cannot be stopped. |
Azure Cache for Redis provides managed in-memory caching on fixed-size tiers billed hourly regardless of traffic. Caches provisioned for launch-day load and never revisited are a common silent cost.
A flat hourly meter that traffic never moves
The cache bills for its tier and capacity size, per hour, from creation until deletion. Requests served, hit rate, and memory actually occupied change nothing on the meter: an empty cache and a saturated one on the same size cost the same. There is no stop operation, no pause, and no scale-to-zero: the only lever that changes the bill is choosing a different size or tier, or deleting the cache. Replication in the higher tiers raises the hourly rate further, since the standby node is part of what the tier buys.
Evidence ZopNight gathers before a resize
Discovered via Azure Resource Graph with tier and capacity. Azure Monitor metrics with a 60-day lookback reveal hit rates and memory usage, Cost Management billing attributes spend, and rightsizing recommendations flag oversized caches. Because the type cannot be stopped, scheduling does not apply. The platform’s contribution is making the flat meter visible and pairing it with two months of utilization evidence, which is what a resize decision actually needs.
How cache spend goes stale
Cache sizing decays in a particular way: it is set once, under launch pressure, with generous headroom, and then nothing ever forces a review, because a too-big cache produces no errors, no alerts, and no complaints. Meanwhile the application changes: features that drove cache load get rewritten, traffic shifts, a CDN absorbs what Redis used to serve. The classic leaks are launch-sized caches years past launch, one cache per microservice where several could share, and non-production caches on production tiers with replication protecting throwaway data.
Reviewing caches in the portal
Azure portal → Azure Cache for Redis lists each cache with its tier and size. A cache’s Metrics blade charts used memory and cache hits. Sustained low memory occupancy against a large fixed size is the visual signature of an oversized cache.