Cloud spend has moved from the status of a variable budget line to that of a major structural cost. For several years now, Flexera's annual surveys have ranked cloud cost optimisation as the number-one priority of the organisations surveyed, which estimate they waste around 30% of their spend. On the Azure side, Microsoft advertises discounts of up to 72% on a 3-year reservation versus pay-as-you-go, and up to 90% on Spot virtual machines: the gap between a managed footprint and an unmanaged one runs into millions of euros over three years for a mid-sized IT department.
This tension is worsening for two reasons. First, the Azure pricing grid has become combinatorial: reservations, compute savings plans, Spot, Azure Hybrid Benefit, Dev/Test rates and MCA/CSP contractual discounts partially overlap, and a poorly targeted commitment can remain under-used for thirty-six months. Second, the rise of data and AI workloads — GPUs, hot storage, inter-region traffic — shifts the cost base towards expensive, barely elastic resources that are poorly covered by the historical FinOps reflexes centred on the general-purpose VM.
The good news is that these levers can largely be mechanised. Reliable cost allocation (tags, management groups, billing scopes), rightsizing driven by real metrics and a commitment coverage built on the stable baseline — not on the peak — deliver quick wins without slowing product teams down. This document provides the end-to-end method: visibility model, rules for arbitrating between reservations, savings plans and Spot, quantified decision thresholds and governance rituals so that the savings achieved do not erode by the next quarter.
Why Azure FinOps Is Unavoidable
Azure FinOps is not a governance fad: it is the answer to three simultaneous dynamics — spend that has become structural, increasingly combinatorial pricing, and cost decisions taken by engineering teams. Here is why the subject can no longer wait for the next budget cycle.
The following sections detail the mechanics: real cost visibility, trade-offs between reservations, savings plans and Spot, rightsizing, then durable governance.
Visibility, Tagging and Allocation
On an ungoverned Azure bill, it is common for 20 to 40 % of spend to be attributable to no identified application: until that figure is close to zero, any optimisation remains a matter of opinion.
Freeze a short taxonomy — 5 to 6 tags maximum (owner, application, environment, cost centre, criticality) — make it mandatory through Azure Policy at resource group level, and base all your reporting on amortised cost, never on raw billed cost.
Reservations, Savings Plans and Spot
On a stable compute estate, committing to nothing structurally costs 30 to 60 % more than the price available: on Azure, on-demand is the most expensive rate in the catalogue.
Buying reservations before doing the rightsizing amounts to locking in your waste for three years. Rightsize first, stabilise for two to three months, commit afterwards — and never commit on the basis of a seasonal peak or a temporary pre-production environment.
Rightsizing, Elasticity and PaaS
By default, Azure Advisor surfaces no memory-based recommendation: without a collection agent configured, rightsizing relies on CPU alone and misses the essentials.
FinOps Governance and Culture
The FinOps Framework structures the approach into three iterative phases — Inform, Optimize, Operate — and the most frequent pitfall consists in trying to optimise before having informed.
Appoint a cost owner per product, not per infrastructure team: as long as cost does not appear in the backlog review of the product that generates it, it will remain someone else's problem.
Key takeaways
- Do you have a formalised tag taxonomy (5 to 6 keys maximum) enforced by Azure Policy at resource group level?
- Do your cost reports rely on amortised cost rather than raw billed cost?
- Have you configured memory metric collection to feed rightsizing recommendations?
- Have you stabilised your sizing for two to three months before any reservation or savings plan purchase?
- Do you track your coverage rate and the utilisation rate of existing commitments on a monthly basis?
- Is there a recurring ritual (monthly or per sprint) where costs are arbitrated with a named owner per application?
