Buy Azure NetApp Files reserved capacity

This is one of the cleaner savings levers in Azure. The capacity is already running and already on the bill at the on-demand rate. Buying a reservation re-prices that same capacity at the discounted rate for the term, so the saving is the gap between the on-demand and reserved rates applied to the committed quantity, every hour, for one or three years. Microsoft does not publish a single headline percentage for Azure NetApp Files, and the actual discount depends on the service level, the unit size and the region, so quote the saving from the Azure pricing page and the purchase preview rather than a generic number. The direction is unambiguous: a longer term and the 1 PiB unit both earn a larger discount than a shorter term and the 100 TiB unit.

The commitment is the trade. You are agreeing to pay for a fixed amount of capacity for the whole term whether or not the workload keeps using it. That makes the finance question simple: how much capacity does this estate genuinely run all the time, with no plausible scenario where it drops below that floor? Reserve that floor, not your peak. Advisor sizes the recommendation from real usage over the look-back window, which is a good starting figure, but the finance partner owns the judgement about how durable that baseline is before signing a three year line.

The risk is bounded and the upside is committed. Capacity you use above the reservation simply bills at the on-demand rate as it does today, so over-running the reservation costs nothing extra. Under-running it, by reserving more than you keep online, is the only real waste, and even that is recoverable: reservations can be exchanged or refunded within Microsoft's published limits. The asymmetry favours acting, as long as the reserved quantity sits at or below the true floor.

Priya is the finance partner for the platform team and the Advisor recommendation lands flagged High impact. The instinct is not to approve the full headline quantity Advisor suggests on sight; it is to separate the durable baseline from the recent peak. The platform team confirms the Ultra pool under SAP HANA has held roughly 100 TiB of provisioned capacity for the past twelve months with no scenario in the roadmap where it drops below that, and the Premium log pool has held around 50 TiB. That steady floor is what is safe to commit. Any capacity above it stays on-demand and costs nothing extra against the reservation, so there is no penalty for sizing conservatively.

Priya then weighs term against flexibility. The three year reservation carries the deeper discount, but it locks the commitment for three years; the one year is a smaller saving for a shorter promise. For the HANA Ultra capacity, which underpins a system with no planned migration, Priya backs the three year term on the durable 100 TiB and keeps the more uncertain Premium capacity on a one year term. The saving is quoted from the purchase preview rather than a generic percentage, because the discount depends on service level, unit size and region. The finance pack reads: 'We commit the proven floor at the term that matches its durability, capacity above it stays on-demand, and the only recoverable downside, exchange or refund within limits, is well inside our risk tolerance.'

The cost model here is unusually favourable. The capacity is already running and already on the bill, so the reservation does not add new spend; it lowers the rate on existing spend. The only commitment is to keep paying for a baseline you were already paying for, at a discount, for the term. That makes the expected value strongly positive whenever the committed quantity sits at or below the durable floor, because capacity above the floor stays on-demand and the committed portion is recoverable through exchange or refund within Microsoft's published limits.

The figure that belongs on the savings backlog is the committed quantity at the durable baseline multiplied by the rate gap from the purchase preview, over the term, ranked alongside your other reservation and savings-plan opportunities. Do not quote a generic discount percentage: Microsoft does not publish one for Azure NetApp Files, and the real number depends on service level, unit size and region. Pull it from the Azure pricing page and the purchase preview, and let the 1 PiB unit and the three year term, both of which carry deeper discounts, inform where the largest, most durable baselines should commit hardest.

Azure NetApp Files is often the storage under the most important systems in the estate: SAP HANA, large file shares, virtual desktop profiles, line-of-business databases. That capacity runs continuously, so it is some of the most predictable spend you have. Paying the on-demand rate for predictable spend is leaving money on the table, and that is exactly what Advisor is flagging here as a high-impact savings opportunity.

The decision is a commitment, not a project. There is no migration, no downtime and no change to the workloads. You commit a baseline of capacity for one or three years and that capacity is billed at a lower rate. The only judgement leadership needs to back is that the committed baseline is genuinely durable for the length of the term, because a reservation is a financial commitment for the whole period.

Frame it as the storage equivalent of the reserved instance discounts you already take on compute. It is low-risk: capacity above the commitment still bills on-demand, and the commitment can be exchanged or refunded within limits if plans change. The return is a discount on spend you were always going to incur.

After a cost review surfaced that the company was paying full on-demand rates on a storage tier that had not changed size in a year, the CFO asked the obvious question: if it is that predictable, why are we not committing it for a discount the way we do with compute? The honest answer was that nobody had treated the Azure NetApp Files line as a candidate for reservation, even though Azure Advisor had been flagging it as a high-impact savings opportunity for months.

The team's response was to treat the recommendation as a finance decision rather than an engineering one. They confirmed the durable baseline of Ultra and Premium capacity that the SAP HANA landscape runs continuously, committed that floor on the term that matched how long they were confident it would hold, and left everything above the floor on the on-demand rate. No volume changed, no workload moved, and the next bill showed the same capacity at the reserved rate. The shift, from paying on-demand for storage that never changes to committing the proven baseline for a discount, is the one-line outcome this capability delivers, and it is reversible within limits if the plan changes.

This is the rare cost decision where the downside is small and bounded and the upside is committed. There is no project, no migration and no risk to the workloads, because nothing about them changes. The organisation simply commits a baseline of storage it already runs all the time, in exchange for a lower rate, for a term that matches how long that baseline will hold.

The cost of leaving it is quiet but real: every month the high-impact recommendation sits open, the company pays the full on-demand rate on storage that never changes. The cost of acting is a commitment that is reversible within limits. When the risk of inaction is steady overpayment and the cost of action is a recoverable commitment on proven spend, this is exactly the kind of saving leadership should approve quickly.