Right-size underutilised App Service plans

This is the rare cost lever that pays back immediately and keeps paying. An App Service plan is billed per hour at its SKU rate, so the moment a plan steps down from, say, a P2V3 to a P1V3, the hourly rate roughly halves and the saving lands on the very next invoice. There is no migration project, no data copy, no licence to buy. The change is a single control-plane operation and the meter changes with it.

Frame each Advisor finding as a recurring saving rather than a one-off. A plan running a SKU one size too large is not a single wasted pound; it is that gap billed every hour, month after month, until someone resizes it. Multiply the monthly delta by twelve to see the annual figure, and the case usually makes itself: the only real cost of acting is the engineering time to confirm the load and run the resize.

The trade-off splits cleanly into two buckets. Most plans are a risk-free step down: the workload genuinely does not use the capacity, so a smaller SKU carries it with headroom to spare and the saving is pure. A minority are a judgement call: a plan that idles most of the week but spikes hard on a known schedule, where the right answer may be a smaller SKU plus autoscale rather than a flat downsize. Your job is to separate the free wins from the calls that need a second look, and bank the free wins first.

Priya is the finance partner working with the platform team on a creeping Azure bill. Advisor lists nine 'Right-size underutilized App Service plans' findings, each with a monthly saving attached. The instinct is not to celebrate the headline total; it is to turn it into a number the business recognises. Because an App Service plan is billed per hour at its SKU rate, every saving here is recurring: the partner annualises each finding by multiplying the monthly delta by twelve, and reframes the cluster as a standing reduction to the run rate rather than a one-time rebate.

Priya then sorts the findings into two columns. The largest, api-prod-plan running a P2V3 across three workers at low CPU, is a clear risk-free step down: the workload does not use the capacity, so a smaller SKU keeps it running with headroom and the saving is clean. A couple of staging plans are even simpler, idle outside office hours and safe to shrink or schedule. One plan is a judgement call: it idles most of the week but spikes every Monday morning on a reporting run, where the right move is a smaller SKU plus autoscale rather than a flat downsize. The finance pack reads: 'Seven plans step down at no risk for an annualised saving banked on the next invoice; one needs autoscale instead of permanent headroom; nothing here requires a migration or a new purchase, only engineering time to confirm the load.'

The cost model here is unusually clean. The saving from a step-down is recurring and lands immediately: an App Service plan is billed per hour at its SKU rate, so a smaller SKU shows up as a lower line on the very next invoice and every invoice after. There is no migration, no data copy and no purchase, so the only cost of acting is the engineering time to confirm the load and run the resize.

Annualise to see the real number. A plan running one size too large might look like a modest monthly figure, but multiplied across twelve months and several plans and environments it is a material standing cost. The finance role is to take Advisor's per-plan savings, total and annualise them, separate the risk-free step-downs from the spiky plans that need autoscale, and track the banked saving as a reduction to the run rate rather than letting the findings sit unworked while the meter keeps running.

App Service is one of the most common places a cloud bill quietly inflates, because the plan is sized once, at launch, and rarely revisited. Azure itself flags the waste: Advisor watches each plan's CPU and tells you, plan by plan, where a cheaper SKU would carry the same load. The report shows this as a list of named plans with a measured saving against each.

The leadership question is not 'are we overspending today?' It is 'do we have a routine that turns measured under-utilisation into a smaller bill, or does waste accumulate until someone happens to look?' The defensible end state is that right-sizing is a standing review, not a one-off cleanup: Advisor's App Service findings are worked every cycle, the risk-free step-downs are taken, and the spiky plans are handled with autoscale rather than permanent headroom.

This is purely a savings decision with very little downside. Resizing a plan is reversible in minutes, so the cost of getting a step-down slightly wrong is small and recoverable, while the cost of never looking is real money billed every hour. It is the kind of low-risk, recurring saving leadership should want made routine rather than heroic.

After a quarter where the cloud bill rose faster than revenue, the CFO asked the obvious question at the review: are we paying for capacity we actually use? For App Service the honest answer at the time was uncertain, because plans had been sized at launch and never revisited, and nobody owned the job of checking whether the SKU still matched the load.

The team's response was to stop treating right-sizing as a one-off cleanup and start treating it as a routine. They put Azure Advisor's App Service cost findings on a standing cadence, took the risk-free step-downs each cycle, moved the one genuinely spiky plan onto autoscale so it pays for the peak only when the peak happens, and earmarked the steady production plans for a reserved-instance commitment to lock in a further discount on capacity they know they will keep. The next time the CFO asked, the answer had changed from 'we think so' to 'every plan is checked against its measured CPU each cycle, the over-sized ones have been stepped down, and the saving is on the run rate.' That shift, from sizing once and hoping to sizing continuously against evidence, is the confidence signal this capability delivers, and it lowers the bill rather than raising it.

Almost every cloud bill carries a layer of App Service over-provisioning that nobody decided to incur: plans sized at launch, cloned at scale, or bumped up for an event and never brought back down. Advisor measures it for you and names the plans, which turns a vague sense of overspend into a concrete, prioritised list with a saving against each line.

The saving is real and recurring while the cost of acting is small and the risk is low, because a resize is reversible in minutes. This is the rare class of cost work where there is no meaningful downside to acting and a measurable downside to inaction, which is exactly the kind of saving leadership should make routine rather than occasional.