Notes

Azure cost: where the money actually goes in a small estate

Most Azure cost advice is written for estates with a FinOps team, a tagging mandate and a quarterly review meeting. This is not that. These notes are about the version of the problem where one person notices the bill went up, has no mandate to do anything about it, and has an afternoon.

At small scale the money is rarely where the dashboards point. Rightsizing recommendations assume a workload you plan to keep. Reserved instance suggestions assume you know what next year looks like. Neither helps with the actual shape of a small estate, which is: a handful of things running that should be, and a long tail of things running that nobody remembers creating.

What azure cost looks like when nobody owns it

Three patterns turn up in nearly every subscription I have been handed.

The first is resources that outlived their purpose. A disk detached during a migration in 2021. A public IP left behind when a load balancer was rebuilt. A snapshot taken "just in case" before a change that went fine. None of these are mistakes exactly. Each was a reasonable decision at the time, followed by nobody having a reason to revisit it.

The second is the demo that became permanent. A VM spun up for a customer presentation that happened once, in a resource group called rg-poc-2022, still running because switching it off requires being certain, and nobody is certain about anything they did not build.

The third is estimates that are wrong in a specific and consistent direction. Managed disks bill by provisioned tier rather than consumed gigabytes, so per-GB arithmetic understates them by a wide margin. Standard public IPs are not free, though the Basic ones were. Standard load balancers bill even with an empty backend pool. Each of these is a small trap, and together they mean a back-of-envelope figure is usually too low, which is the worse direction to be wrong in when you are asking someone for permission.

Cost figures as a prioritisation tool

A number good enough to rank twelve findings is not the same as a number good enough to bill a client. Reservations, savings plans, enterprise agreement discounts and Hybrid Benefit all move the real figure, and none of them are visible in the resource you are looking at.

So the framing that survives contact with a finance team is this: these figures tell you which thing to delete first, not what you will save. State the caveats before someone else finds them. An estimate presented as an estimate is useful. The same estimate presented as a saving is a hostage.

Doing it read-only

Every check in these notes is a read. That is partly caution and partly practicality: a script that can delete things needs a conversation before it runs, and a script that only looks does not. It also means the output is safe to run in a subscription you have just been given access to and do not yet understand.

The other half of that is failing loudly. A cost script that cannot reach Azure and prints "no findings" is worse than one that crashes, because it produces a clean report from an empty search. "Found nothing" and "could not look" need to be different outcomes, and the second one should exit non-zero so whatever scheduled it notices.

Reading order

Start with disk pricing, because the tier model is the single most common source of wrong numbers and everything else in this cluster assumes you already know it. Then work through the inventory of things nobody deletes. Idle VMs and snapshots are the two categories that need judgement rather than a query, and tagging is what stops the whole exercise being necessary again in a year.

Reporting comes last on purpose. There is no point formatting findings nicely until you trust them.