Buy a Red Hat software reserved plan

This is a pure savings recommendation, not a security or risk one. Advisor has measured that a block of RHEL software hours runs steadily enough that committing to a one-year or three-year plan beats paying the on-demand rate. The saving is the gap between the on-demand Red Hat meter and the discounted plan rate, multiplied by every hour those VMs run for the life of the plan. Microsoft does not publish a single headline discount percentage for Red Hat software plans, because the figure depends on the plan and the region, so do not anchor on any quoted number: let the calculate step confirm the real saving for your usage before you commit.

The finance question is not whether to save, it is how much to commit. Advisor recommends a quantity sized to your stable baseline, so the plan covers the RHEL hours you run every hour of every day and leaves the spiky, uncertain capacity on demand. Buy to the baseline and the commitment is close to risk-free: you are prepaying hours you were always going to consume.

The arithmetic is clean because the plan only touches the software meter. It does not change the compute bill, it does not require redeploying anything, and the discount lands automatically on matching VMs the moment the plan is active. The one genuine trade-off to weigh is liquidity and lock-in: a Red Hat plan is paid for the term and, unlike Reserved VM Instances, cannot be refunded or exchanged, so the baseline you commit to needs to be one you are confident will still be running.

Dana is the finance partner for the platform team. The Advisor recommendation lands with an estimated saving attached, but the instinct is not to rubber-stamp the recommended quantity. It is to separate the RHEL hours that run every hour of every day from the hours that burst and disappear, because a non-refundable plan should only ever be sized to the part that is genuinely steady. The team pulls the usage Advisor evaluated and confirms how many RHEL VMs sit in the always-on production baseline versus the test and burst pool.

The decision reframes cleanly. The steady baseline is hours the company is going to pay for no matter what, so prepaying them at the plan rate is close to risk-free and the saving is the difference between the on-demand software meter and the discounted plan rate over the whole term. The burst pool stays on demand because committing to it would mean prepaying hours that might not run. Dana writes it up as: 'Commit a plan to the production baseline, leave the burst pool on demand, and the saving is locked in against hours we were always going to consume. The only thing we give up is the cash up front, which a Red Hat plan requires in full, for a term we cannot refund, which is acceptable because this baseline is not going anywhere.'

The return-on-investment profile here is unusually clean. The cost of acting is the upfront prepayment for a term, against a baseline Advisor has already confirmed is steady. The return is the gap between the on-demand Red Hat meter and the discounted plan rate on every covered hour for the life of the plan, with the exact figure confirmable before you buy via the calculate step rather than from any headline percentage. There is no migration, no compute change and no operational risk attached to the saving itself.

The cost of not acting is recurring and unrecoverable. Each billing cycle that the steady RHEL software runs on demand is a cycle billed at list price that a plan would have discounted, and that money cannot be clawed back once the cycle closes. The finance role is to size the commitment to the genuinely stable baseline so the saving is captured without taking on lock-in against volatile hours, and then to act promptly, because the saving is time-bound and every deferred cycle is a deferred discount.

Azure Advisor, Microsoft's own optimisation engine, has looked at your Red Hat Linux usage and concluded you are overpaying for the software licence by running it on demand. This is not a projection from a vendor pitch: it is a recommendation grounded in your real, measured consumption over the past two months.

The decision is a straightforward return-on-investment call. Committing to a one-year or three-year Red Hat software plan prepays a licence cost you are already paying every hour and returns it at a discount, with the benefit applied automatically. The compute bill, the workloads and the operations are all unchanged. The only thing that changes is the unit price of a steady, predictable line item.

The single point of judgement for leadership is commitment confidence. A Red Hat plan is non-refundable and non-exchangeable for its term, so the question is simply whether the baseline of RHEL workloads it covers will still be running. For a stable production estate that answer is usually an easy yes, which is what makes this one of the lowest-risk savings on the Advisor list.

After a cost review flagged that Red Hat licence spend had crept up with the RHEL estate, the CFO asked the obvious question: is Microsoft's own tooling telling us we are overpaying, and if so, why have we not acted? The honest answer was that Advisor had been raising a Red Hat reservation recommendation for a while, but nobody owned the call on how much to commit, so it sat unactioned and the on-demand software meter kept running.

The team's response was to treat the recommendation as a sizing exercise rather than a yes or no. They confirmed the always-on RHEL baseline, bought a plan sized to it on a term that matched how long those workloads are expected to run, and left the volatile capacity on demand. The next review showed the Red Hat software line dropping to the discounted rate automatically, with no change to the workloads. The CFO's takeaway was the useful one: when Microsoft's optimisation engine flags a saving on steady, predictable spend, the default answer should be to size it and take it, not to let it age on the recommendations list.

This is the rare cost recommendation where Microsoft's own engine has done the analysis, the saving is on spend you are already committed to, and acting changes nothing about how the business runs. The compute is the same, the workloads are the same, the only change is that a steady licence line moves to a discounted rate. The risk of acting is bounded to the term commitment; the risk of not acting is continuing to pay list price on steady spend indefinitely.

The cost of getting this wrong is small and quantifiable: at worst, a plan sized slightly too large leaves a portion of the commitment underused, which is exactly why the plan is sized to the always-on baseline rather than the peak. The cost of inaction is a quiet, recurring overpayment that compounds every billing cycle. When the downside of acting is a bounded commitment and the downside of waiting is unrecoverable overspend, the default should be to act.