Azure cost optimisation is the practical work of making sure every pound on your Azure invoice buys something the business actually needs. It is not a one-off cleanup and it is not a licensing negotiation. It is a repeatable checklist of decisions about size, schedule, commitment, tier and ownership, applied to a live estate that changes every week.
Most organisations do not overspend on Azure because they made one bad choice. They overspend because a hundred small defaults went unchallenged: a virtual machine sized for a spike that never came back, a test environment nobody switched off, three years of snapshots, a logging workspace ingesting everything at the analytics rate. Each is defensible on its own. Together they routinely add a third to the bill, and every one of them sits on the Azure cost optimisation checklist below.
This Azure cost optimisation checklist walks through the whole estate in the order that pays best: find the waste, fix the compute, buy the commitments, tier the storage, tidy the quiet line items, then put tagging, budgets and a review cadence in place so the savings do not quietly reverse. It is written for a business running Azure without a dedicated FinOps team, alongside our wider cloud adoption work and the Azure landing zone implementation checklist that sets the guardrails up front.
Table of contents
- What Azure cost optimisation actually means for a UK business
- Where the money leaks in an unoptimised Azure estate
- The compute checklist: rightsizing, schedules and autoscaling
- Commitments and licensing: the biggest Azure cost optimisation lever
- The storage and data checklist for Azure cost optimisation
- Networking, monitoring and PaaS: the quiet line items
- Tagging and visibility: the foundation of Azure cost optimisation
- Budgets, alerts and anomaly detection that keep spend honest
- What Azure cost optimisation costs to run and what it returns
- A 90-day Azure cost optimisation plan for a small IT team
- Mistakes that quietly undo Azure cost optimisation
- Frequently asked questions about Azure cost optimisation
- References
What Azure cost optimisation actually means for a UK business
Azure cost optimisation gets confused with cost cutting, and the two are not the same thing. Cutting means spending less. Optimising means spending correctly, which sometimes means spending more on one workload so you can spend far less on four others.
It is an engineering discipline, not a finance exercise
The decisions that move an Azure bill are engineering decisions: instance family, disk type, retention period, autoscale rule, region. Finance can report the number and challenge it, but nobody in finance can safely resize a production database. Effective Azure cost optimisation puts the recommendation in front of the person who owns the workload, with enough context that they can say yes or no in minutes.
The three levers, in the order they pay
Every saving in Azure cost optimisation comes from one of three levers. Use less — turn things off, shrink them, delete them. Pay less for what you use — reservations, savings plans, Hybrid Benefit, Spot. Change the shape — move from always-on infrastructure to serverless, consumption or auto-pausing services. Work them in that order, because buying a three-year commitment on an oversized virtual machine locks the waste in rather than removing it.
Optimised does not mean cheapest
A cheaper configuration that breaches your recovery time objective is not optimised, it is a liability with a lower invoice. Azure cost optimisation is always bounded by performance, resilience and compliance requirements that you write down first. If nobody has agreed what “acceptable” looks like for a workload, any resizing conversation stalls on fear.
What good looks like after ninety days
A mature estate has no unattached disks, no unattached public IP addresses, no permanently idle virtual machines, at least 70% of steady-state compute covered by a commitment, storage on lifecycle policies, every resource carrying an owner tag, and a monthly review where the top five cost movements each have a named explanation. That is an achievable Azure cost optimisation standard for a team of two or three, not a large programme.
Where the money leaks in an unoptimised Azure estate
Before you optimise anything, find out where the money is going. Every Azure cost optimisation review starts with measurement rather than action. Azure Cost Management’s cost analysis view, grouped by resource group and then by meter category, will usually tell you the story in twenty minutes.
The seven usual suspects
Across the estates we review, the same seven categories account for almost all the spend an Azure cost optimisation pass can recover: oversized compute, resources that are idle or orphaned, missed commitment discounts, storage sitting on the wrong tier, snapshots and backups nobody prunes, logging and monitoring ingestion, and non-production environments running twenty-four hours a day for a team that works forty.
A first-pass triage table
The table below is the triage sheet we use on day one of an Azure cost optimisation review. Work top to bottom; the earlier rows are both larger and easier.
| Waste category | Typical symptom | Where to check first | Effort to fix |
|---|---|---|---|
| Orphaned resources | Unattached disks, idle public IPs, empty App Service plans | Azure Advisor cost recommendations | Low |
| Non-production always on | Dev and test VMs running at 3am | Cost analysis filtered by environment tag | Low |
| Oversized compute | CPU under 15% for a fortnight | Azure Monitor metrics, Advisor rightsizing | Medium |
| No commitment coverage | Steady workloads billed at pay-as-you-go | Cost Management reservation recommendations | Medium |
| Storage on the wrong tier | Cold archives sitting in the hot tier | Storage account insights, blob inventory | Medium |
| Snapshot and backup sprawl | Years of snapshots, no retention rule | Disks and Recovery Services vault | Low |
| Log ingestion overspend | Verbose diagnostics at the analytics rate | Log Analytics usage and estimated costs | Medium |
What the split usually looks like
The chart below shows how recoverable spend typically distributes across those categories on an estate that has never had an Azure cost optimisation pass. The headline is that compute sizing and idle resources together dominate, which is why the compute checklist comes first.
Do the triage before you touch anything
Resist the urge to fix the first thing you find. An hour spent building the triage list means the changes land in value order, and it gives you a baseline to measure the programme against later. Without a baseline, nobody can prove the Azure cost optimisation work paid for itself.
The compute checklist: rightsizing, schedules and autoscaling
Compute is the largest line on most Azure bills, which makes it the first substantive stop on the Azure cost optimisation checklist and the one with the most defaults left untouched. Three questions cover it: is it the right size, does it need to run all the time, and does it need to be a virtual machine at all.
Rightsize against a fortnight of real metrics
Pull fourteen days of CPU, memory and disk metrics from Azure Monitor before resizing anything. A machine averaging under 15% CPU with peaks below 40% is usually two sizes too large. Azure Advisor surfaces these automatically, but it only looks at CPU and network by default, so enable memory metrics through the Azure Monitor agent or you will miss memory-bound workloads and resize them into trouble. Rightsizing on a single day of data is the fastest way to lose trust in an Azure cost optimisation programme.
Move to newer VM series while you are there
Newer virtual machine generations frequently deliver more performance per pound than the series they replace. Migrating from an older D-series to the current generation often gives the same throughput on a smaller size, which compounds with any commitment discount you buy afterwards. Check the regional availability first; not every series exists in UK South and UK West.
Shut down what nobody uses overnight
A development virtual machine that runs 45 hours a week instead of 168 costs 73% less. Azure has native auto-shutdown on virtual machines, and Automation runbooks or Logic Apps can handle start and stop schedules across a tagged group. This is the single highest-return change in most Azure cost optimisation programmes because it is reversible, low risk and needs no application change.
Use autoscale rules rather than peak-sized fleets
Scale sets, App Service plans and AKS node pools all support autoscaling on schedule or metric. Sizing a fleet for Black Friday and running it that way in February is the most expensive form of capacity planning there is. Set a sensible floor, a hard ceiling and a cooldown period so scaling events do not thrash. Autoscaling is the rare form of Azure cost optimisation that keeps working while everyone is asleep.
Consider Spot for anything interruptible
Spot virtual machines can run at up to 90% below pay-as-you-go rates in exchange for eviction at thirty seconds’ notice. Batch processing, CI build agents, rendering and non-critical AKS node pools are natural fits. Never put a database or a customer-facing tier on Spot, and always set an eviction policy your workload can survive.
Right-size the database tier too
Azure SQL Database serverless auto-pauses after a configurable idle period and bills compute per second, which suits development and intermittently used line-of-business databases. Elastic pools help when you run many small databases with staggered peaks. Both are structural changes that beat any amount of tuning at the margins, and both survive the next Azure cost optimisation review because the saving is built into the service model rather than into a setting somebody can undo.
Commitments and licensing: the biggest Azure cost optimisation lever
Once workloads are the right size and on the right schedule, buy the discount. This is where the largest single percentage reductions in Azure cost optimisation live, and where mistakes are hardest to unwind, so sequence matters.
Reservations versus savings plans
Reserved instances commit you to a specific virtual machine series in a specific region for one or three years and pay the deepest discount — Microsoft quotes up to 72% against pay-as-you-go for a three-year term. Azure savings plans for compute commit you to an hourly spend figure instead, apply across series, regions and several compute services, and quote up to 65%. Reservations pay more; savings plans forgive more change.
The commitment comparison
| Purchase option | Indicative discount | Commitment | Flexibility | Best for |
|---|---|---|---|---|
| Pay-as-you-go | Baseline | None | Total | Spiky or short-lived workloads |
| Savings plan, 1 year | Moderate | Hourly spend, 1 year | Across series and regions | Estates still changing shape |
| Savings plan, 3 year | Up to 65% | Hourly spend, 3 years | Across series and regions | Stable total spend, moving mix |
| Reservation, 1 year | Around 40% | Specific SKU, 1 year | Exchange within family | Known steady workloads |
| Reservation, 3 year | Up to 72% | Specific SKU, 3 years | Exchange within family | Long-lived production estate |
| Spot virtual machines | Up to 90% | None | Evictable at 30s notice | Batch, build agents, rendering |
Claim Azure Hybrid Benefit if you already own the licences
If you hold Windows Server or SQL Server licences with active Software Assurance, Azure Hybrid Benefit lets you apply them to Azure virtual machines and pay compute-only rates. Microsoft quotes savings of up to 40% on Windows Server and up to 85% on SQL Server when Hybrid Benefit is stacked with a three-year reservation. It is a checkbox on the resource, it is routinely left unticked, and it is the cheapest Azure cost optimisation win available to any organisation with an on-premises licensing history.
Cover the steady base, not the peak
Buy commitments to cover the trough of your usage curve, not the average and never the peak. A commitment that goes unused is worse than no commitment at all. Seventy per cent coverage of steady-state compute is a healthy target for a first Azure cost optimisation cycle; you can top up next quarter once the utilisation reports confirm the first tranche is fully consumed.
Watch the discount depth by option
Track utilisation monthly and set auto-renew deliberately
Reservation utilisation reports in Cost Management show whether you are consuming what you bought. Anything below 95% utilisation needs an explanation, and anything below 80% needs an exchange. Decide auto-renew consciously at purchase; a reservation that silently rolls over for another three years on a decommissioned workload is an expensive kind of forgetting. Put the utilisation check in the same monthly slot as the rest of your Azure cost optimisation review.
The storage and data checklist for Azure cost optimisation
Storage rarely looks alarming on a monthly invoice, which is exactly why it grows unchecked. It also carries the most avoidable spend per hour of Azure cost optimisation effort, because tiering and lifecycle rules are set once and then work forever.
Tier blob storage by access pattern
Azure Blob Storage offers hot, cool, cold and archive tiers with progressively lower storage costs and progressively higher access costs and minimum retention periods. Data older than thirty days that nobody reads should not be in the hot tier. Data nobody has opened in a year probably belongs in archive.
Storage tier comparison
| Tier | Storage cost | Access cost | Minimum retention | Suits |
|---|---|---|---|---|
| Hot | Highest | Lowest | None | Active application data |
| Cool | Lower | Higher | 30 days | Monthly reporting sets |
| Cold | Lower still | Higher still | 90 days | Quarterly or annual data |
| Archive | Lowest | Highest, rehydration needed | 180 days | Compliance retention |
Automate tiering with lifecycle management policies
Do not tier by hand. A lifecycle management policy on the storage account moves blobs between tiers on access age and deletes them at end of life, with no ongoing effort. Write the policy to match your retention schedule, then test it against a copy before enabling it on production containers. Policy-driven tiering is Azure cost optimisation that does not depend on anybody remembering it.
Delete unattached disks and prune snapshots
A managed disk bills whether or not it is attached to anything, and deleting a virtual machine does not always delete its data disks. Snapshots are worse: they are incremental, cheap individually and never expire on their own. Both show up in Azure Advisor, and clearing them is usually the first visible win of an Azure cost optimisation project.
Match disk performance to actual IOPS
Premium SSD is the default choice for production and it is frequently three times the disk anyone needs. Check the IOPS and throughput figures in Azure Monitor before renewing that assumption. Premium SSD v2 decouples capacity from performance, so you can buy the size you need and dial the IOPS separately rather than paying for a larger disk to reach a performance tier.
Review backup retention against the actual policy
Recovery Services vault retention often defaults to values nobody chose, and long-term retention points accumulate quietly. Align the retention schedule to the recovery point objectives your business actually agreed, which may be shorter than the default for non-critical systems and longer for the two or three that matter. Backup is the line item most often left outside the scope of an Azure cost optimisation exercise, and it compounds every month.
Networking, monitoring and PaaS: the quiet line items
The remaining Azure cost optimisation categories are individually small and collectively significant. They are also where a bill grows without anybody deploying anything new.
Outbound data transfer and cross-zone traffic
Inbound data is free; outbound is not, beyond the first 100 GB each month. Chatty architectures that cross availability zones or regions for every call turn a design decision into a recurring charge. Keep talkative components in the same zone, and check whether a private endpoint or service endpoint changes the traffic path in your favour.
Idle public IPs, gateways and load balancers
Standard public IP addresses bill hourly whether attached or not. NAT gateways, application gateways, VPN gateways and load balancers all carry an hourly charge that continues long after the project they were built for ended. Sweep them quarterly as part of the Azure cost optimisation cycle; they never appear in a compute rightsizing report.
Log Analytics ingestion is a real budget line
Log Analytics bills per gigabyte ingested and again for retention beyond the free period. Verbose diagnostic settings on chatty resources can dwarf the compute they monitor. Route high-volume, low-query data to the basic or auxiliary log plans, set table-level retention, and consider a commitment tier once daily ingestion is predictable.
Consolidate App Service plans
You pay for an App Service plan, not for the apps on it. An estate that spawned one plan per app is paying for idle capacity many times over. Consolidating low-traffic sites onto shared plans, and deleting plans left behind by deleted apps, is quick and safe.
Tune AKS before you blame Kubernetes
Kubernetes clusters hide cost behind an abstraction. Enable the cluster autoscaler, set realistic requests and limits so the scheduler can pack nodes properly, use Spot node pools for interruptible workloads, and stop non-production clusters overnight. Node pools sized for a worst case that never arrives are the AKS equivalent of an oversized virtual machine. Kubernetes does not make Azure cost optimisation impossible, it just moves the controls one layer down.
Tagging and visibility: the foundation of Azure cost optimisation
None of the above survives contact with a growing estate unless you can answer one question on demand: who owns this resource and what is it for? That is a tagging problem, and it is the foundation the rest of the Azure cost optimisation programme stands on.
Agree a small, mandatory tag set
Four or five tags beat twenty. Owner, environment, cost centre, application and, if you bill clients, customer. Define the allowed values as a closed list — free-text tags drift within a fortnight and destroy the reports you built them for. A tag set nobody can remember produces numbers nobody trusts, and Azure cost optimisation stalls there.
Enforce tags with Azure Policy, not with goodwill
Azure Policy can require a tag on resource creation, deny deployments without it, and inherit tags from the resource group. Enforcement at deployment time is the only approach that holds, because retrofitting tags across a running estate is slow, manual work that nobody volunteers for twice.
Use subscription and resource group structure as a second axis
Scopes are the strongest allocation lever Azure gives you. Management groups, subscriptions and resource groups slice cost with no tagging effort at all, which is why the landing zone design matters so much. If production, development and each major workload sit in their own subscriptions, half your reporting problem disappears before you write a single tag policy.
Publish the numbers to the people who cause them
A cost report nobody sees changes nothing, and Azure cost optimisation is ultimately a change in behaviour rather than a change in settings. Scheduled exports from Cost Management, or a shared dashboard filtered by owner tag, put the figure in front of the team that can act on it. This is the showback step, and it connects directly to cloud cost allocation and chargeback, which is the same discipline applied across every cloud you run.
Budgets, alerts and anomaly detection that keep spend honest
Azure cost optimisation without guardrails decays. Within two quarters, an unmonitored estate drifts back towards its old shape, because every individual deployment decision is small and nobody is watching the aggregate.
Set budgets at the scope that has an owner
Create budgets in Cost Management at subscription or resource group level, wherever a named person is accountable. Budgets do not stop spending; they raise alerts at percentage thresholds, and those alerts need to reach the owner rather than a shared inbox nobody reads.
Turn on anomaly detection and act on it
Azure’s cost anomaly detection flags unusual daily spend patterns against your own history and can email a subscription owner automatically. A doubled bill caught on day two costs a fraction of the same mistake found in next month’s invoice. Treat every anomaly alert like a cybersecurity alert: triage it, explain it, and close it with a note.
Give engineers a preview before deployment
The Azure pricing calculator and cost estimates in the portal let a team see the monthly figure before they click create. Making that a normal step in the deployment review catches the expensive default while it is still free to change.
Guardrails belong in the landing zone
Policy-driven guardrails — allowed SKUs, allowed regions, mandatory tags, deny rules for expensive services nobody has approved — stop the next generation of waste from ever existing. Retrofitting them is possible; building them into the landing zone is far cheaper and makes every future Azure cost optimisation cycle shorter. It is a core part of any managed cloud adoption engagement.
What Azure cost optimisation costs to run and what it returns
Every Azure cost optimisation programme has a cost of its own: people’s time, sometimes tooling, and occasionally a short performance risk. It is worth being honest about the arithmetic before you promise a number to the board.
The realistic setup effort
For an estate of a few hundred resources, expect roughly five to eight days of engineering effort for the first full Azure cost optimisation pass: two days of analysis and triage, two to three days of remediation, one day agreeing the tag standard and writing the policies, and a day building the reporting. Larger estates scale sub-linearly because the same policies cover more resources.
The ongoing running cost
After the first pass, budget half a day a month for the review and perhaps a day a quarter for the commitment cycle. That is the honest steady-state cost of Azure cost optimisation for a small team, and it is the number to protect when things get busy, because it is the part everyone skips.
A worked example
Take a business spending £12,000 a month on Azure. A first pass that removes £900 of orphaned resources, saves £1,100 by scheduling non-production, recovers £1,400 through rightsizing and £1,900 through commitments and Hybrid Benefit lands at roughly £5,300 a month, or 44%. Even at half that outcome, the eight days of effort repay themselves inside the first month.
Savings arrive in waves, not all at once
When a third-party platform earns its fee
Native tooling covers most of what a small estate needs. A third-party FinOps platform earns its subscription when you run several clouds, need per-customer unit economics, or want automated rightsizing with approval workflows. Below roughly £20,000 a month of cloud spend, the licence usually costs more than the extra savings it finds. For a single-subscription estate, native Azure cost optimisation tooling is genuinely enough.
Native tooling versus a FinOps platform
| Capability | Azure native tooling | Third-party platform |
|---|---|---|
| Cost analysis and reporting | Included, Azure only | Included, multi-cloud |
| Rightsizing recommendations | Azure Advisor, CPU-led | Multi-metric, often automated |
| Commitment planning | Built-in recommendations | Portfolio modelling across providers |
| Chargeback and showback | Exports plus your own reporting | Packaged, with unit economics |
| Cost to run | Free, your team’s time | Percentage of spend or per-seat fee |
A 90-day Azure cost optimisation plan for a small IT team
A plan beats a list. This is the Azure cost optimisation sequence we run, compressed into thirteen weeks, and it assumes one engineer part-time rather than a dedicated team.
Days 1 to 10: measure and triage
Export three months of cost data, group it by resource group and meter, and build the triage table from the earlier section. Agree the performance and availability constraints for the top ten workloads so nobody has to guess later. Do not change anything yet.
Days 11 to 25: harvest the free wins
Delete unattached disks, unused public IPs, empty App Service plans and orphaned load balancers. Apply auto-shutdown schedules to every non-production virtual machine. These changes are reversible, need no architectural review, and typically fund the rest of the Azure cost optimisation programme on their own.
Days 26 to 45: rightsize with evidence
Work the rightsizing list one workload at a time, with the owner’s agreement and a rollback plan. Resize during a maintenance window, watch it for a week, then move on. Resist the temptation to batch fifty resizes into one evening; the one that misbehaves will cost you the credibility you need for the commitment conversation.
Days 46 to 65: buy the commitments
Only now, with the estate at its steady size, model the reservation and savings plan coverage. Buy to cover the trough, start with one-year terms if the estate is still moving, and record the renewal dates in a calendar somebody actually reads.
Days 66 to 80: tier storage and tune logging
Enable lifecycle management policies, prune snapshots, align backup retention, and review diagnostic settings against what anyone actually queries. This is quiet work with a durable payoff, because policies keep working without supervision.
Days 81 to 90: lock in the governance
Publish the tag standard, deploy the Azure Policy assignments that enforce it, create budgets and anomaly alerts at owned scopes, and run the first monthly review meeting. Finish by writing down what changed and what it saved, because that document is what buys you the time to do it again next quarter. It is also the evidence that the Azure cost optimisation programme worked.
Mistakes that quietly undo Azure cost optimisation
Most programmes do not fail loudly. They deliver a good first quarter and then erode, because one of these five patterns went unaddressed.
Buying commitments before rightsizing
Committing three years of spend to an oversized virtual machine converts a fixable problem into a contractual one. Always resize first, then commit. Microsoft limits how much reserved capacity you can cancel, so this mistake is expensive to reverse. It is the single most common Azure cost optimisation error we are called in to unpick.
Treating it as a one-off project
An estate that was optimised in March is not optimised in September. New workloads arrive with the same defaults, and old ones outlive their purpose. Azure cost optimisation only holds as a monthly rhythm, and the rhythm needs an owner with the authority to ask uncomfortable questions.
Optimising into an outage
Undersizing a production database to save a few hundred pounds, then explaining the incident to a customer, is a poor trade. Every change needs an owner’s sign-off, a monitoring window and a documented rollback. Speed is not the objective here.
Ignoring the non-compute bill
Teams fixate on virtual machines and forget bandwidth, log ingestion, backup, support plans and the gateways nobody has looked at since the migration. Those categories rarely dominate, but they are pure overhead when they are wrong, and they never fix themselves.
Letting the tag standard rot
If nobody enforces the tag policy, allocation coverage falls a few points every month until the reports are meaningless and the whole exercise has to start again. Track tagged-resource coverage as a metric in its own right and treat a decline as a defect, exactly as you would in managed IT services reporting.
Frequently asked questions about Azure cost optimisation
How much can we realistically save?
An estate that has never been reviewed typically yields 25% to 40% in the first pass, most of it from idle resources, sizing and commitments. A well-managed estate reviewed regularly will yield far less, which is the point — the savings show up once and then become the new baseline. Set that expectation before the first Azure cost optimisation meeting rather than after it.
Should we start with reservations because they are the biggest lever?
No. Rightsize and schedule first, then commit. Buying commitments against an unoptimised estate is the most common and most expensive Azure cost optimisation mistake, because it locks in the very waste you were trying to remove.
Do we need a FinOps specialist?
Not below a few tens of thousands of pounds of monthly spend. The Azure cost optimisation work is a defined checklist and a monthly cadence, which an experienced cloud engineer can run in a day a month. Specialists earn their keep at scale, across multiple clouds, or where cloud cost feeds directly into customer pricing.
How does this relate to our wider cloud strategy?
Cost is one of the five pillars of the Microsoft Azure Well-Architected Framework, alongside reliability, security, operational excellence and performance. Treating Azure cost optimisation as a standalone activity divorced from those trade-offs is how teams end up saving money in ways they later regret.
What about Microsoft support plan and licensing costs?
They are part of the bill and worth a yearly review. Support plans are often bought at a tier the business no longer needs, and licence entitlements bought elsewhere in the organisation frequently qualify for Hybrid Benefit without anyone realising.
How do we stop savings reversing after six months?
Enforcement and visibility. Policy-based guardrails prevent the expensive defaults, budgets and anomaly alerts catch the drift, and a monthly review with named owners keeps the pressure on. Without those three, expect the bill to return to trend inside two quarters. Azure cost optimisation is a habit before it is a project.
References
Azure Well-Architected Framework: Cost Optimisation Checklist
Microsoft Learn: Best Practices for Cloud Cost Management
Azure Advisor Cost Recommendations Reference
Save Money with Azure Reserved Instances
What is an Azure Savings Plan for Compute?
Azure Hybrid Benefit Pricing and Eligibility
Azure Blob Storage Access Tiers Overview
Create and Manage Azure Budgets
Identify Anomalies and Unexpected Azure Charges
Azure Monitor Logs Cost Calculations and Options
Cost Optimisation Best Practices for Azure Kubernetes Service
