The Line Item That Isn't There: Finding Unlicensed Windows VMs in Azure

The most expensive word on your bill is one it never prints

Open your Azure invoice and search it for the word "Windows". On most subscriptions you will not find it.

That is not an oversight. Azure does not sell you a Windows Server license as a separate line. It sells you a virtual machine at an hourly rate, and if that VM runs Windows, the license is already inside the rate. A Linux D4s_v5 and a Windows D4s_v5 are the same silicon at two different prices, and the difference between the two prices is the license you may already own.

Azure Hybrid Benefit is the mechanism for telling Microsoft you own it. Flip a flag, and the licensing portion comes off the compute rate. It is one of the very few optimizations in cloud that requires no downtime, no resize, and no architectural change — you are not changing the machine, you are changing a billing attribute attached to it.

So why does anyone leave it off?

Because there is no feedback loop. An oversized VM shows up as low CPU on every dashboard you own. An unattached disk shows up as a resource with no parent. An unlicensed Windows VM shows up as… a VM. Correctly sized, healthy, fully utilized, running exactly as intended. The waste is not in the machine's behaviour. It is in a metadata field, and no cost report reads metadata fields.

Three values, and only one of them is money

The field is licenseType, returned by the Azure API on every VM. It has three values that matter, and the difference between them is the entire detection problem.

That third row is where naive detection goes wrong. Windows_Client is not an unlicensed machine. It is Azure Virtual Desktop, licensed through Microsoft 365 entitlements rather than through Windows Server Hybrid Benefit. There is nothing to enable and nothing to save. A rule written as "report every VM where licenseType is not Windows_Server" is a perfectly reasonable-looking rule, and it is wrong.

Here is the distribution across the twenty Windows VMs in the subscription we run this against:

Windows_Client  18
None             1
Windows_Server   1

The naive rule raises nineteen findings. Eighteen of them are false. The correct rule raises one.

This is the part of FinOps tooling nobody puts on a feature list: a detector's value is set by its false positive rate, not its recall. Nineteen findings, eighteen wrong, is worse than no detector at all — because a team that dismisses eighteen bad findings will dismiss the nineteenth too, and the nineteenth was the real one.

Our own rule found nothing for months

I want to be specific about our own failure here, because it is more instructive than the fix.

We shipped Azure Hybrid Benefit detection and it produced zero findings in production for months, while an eligible VM sat in the account the whole time. The rule ran. It logged no errors. It simply matched nothing, every time, and a detector that finds nothing looks exactly like a clean estate.

That is the failure mode worth internalising. A silent detector and a healthy account produce identical output. If you have a rule that has never fired, you do not have evidence that you are clean. You have no evidence at all.

Two separate defects combined to cause it.

The state field nobody fills in

The rule required a VM to be in state Running, which is an entirely sensible thing to require. You should not recommend a license change on a machine that is switched off.

The problem is that Azure Resource Graph does not report power state for most resource types. In our production data, 369 of 382 Azure rows carry a state of unknown — not stopped, not running, just absent. Requiring a positive Running reading therefore matched almost nothing, and in this case matched exactly nothing.

Worse, our own sync was making it harder. A dedicated VM sync collected real power states, and then a catch-all Resource Graph pass ran afterwards, had no power state to contribute, and overwrote the good value with unknown. We now refuse to downgrade a known state to unknown on write.

The rule was inverted to match. It now excludes a VM only when the provider positively reports it as stopped or gone. Ignorance no longer suppresses a finding — which is the right default, because the alternative is silence.

A capital R

The second defect is almost too dull to write down, which is exactly why it survived. The comparison was state === 'Running', case-sensitive, across the whole rule engine. AWS stores that same concept as running and RUNNING.

One capital letter, silently failing to match, across every rule that checked whether a resource was on. All state comparisons now go through a single shared helper instead of string equality.

The dollar floor is the real filter

If the rule no longer requires a running VM, what stops it recommending a license change on a deallocated machine?

