Why Is My Azure Bill So High? How to Find Out in Ten Minutes

Someone posted this on Microsoft's own Q&A forum:

"I got billed $2000 recently for Azure. I have used the services for years at a usual $200 to $300 bill. Now all of a sudden it is $2000. I need someone to contact me ASAP."

That is the real feeling when it happens. And then you open the portal to find out why, and you get a chart with a number on it and no answer in it.

I did the same thing on the other cloud. I let a second AWS account run for six months before I checked what was inside it. Different logo, same mistake. So take this as a list of the places the money actually hides, and how to go find yours.

Start with the machine you think is off

Azure virtual machines have two ways of being off, and only one of them is free.

If you shut a VM down from inside the operating system, the way you would shut down your laptop, Azure puts it in a state called Stopped. Microsoft's own billing table describes it like this: "The virtual machine is allocated on a host but not running... This state can be result of invoking the PowerOff API operation or invoking shutdown from within the guest OS."

The billing column next to that row says Billed.

The machine is still holding its slot on the physical host, so you are still paying for the machine. It is off to you and on to the invoice.

The state you actually want is Stopped (deallocated). The Stop button in the portal gives you that one. It hands the hardware back, and the compute charge ends.

The command line has the same trap sitting inside it, so watch this one. "az vm stop" powers the machine off and leaves it allocated, which means it carries on billing. "az vm deallocate" is the one that actually stops the charge.

Microsoft's own description of deallocate spells it out: "Deallocate a VM so that computing resources are no longer allocated (charges no longer apply). The status will change from Stopped to Stopped (Deallocated)." Two commands, nearly the same name, and only one of them saves you anything.

So go look at your VM list. Next to each one it either says "Stopped" or "Stopped (deallocated)". That one word in brackets is the whole difference. If you have a few machines sitting in plain Stopped because somebody logged in and shut them down properly, that is money you have been handing over every hour since.

Deallocated is not free either

There is a footnote under that same Microsoft table, and it is small enough to miss: "Some Azure resources, such as Disks and Networking continue to incur charges."

Your disk does not go away when the machine deallocates. It sits there, full size, full price, waiting for a machine that may never come back on. A premium SSD attached to a VM you stopped last quarter is still a monthly charge with your name on it.

Public IP addresses work the same way, and Microsoft is blunt about it on the pricing page: "you're charged for a static public IP address irrespective of the associated resource." Irrespective is the important word there. The address does not need to be attached to anything. It just needs to exist.

There is a second reason this one shows up on a lot of invoices right now. Basic SKU public IP addresses were retired on 30 September 2025. Anything that survived that had to move to Standard, and Standard costs more than Basic did. If your bill stepped up around then and never stepped back down, that is worth ten seconds of looking.

Half your invoice is not named after the thing you built

Go back to the person with the $2000 bill. When they listed out what they were being charged for, two lines stood out.

The first was a charge called "1-4 vCPU VM License" for $297.57. It was sitting on top of an A1-v2 virtual machine that cost $43.36. The license was almost seven times the price of the machine it was attached to.

Nothing went wrong there. That is simply how Azure bills. The machine and the software running on it are two separate charges. Pick a Windows image or a SQL Server image and you have bought two things, and only one of them is called a virtual machine on your invoice.

The second line was around $300 of Azure Bastion, which they described as being somehow added to some VMs. Bastion is the service that lets you connect to a machine through the browser without opening a port. It is genuinely useful. It also bills per hour, per host, the whole time it exists, whether you connect to anything or not.

So when you go looking, do not only look for resources you forgot. Look for charges you never recognized as resources in the first place.

How to find yours, in about ten minutes

In the portal, go to Cost Management, then Cost analysis. Open the Services view. This is the part most people never get past, so here is what to actually do once you are there.

Look at the Total at the top, and the small percentage next to it. That percentage is the change against the previous period, and it answers the first question you need answered: is this a spike or a climb? A spike is one thing that happened on one day. A climb is something you have been slowly adding to for months. Those are different problems and the hunt for each one looks different.

Now expand the biggest row. Services open up into products, and resources open up into meters. The meter is the real charge name, the one Azure uses in its own accounting. That is the level where "1-4 vCPU VM License" shows up as its own thing instead of hiding inside the word Compute.

Switch to the Resources view when you want to know which single thing is doing it, rather than which category. Then drill into that one resource and you will see every meter it carries.

If it is a spike, set the granularity to Daily. A spike has a start date. Find the date and then ask yourself what you changed that day, or who else has access and might have changed something. The date usually names the culprit faster than the chart does.

Before you close the tab, do two more things. Set a budget for what you expect to spend, and turn on an anomaly alert. Both are free, both live in Cost Management, and together they mean the next surprise reaches you in a few days instead of at the end of the month.

If it turned out to be a spike

A sudden jump almost always comes down to one of three things, and they are worth checking in this order.

A reservation ran out. Reserved instances are a one or three year commitment you make in exchange for a discount, and when the term ends the discount ends with it. Nothing breaks, nothing sends you a bill, the same machines just quietly go back to full price. If your spend jumped without anything being built, check the Reservations view first.

Something scaled up and never scaled back. Autoscale is good at adding capacity under load and much less reliable about giving it back, especially if the rule that removes instances is stricter than the rule that adds them. One busy afternoon can leave you paying for the afternoon forever.

Somebody built something and left it on. This is the most common one and the least interesting, and it is why the Daily view matters. Find the date the line went up, then find out who had access that day.

One more worth knowing about because it grows instead of spiking. Log Analytics bills you for every gigabyte you send it. Switch on diagnostics across a handful of resources and you have signed up for a charge that scales with how chatty your infrastructure is, which is not a number anybody estimates correctly in advance.

Why this takes longer than it should

None of this is hidden. Every number I just described is sitting in your portal right now, and Microsoft documents all of it openly.

The problem is the vocabulary. Azure bills you per meter, and the meter is named after the billing product rather than after the thing you made. You built "the staging box". The invoice says "1-4 vCPU VM License" and "Standard SSD Managed Disks" and Bastion host hours. The answer is in there, written in words you did not choose, spread across three screens.

That gap is the whole job, and the work is translation.

The shorter way

Do the ten minute version at least once. You will come out of it knowing your subscription better than any tool can explain it to you, and you will never look at a VM state the same way again.

If you would rather not do it every month, that is what we built Liberra for. It connects to your Azure subscription, reads your real spend through Cost Management, and keeps an index of what is actually in there, so when you ask why the bill is up it already knows your resources instead of spending fifteen minutes collecting them first.

For what to resize, it reads Azure Advisor, which is Microsoft's own recommender. Advisor watches your machines for longer than we could and publishes both the target size and the money saved, in whatever currency your subscription bills in. We show you what Microsoft already worked out rather than inventing a second opinion on top of it.

And it cannot delete anything. Not as a setting you could switch off... the delete commands are blocked in the code itself. Every change that writes waits for you to approve it first. Reads happen instantly, because reading cannot hurt you.

You ask in plain English, it answers in plain English, and the meter names stay where they belong.

Founder, Liberra AI