Cutting Azure waste: where the 40% actually hides

Almost every organisation we assess is overspending on Azure, typically by 30 to 40%. The striking thing isn't the number; it's how ordinary the causes are. Waste rarely comes from one dramatic mistake. It accumulates quietly, in resources nobody remembers switching on.

In short: Most Azure waste comes from four fixable sources: idle and orphaned resources, oversized always-on VMs, pay-as-you-go pricing on steady workloads that should sit on reserved instances or savings plans, and unclaimed discounts like Azure Hybrid Benefit. Start with Azure Advisor's cost recommendations and the Cost Management right-sizing data, act on the quick wins first, then put monitoring in place so the savings hold. Across our own client assessments that routinely recovers 30 to 40% of monthly spend without touching a single workload's performance.

That 30 to 40% figure is what we see repeatedly across our own client assessments, and it's consistent with the wider picture: Flexera's annual State of the Cloud research has for years put self-reported public cloud waste at around 30%, and Microsoft's own guidance is that most estates carry recoverable spend the moment they stop being actively watched. Here's where we consistently find it, and the approach we use to root it out for good.

Where does idle and orphaned spend hide?

Test environments spun up for a project that shipped months ago. Disks left behind when a VM was deleted. Public IPs reserved and never attached. Individually they're small; across an estate they add up to a meaningful monthly bill for nothing.

Why it persists: deleting a resource does not delete everything attached to it

The reason it persists is that deleting a resource in Azure doesn't always delete everything attached to it. Remove a virtual machine and its managed disks, network interface cards and reserved public IP addresses frequently stay behind, still billing. A standard public IP or a premium SSD disk left orphaned is a small, silent line item that no report flags unless someone goes looking.

• Audit for unattached managed disks, orphaned NICs and idle public IP addresses, which Azure Advisor now surfaces directly under its cost recommendations
• Flag resources with zero activity over the last 30 days, and check for old snapshots and manual backups that were never cleaned up
• Tag everything by owner, project and environment so nothing is anonymous, then use those tags in Cost Management to attribute every pound to something

How do you fix oversized, always-on compute?

VMs are routinely provisioned two or three sizes larger than the workload needs, then run 24/7 regardless of use. Right-sizing based on real utilisation, and scheduling non-production workloads to switch off overnight, is often the single biggest saving available.

The lever here is Azure Advisor's right-sizing recommendations, which read actual CPU and memory telemetry over a rolling window and tell you which VMs are consistently underused. A machine sitting at 5% CPU for a fortnight can usually drop a size or two, or shift to a burstable B-series SKU, with no user-visible impact. On top of that, non-production environments, dev, test, UAT, rarely need to run outside office hours. Auto-shutdown schedules or Start/Stop automation on those alone can cut their compute bill by roughly two-thirds, because you stop paying for the 128 hours a week nobody is using them.

Reserved instances or savings plans: which cuts more?

Pay-as-you-go pricing on predictable workloads is one of the most common, and most expensive, oversights. Anything with a steady baseline, domain controllers, line-of-business servers, production databases, is a candidate for a commitment-based discount, and the two main options work differently:

• Reserved instances commit you to a specific VM series in a specific region for one or three years, in exchange for discounts that can reach around 40% for one year and up to roughly 60% for three against pay-as-you-go. They give the deepest saving but the least flexibility, so they suit workloads whose size and location genuinely won't change.
• Savings plans commit you to an hourly spend figure rather than a specific machine, and apply that discount automatically across compute wherever it runs. The headline discount is usually a little lower than an equivalent reservation, but the flexibility means you keep saving even as workloads move or resize, which suits estates that still evolve.

The lever most often left switched off: Azure Hybrid Benefit

The other frequently missed lever is Azure Hybrid Benefit: if you already own Windows Server or SQL Server licences with Software Assurance, you can apply them to Azure VMs and stop paying for the licence a second time inside the compute rate. Stacked with a reservation, it's one of the largest single discounts available, and it's routinely left switched off. On the Microsoft 365 side, unused and over-specified licences are just as common, which is the other half of the Azure and licensing cost optimisation work we do.

What order should you tackle it in?

All of the above is worth doing, but not on the same day and not in whatever order it happens to occur to you. Sequencing by effort against saving means the easy work funds the attention the harder work needs:

The ordering matters more than it looks. The first three change nothing about how anything performs and need no negotiation with a workload owner, so they can usually be done inside a fortnight. Right-sizing sits fourth rather than first because a recommendation is only trustworthy once there is a rolling window of real telemetry behind it, and because each change wants a window agreed with whoever owns the workload.

Commitments come last of the actions for a specific reason: you should only buy one or three years of a workload once the estate underneath it has stopped moving. Buying a reservation for a VM you are about to right-size locks in the wrong size for the length of the term. Tagging sits at the bottom of the list, but it is the item that decides whether any of the rest is still true in six months.

How do you stop the waste coming back?

Finding waste once is easy. Keeping it out is the hard part, and it's where a managed approach earns its keep. The savings from a one-off clean-up erode within months as new resources get created, environments get cloned, and commitments quietly expire without anyone renewing or re-evaluating them.

What we put in place

We put continuous monitoring and anomaly detection in place using Azure Cost Management budgets and alerts, so an unexpected spike triggers a flag rather than a surprise at month-end. We review spend monthly against forecast, track reservation and savings-plan utilisation so you're not paying for commitments you've stopped using, and give you board-ready reporting so cost never drifts again.

If you'd like to know where your 40% is hiding, our free assessment is the fastest way to find out.