# Azure Redis Cache Could Use Reserved Capacity

> Production Azure Redis caches with no stop events in their state history, 60+ days of coverage, commitment-grade uptime, and RedisCPU or RedisMemoryPercent measured at 30% or above are flagged by RC-1339 for 1- or 3-year reserved capacity. Savings prefer a real break-even computation, falling back to a 40% fraction.

Source: https://zop.dev/integrations/azure/recommendations/azure-redis-cache-could-use-reserved-capacity
Updated: 2026-08-19

---

## 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

```bash
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.