Reserve App Service capacity for steady web apps

This is one of the cleanest savings levers in Azure because nothing about the workload changes. You are not re-architecting, downsizing or accepting any reduction in performance. You are telling Azure that a plan you already run every hour will keep running, and in exchange the matching hours bill at a lower rate for the term. The saving is the gap between the pay-as-you-go rate and the reserved rate, multiplied by every committed hour over one or three years.

The headline discount is meaningful but it varies by region, plan size and term, so treat any single percentage with caution and price your own SKU. Microsoft documents the three year P1v3 example in East US as falling from roughly the pay-as-you-go rate to well under half of it, with the one year term saving less and the three year term saving the most. The right framing for a finance pack is not a fixed percentage but a forecast: this many committed instances, at this region and size, saves this much per year against the current run rate.

The cost of acting is close to zero and the risk is bounded. There is no upfront re-platforming spend, and you can pay monthly rather than all upfront so the cash profile barely moves. The only real exposure is committing to capacity you later stop using, and Azure caps that downside with self-service exchange and refund, covered later in this lesson.

Priya is the finance partner reviewing the App Service line, which has grown into one of the larger compute items on the Azure bill. Azure Advisor's recommendation puts a number on the table, but she treats it as a starting point rather than an instruction. The recommendation engine looks at the last 7, 30 and 60 days of usage and proposes the quantity that maximises savings, defaulting to the three year price where it is offered. Her job is to confirm that the baseline it found is genuinely durable, not a temporary spike that happened to be running during the lookback window.

She asks the team to separate the always-on floor from the elastic top. The portal and API plans run a steady two P1v3 instances each, every hour, and have done for a year: that is four instances of confident, reservable baseline in East US. The batch plan scales between one and four instances on a schedule, so only its floor of one is safe to reserve and the rest should stay on demand to avoid paying for capacity that is often idle. The finance pack reads: 'Reserve four P1v3 in East US at three years, saving the gap between on-demand and reserved on every hour for the term; size the commitment to the floor we are certain of, keep the bursty top flexible, and pay monthly so the cash profile is unchanged.'

The arithmetic here is unusually favourable. For a plan that runs every hour of the year, the saving is the per-hour discount times roughly 8,760 hours times the number of committed instances, and it repeats for one or three years. There is no offsetting cost: no migration, no performance trade, no engineering effort beyond the purchase itself. Each unreserved always-on instance is a line where you are choosing to pay more than you have to for capacity you are certain to keep.

The discount varies by region, size and term, so the finance role is to price the actual SKU rather than quote a generic percentage. Microsoft's documented examples show the three year term saving the most and the one year term less, with the reserved P1v3 rate landing well below the on-demand rate. Build the forecast from the current run rate: committed instances times the priced discount times the hours in the term, paid monthly so the cash profile is unchanged. That number is the saving you are forgoing every month the recommendation sits unactioned.

Most production web applications run on the same plan size for years. Paying the on-demand rate for that capacity, hour after hour, is the equivalent of renting a building you intend to occupy for a decade on a nightly hotel rate. A reservation is the longer lease: the same space, a lower price, in exchange for a commitment you were already going to honour.

The leadership question is not 'should we run these apps?' It is 'are we paying the casual rate for capacity we have no intention of giving up?' Where the answer is yes, a reservation captures a guaranteed saving on spend that is already committed in practice, with no change to the service customers see.

This is a return-on-investment decision, not a risk one. The payback is immediate and continuous, the workload is untouched, and Azure provides an exit through exchange and refund if plans change. The only way to lose money is to commit to capacity you genuinely will not use, which is exactly what the recommendation and the usage data are there to prevent.

At a quarterly cost review the CFO asked why the App Service line was rising while traffic was flat. The honest answer was that the apps had been stable for over a year but were still billed at the casual, on-demand rate, because nobody had converted that proven, steady demand into a commitment. The capacity was as predictable as a payroll, yet it was priced as if it might disappear tomorrow.

The team's response was to stop treating reservations as an occasional, manual chore and start treating them as standard practice for any plan that has run unchanged for a quarter. They confirmed the always-on baseline against real usage, reserved it for three years where the discount was deepest, and left the genuinely elastic capacity on demand. The next quarter the App Service line dropped on the same traffic, and the saving was locked in for the term. The shift, from paying the casual rate for capacity the business will clearly keep, to pre-committing the proven floor and pocketing the discount, is the one-line return this capability delivers, and it asked nothing of the engineering roadmap.

Nearly every cost-optimisation programme has a layer of spend that is both large and entirely predictable, and for web-heavy estates the always-on App Service plans are exactly that layer. Leaving them on demand is a standing, recurring overpayment on capacity the business has already decided to keep. Reserving them captures a guaranteed return with no operational risk and no change to the customer experience.

The cost of acting is close to nothing: no upfront re-platforming, a monthly payment option that barely moves cash flow, and a documented exchange-and-refund path if plans change. The cost of not acting is a discount forgone every single hour. This is the rare class of decision where the upside is certain, the downside is bounded by Azure's own policy, and the action is a purchase rather than a project, which is exactly the trade leadership should approve fastest.