Five line items that inflate a mid-market Azure bill

Most mid-market Azure bills do not grow because someone made a bad decision. They grow because reasonable local decisions accumulate into a monthly number that no single person owns. A larger SKU to get through quarter close. A disk kept "just in case" after a migration. A log workspace created by a team that has since moved on.

That is the pattern worth looking for. Not waste in the moral sense, but cost without an owner.

Below are the five line items we see most often in a read-only review, ordered by how frequently they explain the gap between "the bill went up" and "we shipped more". All five are visible in the portal, and four you can check yourself this week.

1. Disks and snapshots that outlived their virtual machine

Deleting a VM does not delete its disks. The OS disk and the data disks remain, unattached, and Premium SSD storage is billed on the provisioned size rather than on the data actually stored. A decommissioned three-VM environment can leave several hundred gigabytes of provisioned Premium storage that nobody is watching, because it appears in the storage view and not in the compute view.

Snapshots compound it. Without a retention policy, chains from two years ago sit beside this month's. Their incremental nature makes each one look small, and the total does not.

How the charge is produced: default platform behaviour, no retention policy, and a migration declared finished before the cleanup was.

What to look at: unattached managed disks, and a snapshot inventory grouped by creation date.

2. SKUs sized for the peak and billed for the whole month

A VM chosen to survive month-end batch processing runs for every hour of the month, whether or not the batch is running. Billing follows the SKU, not the utilisation. If the load sits at 15% of provisioned capacity for 690 of those 720 hours, the invoice is still computed on 100%.

This is where right-sizing conversations usually go wrong. The answer is rarely "move everything down a size". It is a mix: burstable series for workloads that genuinely idle, reserved capacity for the ones that run constantly, and autoscaling for the tier that only matters during peaks. Each is a different instrument with a different risk profile. Choosing between them needs the percentile utilisation, not the average.

What to look at: P95 CPU and memory per VM over 30 days, next to the SKU you are paying for.

3. Networking that was never in the budget

Compute is the part everyone models. Networking is the part that appears afterwards.

• Cross-region egress. A service in one region talking to a database in another pays for the crossing on every call. Chatty applications make that expensive in a way no workload diagram shows.
• NAT Gateway hours. Billed per hour plus per gigabyte processed, and easy to leave provisioned per environment after the original need is gone.
• Private endpoints. Each one carries an hourly charge. Ten endpoints across three environments is a line item that did not exist two years ago.
• VPN and ExpressRoute gateways. Frequently sized once, for a migration, and never revisited.

None of these is a mistake. All of them are invisible until the bill is grouped by service.

What to look at: cost grouped by service, then by resource, for the networking services specifically.

4. Non-production environments on production settings

Development, staging and QA are usually cloned from production and never re-sized. Same SKU, same redundancy, same retention, same backup policy, for an environment that runs eight hours a day and serves no customers.

The mechanism is simple. Cloning is the safe way to build an environment, and re-sizing is a separate task that nobody owns. Redundancy is the expensive part, because zone-redundant and geo-redundant options multiply the compute and storage lines at the same time.

What to look at: subscriptions grouped by environment tag, with SKU and redundancy tier shown beside the production equivalent.

5. Licensing and telemetry

Two charges hide here.

The first is licensing. Windows Server and SQL Server carry a licence cost inside the VM price. When the organisation already owns Software Assurance or subscription licences with hybrid benefit available, that cost is paid twice until the benefit is applied. It is configuration, not architecture.

The second is telemetry. Log Analytics is billed on ingestion and on retention. A workspace given a generous daily cap during an incident, and never reset, keeps billing after the incident is closed. Verbose logging switched on to debug one evening is rarely switched off.

What to look at: hybrid benefit status per VM, and ingestion per workspace per day against the configured cap.

The one-hour review

Five steps, no tooling and no purchase:

1. Group cost by service for the last three months. Note the services that grew faster than usage.
2. Group by resource inside those services. Sort by cost and read the top twenty.
3. List unattached disks, and snapshots older than the retention policy.
4. Pull P95 CPU and memory for the ten most expensive VMs. Compare with the SKU.
5. Check hybrid benefit status, and the daily cap on every Log Analytics workspace.

What you are looking for is not one large mistake. It is four or five medium line items with no owner, which is exactly why they survived the last budget review.

If the review raises more questions than it answers, that is normal. The next step is a read-only assessment: we map the five drivers to your subscription, quantify each one, and leave you with the list whether or not you hire us.