Buy Azure OpenAI provisioned throughput reservations

This is one of the cleanest savings levers in the Azure estate because it changes the price, not the workload. The provisioned deployment keeps running exactly as it did; the only thing that moves is the rate applied to its PTU meter. Microsoft documents that committing to a term reservation can save a meaningful share over the hourly pay-as-you-go rate, with the one-year commitment saving more than the one-month, so a deployment that is genuinely steady-state is paying list price for no reason once Advisor has flagged it.

The judgement is about commitment risk, not technical risk. A reservation is a term commitment: you are agreeing to pay for the reserved PTUs for the whole term whether or not you keep deploying them. The reservation does not guarantee capacity and is not tied to the deployment, so the finance question is confidence that the underlying workload will still be there in a month or a year. For a deployment that has run flat for months, a one-month reservation is close to risk-free and a one-year reservation trades flexibility for a deeper discount.

Frame the recommendation as recovering money you are already committed to spending. The PTUs are deployed and billing hourly today. The reservation simply re-prices them. The only cost of acting is the term commitment itself, which is bounded, exchangeable and refundable within documented limits, so the downside is small and the saving compounds every hour the deployment runs.

Priya is the finance partner for the AI platform. The Advisor recommendation lands with a headline saving for buying a reservation on the support-assistant deployment, and the instinct is not to approve the term commitment on the strength of a single estimate. The first question is whether the underlying workload is genuinely steady: the support assistant has been live and busy for months at a flat 100 provisioned units, so the usage that the discount depends on is real, not aspirational. The second question is the meter: the discount only lands if the reservation matches the deployment type, Global, and the scope where the deployment lives, so a reservation bought for the wrong type or scope would save nothing.

Priya separates the decision into two figures. The saving is the gap between what the 100 PTUs cost at the hourly rate today and what they would cost under the reservation, which Microsoft documents as a material discount that is deeper for the one-year term than the one-month. The risk is the commitment: a one-year reservation locks in the lower rate but obliges payment for the full term even if the assistant were retired, while a one-month reservation captures most of the discipline with almost no lock-in. The finance pack reads: 'The PTUs are already running and billing hourly. A one-year reservation captures the deepest documented saving on capacity we are confident persists; a one-month reservation is the near-risk-free option if we want to prove the saving before committing for a year. Either way we are re-pricing spend we have already made, not adding new spend.'

The savings model here is unusually clean. There is no engineering change, no migration and no risk to the workload; the reservation only re-prices a meter. The expected saving is calculable in advance: take the deployed PTUs, apply the documented reservation discount over the hourly rate, and that is the recurring saving for the term. Advisor does this estimate for you, and the deployed PTU count gives you the figure to sanity-check it against.

The cost of acting is the term commitment, and it is bounded rather than open-ended. A one-month reservation captures most of the discipline with almost no lock-in and is close to risk-free for any deployment that has run steadily. A one-year reservation captures the deepest discount in exchange for committing for the year, and even that is exchangeable for a different region, deployment type or term and refundable within documented limits. The finance role is to match the term to the confidence in the workload: short term where the future is uncertain, long term where the deployment is a settled production fixture, and to size every reservation to the PTUs actually deployed so none of the reserved capacity is wasted.

AI inference is becoming a material and growing line on the cloud bill, and provisioned throughput is the part of it that behaves like infrastructure: dedicated capacity, running continuously, sized for production. Paying the hourly on-demand rate for capacity you run 24x7 is the AI equivalent of renting servers by the hour and never signing a lease.

Azure Advisor surfaces exactly where that is happening and what the term commitment would save. The leadership question is not whether to use AI; it is whether the steady-state AI workloads are bought the way steady-state infrastructure should be: on a commitment that reflects how it is actually used. A reservation is a financial decision with no effect on the product, the model or the user experience.

The defensible position is that every provisioned deployment that has settled into steady production is covered by a right-sized reservation, the genuinely variable workloads stay on hourly billing on purpose, and the reservation portfolio is reviewed on a cadence rather than bought once and forgotten.

As the AI line on the Azure bill grew past the point of being a rounding error, the CFO asked the platform lead a simple question at the cost review: are we paying retail for any of this? The honest answer was that the production assistants ran on provisioned throughput billed by the hour, because that was how they had been deployed during the pilot, and nobody had revisited the billing model once they became permanent.

The team's response was to treat steady-state AI capacity the way they already treated steady-state compute. They listed every provisioned deployment, identified the ones that had run continuously for long enough to be confident in, and bought right-sized reservations against them for the deployment type and scope each one used, leaving the genuinely spiky and experimental workloads on hourly billing on purpose. They set a quarterly review to keep the reservation coverage matched to live deployments as models and traffic shifted. The next time the CFO asked the question, the answer had changed from 'we think so' to 'the steady workloads are on commitments that reflect how we run them, the variable ones are on demand by design, and we review the mix every quarter.' That shift, from paying hourly out of habit to pricing AI capacity by how it is actually used, is the saving this capability delivers.

As AI moves from pilot to production across the business, the capacity behind it stops being experimental spend and starts being infrastructure. Infrastructure that runs continuously should be bought on a commitment, and Azure Advisor now points to exactly where steady AI capacity is still being rented by the hour. The saving is a documented discount on spend you are already making, with no effect on the product, the model or the customer experience.

The decision leadership owns is the posture, not each purchase: that steady-state provisioned deployments are reserved, that the term reflects genuine confidence in the workload rather than wishful thinking, and that the reservation portfolio is reviewed on a cadence as the AI estate grows. This is the kind of optimisation that is invisible to users, compounds every month, and signals that the organisation runs its AI spend with the same discipline it applies to the rest of its cloud bill.