Why Leaders Should Budget for Azure Provisioned Throughput

Finance teams know how to budget a token bill: it rises when usage rises and falls when it doesn't. Azure provisioned throughput breaks that habit. You rent a slab of model capacity by the hour, and the meter runs whether a single request arrives or not. Leaders should give it its own budget line and buy it without ending up with capacity nobody uses.

Azure provisioned throughput bills like a lease

A provisioned throughput unit (PTU) is a fixed slice of model processing capacity. When you create a provisioned deployment in Microsoft Foundry, Microsoft holds that capacity for you and bills the PTU count hourly, whether or not the deployment is handling requests.

Partial hours are prorated, and a resize changes the bill immediately. Provisioned deployments can't be paused: billing stops only when the deployment is deleted. A forgotten pilot is a standing charge.

PTU quota is shared, and capacity is not promised

Quota is granted per subscription, region and deployment type. Global, Data Zone and Regional Provisioned are separate pools, and within a pool quota is model-independent.

Quota costs nothing, but it is not capacity. If the region can't supply the PTUs when you deploy, the deployment fails. Scaling down or deleting releases capacity to the regional pool, with no guarantee you get it back.

Two budget consequences follow:

• One pool needs one owner. Two teams that each plan to "use our PTUs" are spending the same number.
• Don't plan to scale PTUs down overnight and up by day. Microsoft's guidance says not to, because the capacity may not be there when you return. Budget PTUs as a fixed cost.

Azure reservations for AI turn the lease into a discount

An Azure reservation commits you to a fixed number of PTUs for one month or one year, in return for a discounted effective hourly rate. The discount varies by model family and term, so read it from the Azure pricing pages, not a blog.

The rules a leader should know:

• Reservations match by deployment type, region (for Data Zone and Regional) and scope, not by model. A Global reservation doesn't cover a Regional deployment, but swapping models keeps the discount.
• PTUs beyond the reservation quantity are billed hourly. Reserved PTUs with no matching deployment are paid for anyway, which shows up as utilization below 100%.
• A reservation doesn't guarantee capacity. Create the deployments first, then buy.
• Cancelling or exchanging can incur fees, and the roles needed to buy differ from the roles needed to deploy, so check who holds them early.

Pilot provisioned throughput on hourly billing first

Microsoft names benchmarking before committing to a reservation as a proper use of hourly billing. So run a pilot with a date on it: size the deployment with the capacity calculator, deploy it, send production-shaped traffic for a fixed window, then delete it or reserve what you measured.

The decision comes down to three numbers:

# Rates come from the Azure pricing pages for your model family and deployment type.
hourly_rate = 0.0    # price per PTU per hour, hourly billing
reserved_rate = 0.0  # effective price per PTU per hour on a 1-month or 1-year term
ptus = 100           # from the Foundry capacity calculator
hours = 24 * 30

# Measured during the pilot, from your own logs
input_mtok, output_mtok = 0.0, 0.0    # millions of tokens per month
input_price, output_price = 0.0, 0.0  # price per million tokens on a Standard deployment

hourly_bill = hourly_rate * ptus * hours
reserved_bill = reserved_rate * ptus * hours  # owed even if no request arrives
per_token_bill = input_mtok * input_price + output_mtok * output_price

print(f'hourly={hourly_bill:.0f} reserved={reserved_bill:.0f} per_token={per_token_bill:.0f}')

The rates are zero on purpose, so fill them in from the pricing pages. If per_token_bill at real traffic comes out below reserved_bill, you aren't saving money. You're paying for guaranteed throughput, and the question is whether you need it.

The objection: idle capacity is wasted money

Sometimes it is. Microsoft's docs say Standard deployments remain the better fit for development, testing, low volume and highly variable traffic, and they suggest starting on Global Standard unless you have a reason to move.

But the objection assumes idle PTUs buy nothing. Standard is listed with no latency SLA, while Provisioned has a defined latency target per model. If a copilot or agent breaks when responses wobble, you're buying that predictability.

Spillover also softens bursts: for Azure OpenAI models it can route requests that get a 429 from a full provisioned deployment to a standard deployment in the same Foundry resource.

An idle-capacity line you planned for is a cost. One you discover in month three is an incident.

Take this step first

This week, name one owner for each PTU pool, confirm who can purchase reservations, and book a time-boxed hourly pilot with a delete date on the calendar. Reserve only what the pilot proves.

Production AI fails on surprises as often as on bugs, and a lease-shaped bill is one you can see coming only if someone budgeted for it.