Buy Azure Cache for Redis reserved capacity

This is a rare security-and-cost item that is purely about saving money, with no risk to the workload. Advisor only raises this recommendation when it sees enough steady pay-as-you-go Redis compute that a reservation would beat the on-demand rate, and its threshold is a meaningful saving rather than rounding error. For a cache that already runs around the clock, the reservation simply re-rates hours you are paying for anyway at up to 55% off on the Premium tier, per Microsoft's documented range.

Frame the decision as a payback calculation, not a spend approval. The commitment is a known number: quantity of nodes times the reserved rate times the term, payable upfront or monthly. Against it sits the avoided on-demand spend over the same period. Because Azure offers self-service exchange and refund within limits, a reservation that stops matching can be unwound rather than written off, which caps the downside and makes the payback the only number that really matters.

The one judgement call is commitment risk: do you still expect to run this cache, at this size and region, for the term? For a stable production cache the answer is usually yes, which makes this close to free money. Where it is genuinely uncertain, a one year term de-risks the call versus three years, and the documented refund path is the backstop.

Priya is the finance partner supporting the platform team. The Advisor recommendation lands flagging two always-on Premium caches as reservation candidates with a modelled annual saving. The instinct is not to wave the prepayment through, nor to reject it as new spend; it is to turn it into a payback. The reserved rate is up to 55% below the pay-as-you-go rate on the Premium tier per Microsoft's documented range, so the question is simply: over the term, does the avoided on-demand spend clear the commitment, and how long until it breaks even?

Priya asks the team to confirm the two inputs that decide the answer. First, are these caches genuinely steady-state, or is the usage seasonal? The trailing usage and the product roadmap both say steady, so the reservation will be consumed. Second, what is the right term: a three year reservation maximises the discount, but a one year term de-risks a still-growing product. The finance pack reads: 'Both caches run around the clock, the reservation re-rates compute we are already buying at a documented discount, the payback lands inside the first months, and the downside is capped because Azure allows self-service exchange and refund within limits. This is a payback decision, not a spend request.'

The cost model here is the inverse of most security work: inaction is the expensive option. Every hour a flagged, always-on cache runs unreserved, it pays up to the full on-demand premium on the Premium tier per Microsoft's documented range. Across a year of continuous running, that compounds into a material number that the reservation simply removes, with no change to the workload.

The downside is bounded in a way that makes the decision easy to defend. The commitment is a known figure, payable upfront or monthly, and Azure's self-service exchange and refund within limits means a reservation that stops matching can be unwound rather than lost. The finance role is to attach a payback period to each Advisor recommendation, confirm the workload is genuinely steady for the term, and choose the term, one year for a still-growing product, three for a stable one, that fits the confidence horizon.

Some costs are a risk decision and some are simply money left on the table. This is the second kind. A cache that runs continuously at the pay-as-you-go rate is overpaying for compute the organisation has already committed to in practice, and Azure's own Advisor is pointing at the saving.

The leadership question is not 'should we spend on reservations?' It is 'are we paying the on-demand premium on infrastructure we know we will run for years?' Reserving steady-state compute is a normal part of running a cloud estate efficiently, and Advisor turns it from a manual audit into a standing recommendation.

The only real consideration is commitment horizon: a reservation is a one or three year prepayment, so the question is confidence that the workload persists, not whether the saving is real. With self-service exchange and refund available within limits, even that risk is bounded.

After a cost review where Redis showed up as a quietly growing line, the CFO asked the obvious question: are we paying the right rate for infrastructure we know we will keep? The honest answer at the time was that the caches were billing at the on-demand rate by default, because nobody had acted on the reservation recommendation Advisor had been raising for weeks.

The team's response was to stop treating reservations as an occasional finance project and start treating them as standing housekeeping. They read the Advisor recommendation, confirmed the two caches were genuinely always-on, sized the reservation in the correct node increments, and bought a term that matched the product's confidence horizon. The next time the CFO asked the question, the answer had changed from 'we pay whatever the on-demand rate is' to 'steady-state compute is reserved, the discount applies automatically, and the commitment is reversible within limits if the workload changes.' That shift, from paying the lazy on-demand premium to buying certainty at a documented discount, is the confidence signal this recommendation delivers, and it lowers the bill rather than raising it.

Nearly every cloud estate of any size carries some steady-state compute that is quietly billing at the on-demand rate because nobody acted on the reservation recommendation. An always-on Redis cache is a clean example: the usage is committed in practice, so paying the uncommitted rate is pure leakage that Azure's own Advisor is pointing at.

The cost of acting is a bounded, reversible prepayment, and the cost of not acting is a recurring premium on compute you will run regardless. This is the rare class of decision where the recommendation comes from the platform itself, the saving is documented, and the risk is capped by a refund path, which is exactly the trade leadership should approve quickly.