The Azure discount you already paid for

Microsoft documents the failure mode itself

Azure Hybrid Benefit lets you apply Windows Server and SQL Server licences you already own, with active Software Assurance or a subscription, to workloads running in Azure. It is not a negotiation and it is not something you apply for. It is a setting, checked against a licence you have already bought.

In its own documentation on centrally managed Hybrid Benefit, Microsoft describes the problem plainly. Under the resource-level model, resource owners may select the benefit when no licences are available, or fail to select it when licences are available. Both are errors. The second one costs money quietly, every hour, and nothing in the portal raises its hand about it.

Windows Server is where it hides

Microsoft has built a central way to manage the benefit at subscription or billing account scope, where a billing administrator assigns licences once and Azure applies them hourly to whatever is running. That option covers SQL Server. For Windows Server, the resource-level model is still the only one available, which means somebody has to set the benefit on each virtual machine, at creation or afterwards.

Central management is also unavailable to organisations whose Azure is managed through a Cloud Solution Provider partner. So a large share of mid-market tenants sit on exactly the model Microsoft describes as error-prone, with no dashboard telling them which machines are paying full price for a licence they already hold.

The ratios decide whether it is worth claiming

The accounting is not one licence per machine. Microsoft normalises everything into normalized cores, and one SQL Server Enterprise core licence covers as much as four Standard core licences. A General Purpose SQL managed instance needs one normalized core per vCore. Business Critical needs four. SQL Server on a virtual machine carries a minimum of four vCores per machine regardless of how small the machine is.

Two exceptions catch people out. The benefit does not apply to the serverless compute tier of Azure SQL Database. And during a migration the same licences can count both on-premises and in Azure for up to 180 days, which is a window worth planning around rather than discovering after it closes.

The check runs in both directions

Finding the gap is unglamorous work. List every Windows Server virtual machine and every eligible SQL resource, compare that against the licences procurement actually holds, and look for the mismatch. Machines paying the undiscounted rate while a licence sits unused. And machines claiming a benefit nobody can produce a licence for.

The second direction matters as much as the first. An unbacked claim is not a saving. It is an audit exposure wearing a saving’s clothes.

Why it stays unfixed

This is not a hard problem. It is a boring one that sits between two teams. Procurement knows which licences exist. The engineers know what is running. Neither owns the reconciliation, so it does not happen, and the meter keeps running at the full rate.

That is the shape of most Azure waste. The finding is the easy part. The owner is the missing part. A recommendation with nobody’s name on it is a recommendation that survives comfortably into next quarter.