Money. The rule ignores anything below $50/month of compute cost. A deallocated Azure VM bills close to nothing for compute — you keep paying for its disks, but the compute rate, which is the only thing Hybrid Benefit touches, drops away. So a deallocated VM falls under the floor on its own.

This turns out to be a better filter than the state check ever was, for a reason worth generalising: a cost threshold is evidence-based, and a state check is metadata-based. The cost is measured from billing data. The state is a field the provider may or may not have populated. When those two disagree, trust the money.

A rule that has never fired is not proof your estate is clean. It is proof you have no measurement. Those are very different things, and only one of them is good news.

What we actually found: one VM, $94.17

Here is the honest result, and it is small.

Across the Azure subscription we run this against, the rule produced exactly one finding: a VM named Management-Server-WOLF, with an estimated saving of $94.17 per month. That is the whole prize. One machine, out of twenty Windows VMs, worth about $1,100 a year — and by the time this went to publication, that gap had already been closed.

I am stating it that plainly on purpose, because the temptation in a post like this is to extrapolate. Twenty VMs, one hit, five percent — multiply by a big estate and quote a scary number. I am not going to do that, and you should be suspicious of anyone who does.

One finding is a sample size of one. It tells you the detector works. It tells you nothing whatsoever about what proportion of Windows VMs are typically unlicensed, in our estate or yours. A subscription running mostly Azure Virtual Desktop, like this one, is structurally unlikely to have many Hybrid Benefit opportunities — eighteen of its twenty Windows VMs are AVD, and AVD is licensed elsewhere. An estate of Windows Server application hosts could look completely different, in either direction.

Two more caveats that belong on the record:

• The saving is a model, not a quote. The figure applies the standard Windows Server Hybrid Benefit rate reduction to the VM's measured compute cost. It is an estimate, and the product labels it as one. Your actual reduction depends on region, VM size and Software Assurance terms.
• We do not verify that you own the license. This is the important one. Hybrid Benefit requires active Software Assurance or a qualifying subscription license, and no tool can confirm from the outside that you have one. We surface the technical opportunity. Whether you are entitled to take it is a licensing question for whoever owns your Microsoft agreement, and getting it wrong is an audit exposure, not a saving.

How to check this yourself in five minutes

You do not need us for this. If you have Azure CLI and read access, one command gets you the distribution:

az vm list --query "[].{name:name, license:licenseType, size:hardwareProfile.vmSize}" -o table

Read the output against the table above:

1. Count the None rows. Every one is a candidate. A null or missing licenseType on a Windows image means the same thing as None.
2. Ignore the Windows_Client rows entirely. Those are AVD. There is no Hybrid Benefit to apply.
3. Filter the candidates by cost, not by count. A $12/month B-series machine is not worth an entitlement conversation. Sort by size and start at the top.
4. Confirm entitlement before you flip anything. The flag is a billing attribute you can set in seconds; the license behind it is a contract.

If that command returns nothing but Windows_Client and Windows_Server, you are done, and you have something better than a clean dashboard — you have a measurement that came back clean.

The Bottom Line

Azure Hybrid Benefit is not a big lever. On the estate we measured it is worth $94.17 a month, and I would rather publish that number than a range with a "+" on the end of it.

The reason it is worth writing about is not the size of the prize. It is that this class of waste is structurally invisible. It does not move a utilization graph, it does not create an orphan resource, and it does not appear as its own line on the invoice. The only way to find it is to read a metadata field that no cost report reads, interpret three enum values correctly, and price the result against real billing data.

And the reason to be suspicious of your own tooling is that ours got all of that right and still returned nothing for months, because of a capital letter and an unpopulated field. The detector was not wrong. It was silent, and silence reads like good news.

Go and check whether your rules have ever fired. Not whether they are enabled — whether they have ever produced a row. That is a different query, and it is the one that tells you the truth.

For more on why averaged dashboards hide the findings that matter, see Why Your FinOps Dashboard Is Lying to You. For the governance side of cost ownership, read Orphan Spend: The Hidden 79% of Your Cloud Bill Nobody Owns. And for how cost data accuracy breaks down across providers, see Multi-Cloud Cost Management: Why Cost Accuracy Matters.