Azure FinOps: practical levers to cut your cloud bill

Azure bills rarely grow because of one bad decision. They grow by accumulation: a VM sized generously "for now", a staging environment running all weekend, a disk left behind after a migration, licences paid for twice. Each one looks trivial. Together they add up — and they come back unless something stops them.

This article walks through the levers that have the most impact on an Azure bill, then the governance loop that keeps the savings from eroding.

Before optimising: know who spends what

You can only reduce what you can attribute. The prerequisite for any FinOps effort is a cost breakdown the business can actually read:

• a mandatory tagging convention (application, environment, cost centre, owner), enforced by Azure Policy rather than left to goodwill;
• a subscription layout that mirrors ownership — one subscription per application or domain, production separated from non-production;
• Cost Management views shared with application owners, not just the cloud team.

Without that foundation, savings stay one-off and nobody feels accountable for the next overrun.

The levers, from quick wins to structural changes

The table below summarises the main levers. Effort is indicative and depends heavily on your current estate and team maturity.

Orphaned resources: the fastest win

After a few years of operations, nearly every platform holds resources nobody uses: managed disks detached from their VM, idle public IPs, old snapshots, gateways or App Service plans with no apps left. Azure Advisor flags some of them; an Azure Resource Graph query gives you a complete inventory across every subscription at once:

Resources
| where type =~ 'microsoft.compute/disks'
| where properties.diskState =~ 'Unattached'
| project name, resourceGroup, subscriptionId,
          sku = tostring(sku.name),
          sizeGb = toint(properties.diskSizeGB)
| order by sizeGb desc

Before deleting anything, find the owner (this is where tags pay off) and record the decision.

Shutting down non-production environments

A development environment used during office hours doesn't need to run at night or over the weekend. Scheduled VM shutdown, pausing services and scaling down outside working hours are easy to automate with Azure Automation, Logic Apps or your pipelines. The real work is organisational: agree the schedules with the teams and give them a simple way to start an environment on demand.

Also look at Azure Dev/Test pricing, available for non-production workloads of Visual Studio subscribers, which lowers the cost of several services.

Rightsizing: match size to actual usage

Resources are usually sized during the project, with headroom, and never revisited. Look at real utilisation — CPU, memory, IOPS — over a representative period of at least a few weeks, including month-end peaks, before downsizing a VM or a database tier. Azure Advisor recommendations are a good starting point; check them against what the application teams know.

Storage tiers

Not all data needs the same performance. Lifecycle management rules on storage accounts can move rarely accessed blobs to the cool, cold or archive tiers automatically, then delete them when they expire. Be careful, though: colder tiers charge for reads and early deletion, so the benefit depends on how the data is really accessed. The same reasoning applies to log and backup retention — align it with actual compliance needs, not default values.

Azure Hybrid Benefit

If you own Windows Server or SQL Server licences covered by Software Assurance (or eligible subscriptions), Azure Hybrid Benefit lets you avoid paying for the licence a second time inside the VM or SQL service price. It is often under-used simply because nobody has an inventory of the licences the company holds. Check entitlements carefully with whoever manages your licensing.

Reservations and savings plans

For steady workloads, Azure offers two commitment models over one or three years:

• Azure Reservations apply to a specific resource type — a VM family in a region, a database capacity — and give the deepest discount in exchange for less flexibility;
• Savings plans for compute commit to an hourly spend on compute, applied automatically across several services and regions. The discount is generally smaller, but the commitment survives architecture changes better.

Order matters: commit after cleaning up and rightsizing, not before, or you will lock in waste. Track commitment utilisation every month.

Making savings stick: the governance loop

A one-off optimisation project produces a visible drop, then the bill creeps back up. What makes the difference is a regular loop — light, but consistently run:

1. Inform: cost dashboards per application and per owner, shared monthly.
2. Optimise: review Advisor recommendations, orphaned resources and commitment utilisation.
3. Control: Cost Management budgets and alerts per subscription or application, with a warning threshold before the limit.
4. Prevent: Azure policies that enforce tags, restrict expensive SKUs outside production and block unapproved regions.

You don't need a dedicated team to run this. You need a named owner, a monthly slot in the calendar and a few simple metrics: cost per application, share of usage covered by commitments, cost of untagged resources.

In short

FinOps is not a one-off waste hunt; it is a discipline. Make costs readable first, take the quick wins (orphans, off-hours shutdown), rightsize, and only then commit to reservations or savings plans. Finally, put the loop in place that keeps the drift from coming back.

For a ballpark figure based on your current spend, try our FinOps estimator: it combines the levers you haven't activated yet and gives an indicative range. For an analysis based on your actual billing data, get in touch.