I went back through Microsoft’s refreshed cost optimisation guidance this week — the Well-Architected pillar, the FinOps toolkit updates, and the newer AI workload material. On the surface it reads like a tidy list of principles: plan, monitor, optimise, govern.

Read it a second time with an operator’s eye and something different comes through. The hardest problem in that document is not tagging, not rightsizing, not even AI token spend. It is reservations.

The Principles Look Tidy On Paper

Microsoft’s current framing is clean. Align cloud spend to business value. Build a cost-conscious culture. Use the right pricing model for each workload. Continuously optimise.

None of that is wrong. I have used the same language in steering committee decks more than once. The problem is that every principle in the list eventually lands on the same technical decision — how much of your estate do you commit to, for how long, and in what shape.

That is the reservation question. And in my experience it is where most Azure cost programmes quietly fall apart.

Why Reservations Are The Hinge Of The Whole Thing

Reservations and savings plans are the biggest single lever an Azure customer has. On compute alone, the difference between pay-as-you-go and a well-structured three-year commitment is often 40 to 60 percent of the bill.

That is not a rounding error. It is the difference between a cloud programme that survives the next budget cycle and one that gets hauled into a cost review.

The catch is that reservations reward conviction. You have to be willing to commit to a shape of workload — VM family, region, quantity — for one or three years, and pay for it whether you use it or not. Microsoft’s guidance treats this as a technical optimisation. In practice it is a forecasting problem dressed up as a purchasing decision.

What The Guidance Glosses Over

The documentation is careful and correct. It tells you to analyse usage, model scenarios, and match commitments to steady-state consumption. What it does not dwell on is how often the inputs to that analysis are wrong.

Most Azure estates I look at have three properties that make reservation planning hard. Workloads migrate across VM families as teams modernise. Regions shift as latency and data residency requirements change. And AI workloads now sit on top of the estate with a cost profile nobody forecasted two years ago.

Under those conditions, a reservation locked in today against last quarter’s consumption is often a bet against your own architecture roadmap. The principles document does not say that out loud, but anyone who has renewed a commitment and watched utilisation drift knows the feeling.

The Savings Plan Trap

Azure savings plans were meant to solve this. Commit to a dollar amount of compute per hour, and let Azure apply the discount flexibly across families and regions. On paper it is the answer to the flexibility problem.

In reality, savings plans solve one problem and introduce another. They smooth over VM family changes, but they also make it much easier to over-commit, because the commitment is expressed in dollars rather than shapes. I have seen organisations sign three-year savings plan commitments that looked comfortable on a spreadsheet and turned into a drag on the budget within twelve months.

The real discipline is not choosing between reservations and savings plans. It is running both with a rolling review cadence and being honest about the workloads underneath them.

What I Actually Do With Clients Now

When I work through cost optimisation with a team, the reservation conversation happens early and it happens in plain language. Three questions decide most of it.

How confident are we in the shape of this workload twelve months from now? If the answer is genuinely confident, a reservation is the right tool. If the answer is hopeful, a savings plan is safer. If the answer is honest and the shape is unknown, the right answer is to leave it on-demand and accept the premium until the estate stabilises.

What does the AI roadmap do to this forecast? Copilot rollouts, Azure OpenAI workloads, and agent platforms can move compute demand in directions that legacy forecasting models do not capture. Any reservation decision made without the AI team in the room is a decision made on stale data.

Who reviews this quarterly, and what are they allowed to change? Reservations are not a set-and-forget purchase. Without a named owner and the authority to exchange, cancel, or restructure commitments, the programme becomes a pile of past decisions nobody is tracking.

The Principle Underneath The Principles

Microsoft’s guidance lists cost optimisation as a continuous discipline. That is the sentence I would underline twice.

The failure mode I see most often is organisations that treat reservations as a once-a-year procurement event, then spend the next eleven months discovering the forecast was wrong. The technical principles in the documentation only work if there is an operating rhythm behind them.

Cloud cost optimisation in 2026 is not really about frameworks or toolkits. It is about whether someone in the organisation has the mandate, the data, and the authority to make commitment decisions every quarter — and to undo them when the evidence changes.

That is the real lesson sitting inside Microsoft’s principles post. The rest is scaffolding.