Long-running production Redis caches without a reserved-capacity purchase

A cache that has ever been stopped is disqualified

Unique among ZopNight’s Azure commitment rules, RC-1339 checks the resource’s state history for stop events. A cache someone has stopped, even once, is demonstrably not an always-on workload, and locking a 1- or 3-year reservation onto it risks paying for capacity that sits parked. Continuous running history plus a production signal (a prod name pattern like prod/production/prd/live, or an authoritative env tag) are both required before the rule will even look at pricing.

Utilization read on the meters Redis actually reports

The commitment gate reads RedisCPU and RedisMemoryPercent over a 30-day window. Those are the exact series the Azure Monitor producer writes for caches. Under the previous shared gate, which hard-coded the VM metric names CPUUtilization/MemoryUtilization, every real cache came back “utilization unverified” and the rule was dead on live data. Eligibility now requires 60 or more days of observed coverage, uptime at or above the 0.70 floor, and a measured CPU or memory average at or above 30%, with each axis fail-closed and empty metric series treated as unverified rather than as a measured zero. All reads are covered by Monitoring Reader plus Cost Management Reader for the cost basis.

Two pricing paths, one honest percentage

Preferred path: a break-even computation that prices the reservation at 730 hours/month against on-demand billed on measured running hours. A cache that clears the uptime floor but still idles part-time gets a saving capped at the break-even net. If the reservation would lose money, the rule abstains. Fallback path (when tier rates or uptime inputs are missing): a hysteretic uptime suppression plus cost × a derived fraction, defaulting to 40% for Redis. Whichever path runs, the headline percentage is recomputed from the emitted dollar amount so the two never diverge.

Suppressions worth knowing

Existing Reservation or SavingsPlan coverage on the cache, or a reserved=true tag, silences the finding: the discount is already captured. Missing or non-positive pricing abstains.

Inventory your caches and their SKUs

az redis list \
  --query "[].{name:name, sku:sku.name, family:sku.family, capacity:sku.capacity, rg:resourceGroup}" -o table

Match SKU, family, and region when purchasing the reservation. Azure Cache for Redis reservations are scoped to a specific configuration, and a mismatch earns no discount.