Azure cost management is the discipline that stands between a UK business and the invoice nobody expected. The uncomfortable part is that the invoice is almost never a surprise in the technical sense. By the time a finance director is asking why the Azure bill moved from £4,100 to £6,800 in a single month, the cause has usually been sitting in the tenant for weeks, visible to anyone who knew where to look, quietly accruing at a few pounds an hour.
This guide is built around that observation. It starts with the silent cost drivers that account for the overwhelming majority of real-world Azure overspend in UK small and mid-sized organisations — unattached disks, undeallocated virtual machines, orphaned public IP addresses, always-on network appliances, runaway log ingestion and dev environments that nobody turns off. It then works through the controls that catch those drivers early: setting Azure budget alerts that fire on forecast rather than only on actual spend, configuring the Azure Cost Management tool so that the numbers it shows are actually attributable to a team or a project, running a structured cleanup of orphaned resources without breaking production, and establishing a monthly review that takes about an hour and catches spend creep while it is still a rounding error. It covers indicative 2026 UK pricing, the commitment mechanisms that reduce the bill permanently, and the specific mistakes that turn a manageable drift into a genuine shock.
What Azure bill shock actually is — and what it usually is not
Bill shock is the gap between what an organisation expected to pay and what it was invoiced. That is a budgeting failure as much as a technical one, and it is worth separating the two because they have different fixes. If Azure spend rose because the business onboarded forty staff, migrated a file server and stood up a reporting database, the bill is doing exactly what it should. That is growth, and the answer is to update the forecast. Genuine bill shock is different: spend rises while the workload does not, and nobody can immediately say why.
In practice the distinction is easy to test. Take the month-on-month increase and try to attribute it to a deliberate decision. In the reviews we run, most organisations can attribute somewhere between a quarter and a half of an unexpected increase to something a person chose to do. The remainder sits in a small and remarkably consistent set of categories: resources that were created for a reason that has since expired, resources that were stopped in a way that does not stop billing, meters that scale with data volume rather than with users, and commitments the organisation is entitled to but has not applied.
This matters because the two problems need different responses. Growth-driven spend needs forecasting, tagging and chargeback so the cost lands with the team that caused it. Waste-driven spend needs detection and cleanup, and it responds very quickly — a single afternoon of work on a neglected tenant routinely removes between five and fifteen per cent of monthly run rate. Neither is solved by asking engineers to be more careful, which is the response most organisations reach for first and the one that has the shortest half-life.
The other thing bill shock usually is not: a pricing change. Microsoft does adjust regional list prices periodically to track currency movements, and UK customers billed in pounds have seen those adjustments land, but the increments are single-digit percentages applied on a published schedule. They are a line in the annual forecast, not the reason a bill jumped by a third in one month. If a price adjustment is being offered as the explanation for a large in-month movement, it is worth checking the cost analysis view before accepting it.
Before investigating anything else, open Cost Management, set the view to Daily granularity across the last 60 days and group by Service name. Almost every real case of bill shock shows up as a visible step change on a specific day in a specific service. Finding that day tells you what changed, and the resource that changed is usually named in the audit log for the same date. This takes about four minutes and eliminates most of the guesswork that otherwise consumes an afternoon.
The shape of the problem in UK organisations
The figures below reflect what we typically observe when we take over or review an Azure tenant that has been running for eighteen months or more without a formal cost discipline. They are indicative of the SME and mid-market band — roughly 20 to 400 seats — rather than of enterprise estates, where the percentages tend to be lower in relative terms and very much larger in absolute ones.
The last figure is the one that explains the others. A budget in Azure is not a spending cap — more on that distinction shortly — but it is the only mechanism that will proactively tell somebody that spend is heading somewhere it should not. Without one, the feedback loop between a mistake and its discovery is the billing cycle, which means an error made on the third of the month is reported to finance somewhere around the tenth of the following month. That is five and a half weeks of accrual on something that could have been fixed in ten minutes.
The six-day detection lag is worth dwelling on as well, because it is measured from tenants that do have some form of monitoring. Cost data in Azure is not instantaneous: usage records for most services land in Cost Management within eight to 24 hours, and some meters take longer to settle. A daily-granularity alert therefore cannot fire on the day the mistake was made. The realistic best case is a next-day warning, and designing the process around that constraint is more productive than wishing it were real-time.
The silent cost drivers, ranked by how often they appear
The following grid groups the recurring causes of unexplained Azure spend by the layer they sit in. The risk badges reflect frequency combined with the typical monthly cost when the item is present, not technical severity. A high-risk item here is one that shows up in most neglected tenants and costs enough to matter; a low-risk item is one that either appears rarely or costs little when it does, though it is still worth clearing.
Two items in that grid are worth calling out because they are the ones most often misunderstood. The first is the difference between a virtual machine that is stopped and one that is stopped (deallocated). Shutting a Windows or Linux VM down from inside the guest operating system, or through a scheduled task in the OS, leaves the machine in a stopped state in which the compute allocation is retained and billed in full. Only deallocation — stopping the VM from the Azure portal, CLI, PowerShell or an automation runbook — releases the compute and stops the compute meter. Storage continues to bill either way, because the disks still exist.
The second is public IP addressing. Following the retirement of the Basic SKU public IP in September 2025, new public IPs are Standard SKU, and a Standard SKU static public IP is charged whether or not it is attached to anything. An organisation that has rebuilt a handful of virtual machines over a couple of years, each time creating a fresh IP and leaving the old one behind, can accumulate a dozen of them without noticing. Individually they are small. Collectively, at a few pounds each per month, they are a standing charge for nothing, and they never appear in any conversation about capacity because no resource is consuming them.
Log Analytics deserves a mention of its own because it is the driver that scales least predictably. Ingestion is charged per gigabyte, and the volume is a function of what is configured to send data rather than of how many people use the system. Switching on verbose diagnostic settings across a subscription, enabling a new Defender plan, or deploying an application that logs at debug level in production can multiply ingestion overnight with no change to the user-facing workload at all. It is the single most common cause of a step change that engineers genuinely cannot explain, because from their point of view nothing about the application changed.
Where the money actually goes on a typical UK Azure invoice
Before optimising anything it helps to know the rough proportions. The chart below shows the distribution of monthly Azure spend across service categories for a composite UK organisation of around 120 staff running a lift-and-shift estate: a handful of Windows Server virtual machines, an Azure SQL database, file services, a site-to-site VPN, backup into a Recovery Services vault and the monitoring that came with it. Proportions shift considerably for organisations that are further into platform services, but this shape is the one most UK SMEs recognise.
Compute dominating at something close to half the bill is the normal picture for a migrated estate, and it is why right-sizing has the largest single lever. It is also why commitment discounts matter: compute is the category where reservations and savings plans apply most cleanly, and leaving forty-four per cent of the invoice on pay-as-you-go rates when the workload runs continuously is a decision, even when nobody consciously made it. The practical detail of matching VM families and sizes to real utilisation is covered in more depth in our guide to Azure VM sizing for UK SMEs.
The categories at the bottom are the ones that cause disproportionate trouble, because they are the ones that move without warning. Monitoring at six per cent looks harmless until a diagnostic setting change takes it to eighteen. Egress at four per cent looks harmless until a backup job starts replicating cross-region. Neither category is large enough to attract attention during a normal month, which is precisely why they are the ones that need alerting rather than review.
One caution on reading any breakdown of this kind: it describes proportions, not absolutes. An organisation whose bill is ninety per cent compute does not have a problem by definition — it may simply have a compute-heavy workload and a very tidy storage footprint. The value of the breakdown is as a starting point for questions. If monitoring is fifteen per cent of the bill, that is a question. If backup is twenty per cent, that is a question. The answers are sometimes entirely reasonable.
What the common waste items cost — indicative UK list prices
The table below gives indicative monthly figures for the waste items that appear most often, based on UK South region list pricing in pay-as-you-go terms during 2026. They are rounded, they exclude VAT, and they will differ under an Enterprise Agreement, a Microsoft Customer Agreement or a CSP arrangement with partner-applied pricing. Treat them as orders of magnitude for prioritising cleanup work, and confirm current figures against the Azure Pricing Calculator and your own agreement before putting any number in front of a board.
| Waste item | How it is billed | Indicative cost each, per month | Typical count found in a neglected tenant |
|---|---|---|---|
| Unattached Premium SSD managed disk (P10, 128 GiB) | Provisioned capacity, billed whether attached or not | £15–19 | 3–8 |
| Standard SKU static public IP with no association | Hourly rate per reserved address | £2.50–3.50 | 4–12 |
| VM stopped in-guest but not deallocated (D4s v5) | Full compute hourly rate continues to accrue | £120–155 | 1–3 |
| Azure Firewall Standard on an idle non-production network | Fixed hourly deployment charge plus data processing | £600–720 | 0–1 |
| Retained VM snapshots with no lifecycle policy (per 128 GiB) | Incremental capacity, charged indefinitely until deleted | £4–7 | 10–40 |
The Azure Firewall row is the one that changes the arithmetic when it appears. A firewall deployed for a proof of concept and never torn down is a four-figure annual charge for an appliance inspecting traffic that no longer exists, and because it is a single resource rather than a scattering of small ones it tends to hide in plain sight in the cost analysis view. The same logic applies to Application Gateway, NAT Gateway, Bastion and VPN gateways: they carry a fixed hourly charge that accrues identically whether they are handling production traffic or nothing at all. Any resource with a fixed hourly rate should be on a list that somebody reviews, because utilisation has no effect on its cost.
Conversely, the snapshot row illustrates the opposite failure mode. No individual snapshot is worth chasing. Forty of them, accumulated over two years of pre-patch safety copies that nobody ever deleted, come to a couple of hundred pounds a month and will keep growing indefinitely because there is no natural end to the process that creates them. The fix is a lifecycle rule rather than a cleanup, and the cleanup only needs doing once if the rule goes in at the same time.
Azure budget alerts — building the early warning system
A budget in Microsoft Cost Management is an alerting construct, not a control. This is the single most important thing to understand about it, and the point at which a lot of finance teams are misled. Creating a £5,000 monthly budget on a subscription does not stop resources when spend reaches £5,000. It sends an email. Resources keep running, the meter keeps ticking, and the only thing that has changed is that somebody now knows. Azure does not offer a hard spending cap on standard commercial agreements; the cap that exists on free trial and sponsored subscriptions is a different mechanism and does not carry across.
That is not a reason to skip budgets — the alert is genuinely the thing that shortens the six-day detection lag — but it does mean the design has to account for the absence of enforcement. A budget that only alerts at one hundred per cent of actual spend is nearly useless, because actual spend only reaches one hundred per cent near the end of the month, by which time the money is committed. The configuration that works has three properties.
Alert on forecast, not only on actual
Cost Management supports both actual and forecasted alert conditions. A forecasted alert evaluates projected end-of-period spend against the threshold and fires when the trajectory, rather than the current total, breaches it. This is what converts a budget from a post-mortem tool into an early warning. A forecasted alert at ninety per cent on a monthly budget will typically fire within a day or two of a meaningful step change, because the projection picks up the new daily run rate immediately. Set forecasted alerts at 90 and 100 per cent, and actual alerts at 50, 80 and 100 per cent, and the combination gives both the early signal and the confirmation.
Scope the budget where somebody can act on it
A single budget at subscription level tells you that something increased. A budget per resource group, per environment or per management group tells you where. Because most UK SME tenants organise resource groups roughly along project or system lines, resource-group budgets map reasonably well onto the question of who needs to do something. The additional effort is small: budgets can be created through the portal, the API, or as infrastructure-as-code alongside the resources themselves, which is the approach that survives staff turnover.
Send the alert somewhere a human reads
The default behaviour sends email to named recipients. That is fine until the named recipient leaves, at which point the alert quietly stops reaching anyone. Binding the budget to an action group is more durable, because an action group can target a distribution list, a shared mailbox, a Teams channel via webhook, or a ticketing system that will create a work item nobody can silently delete. Action groups also open the door to automated response — a runbook that deallocates a tagged set of development VMs when a threshold is hit, for example — though that should be treated as an advanced step rather than a starting position.
Alongside budgets, enable cost anomaly detection. It operates at subscription scope, evaluates daily, and uses the tenant’s own history rather than a fixed threshold, which makes it good at catching the exact class of problem budgets handle worst: a change that is large relative to normal but small relative to the monthly total. A new £40-a-day meter on a £6,000-a-month subscription will not trouble a budget threshold for a fortnight. Anomaly detection will flag it the next day.
Budget alerts evaluate against the scope you set, and a budget on a subscription does not see spend in a different subscription. Organisations that have accumulated several subscriptions — a common outcome of migrations, acquisitions and partner-created tenants — frequently have budgets on one or two of them and nothing on the rest. Check the full subscription list under the billing account rather than the list that appears in the portal for your own directory role, because the two are not always the same.
A 90-day plan to bring Azure spend under control
Cost control fails most often when it is attempted as a single heroic effort. The estate gets audited, a spreadsheet of findings is produced, a few things get deleted, and eighteen months later the same audit finds the same categories of waste because nothing changed about how resources are created and retired. The timeline below is the sequence that tends to stick, because it front-loads visibility, defers the risky deletions until the evidence is in, and finishes by installing a recurring process rather than a one-off result.
Ninety days is deliberate. Compressing this into a fortnight is possible in a small tenant, but the quarantine window is the part that cannot safely be shortened, and the right-sizing step needs a month of utilisation data to be defensible. Organisations that skip the evidence-gathering and resize on intuition tend to undersize something customer-facing, and the resulting incident does more damage to the credibility of cost work than the saving was worth.
Clearing orphaned resources without breaking production
The orphaned resources cost question is the one with the fastest payback and the highest anxiety attached, because deleting the wrong thing in a production tenant is a genuinely bad afternoon. The way to reduce the risk is to make the identification systematic rather than judgemental, and to separate identification from deletion by a deliberate interval.
Azure Resource Graph is the right tool for identification because it queries across every subscription you have access to in one pass, which the portal blade view does not. An unattached managed disk is identifiable by its disk state property, which reports as unattached when no virtual machine holds it. A public IP with nothing bound to it has a null IP configuration. A virtual machine that is stopped but still billing reports a power state of stopped rather than deallocated. Each of these is a single query that returns a list with resource group, subscription and tags, which is exactly the shape needed for a review spreadsheet.
Azure Advisor covers some of the same ground and is worth running alongside, particularly for idle public IPs and underutilised virtual machines, but it should not be the only source. Advisor is recommendation-driven and conservative by design, which means it will reliably surface the obvious cases and stay quiet about a load balancer with no backend pool or a gateway serving a decommissioned site. The combination of Advisor for the curated recommendations and Resource Graph for the exhaustive inventory covers more than either alone.
What deserves caution before deletion
Not every orphan is safe to remove. An unattached disk may be the data disk from a server that was deliberately shut down pending a decision, and deleting it destroys the data with it. A public IP may be referenced in a third-party firewall allowlist, a DNS record or a supplier integration, and releasing it means never getting that address back. A storage account may look idle because the application that writes to it runs quarterly. In each case the information that would tell you is outside Azure, which is why the quarantine step exists: fourteen days of visible tagging and a circulated list surfaces the human knowledge that no query can.
Snapshots are the exception worth handling differently. Rather than reviewing them individually, set the policy first — a retention period appropriate to the workload, expressed as a rule — then delete everything outside it as a single action. Reviewing four hundred snapshots one at a time is work that produces no better outcome than applying the policy would have.
Deleting a resource does not always stop the charge immediately. Reservations continue to bill for the committed term whether the matching resource exists or not, which is why cancelling a workload without addressing its reservation leaves a charge that appears to come from nothing. Similarly, a Recovery Services vault will refuse to delete while protected items remain, and stopping backup with retain-data keeps the recovery points billing. Check the reservation and vault positions as part of any decommissioning, not afterwards.
Chasing the invoice versus running a cost discipline
Most UK organisations arrive at Azure cost work reactively: a bill lands, somebody asks a question, and a few days of investigation follow. The alternative is not more effort, it is differently scheduled effort. The comparison below sets out what each approach actually costs in time and money over a year on a mid-sized estate.
Reactive
Investigate when the invoice looks wrong
Managed cost discipline
Alerting plus a monthly review with a named owner
The line that matters most is the second one. The difference between detecting a cost-increasing change in three days and detecting it in five weeks is roughly a factor of ten in accrued waste, and that ratio holds regardless of the size of the estate. A mistake that costs £40 a day costs £120 if caught quickly and £1,400 if it waits for the invoice. This is why the alerting configuration is worth more effort than the cleanup: cleanup addresses what already happened, alerting addresses everything that happens next.
The twelve hours of annual review effort is not a trivial commitment for a small internal IT team, and it is the reason this work is frequently outsourced or folded into a managed service. It is also, in our experience, the most reliably recovered twelve hours anywhere in an IT budget, because the estate it governs is one where a single overlooked resource can cost more per month than the review takes to run. The wider question of how cost discipline fits alongside other technology planning is something we cover in our guide to building an IT roadmap for a UK business.
Reservations, savings plans and Azure Hybrid Benefit
Cleanup and right-sizing reduce consumption. Commitment and licensing reduce the rate you pay for the consumption that remains, and they are the two levers that produce a permanent step down in the bill rather than a one-off correction. They are also the levers most often left unpulled in UK SME tenants, usually because nobody is certain of the entitlement position and the decision carries a multi-year commitment.
Reserved instances and savings plans
A reservation commits to a specific VM size in a specific region for one or three years in exchange for a substantially reduced rate — commonly in the region of forty per cent for a one-year term and rising towards seventy per cent for three years on some families, though the exact discount varies by SKU and region and should be checked rather than assumed. A savings plan is the more flexible sibling: it commits to an hourly spend figure across eligible compute rather than to a particular size, which trades a slightly lower discount for the freedom to change SKU without stranding the commitment.
The choice between them is mostly about how stable the estate is. A domain controller and a line-of-business application server that have run the same size for three years are reservation candidates. A development platform that is actively being re-architected is a savings plan candidate, or a candidate for nothing at all until it settles. The sequencing point from the timeline bears repeating: commit after right-sizing. A three-year reservation on an oversized VM converts a correctable mistake into a contractual one.
Azure Hybrid Benefit
Azure Hybrid Benefit allows organisations with Windows Server or SQL Server licences covered by active Software Assurance, or with subscription licences, to apply those entitlements to Azure virtual machines and pay the Linux compute rate rather than the Windows one. The saving on a Windows VM is material — frequently around forty per cent of the compute line, and considerably more on SQL Server workloads where the licensing component dominates.
Two practical notes. First, the benefit has to be switched on; it is not applied automatically, and a migration that used a Windows marketplace image will default to paying the full rate. It can be toggled on an existing VM without redeployment, which makes this one of the few genuinely free wins in the whole exercise. Second, applying the benefit is an assertion about your licence position, so the entitlement needs to be real and documented. Checking the Software Assurance status on the volume licensing agreement before switching it on is a five-minute task that avoids an awkward conversation during a licence review.
Beyond compute, the same principle of paying the right rate applies to storage tiers, database purchasing models and support plans. Hot blob storage holding data that has not been read in a year belongs in cool or archive, and a lifecycle management rule will move it automatically based on last-modified or last-accessed time. An Azure SQL database sized by DTU when the workload would suit a serverless vCore configuration is paying for availability it does not use. None of these individually rivals compute for scale, but together they routinely account for another five to eight per cent.
How ready is the average UK Azure tenant?
Pulling the assessment areas together into a single figure gives a rough indication of how well-defended an organisation is against unexpected Azure spend. The gauge reflects what we typically find on a first review of a UK business in the 20–400 employee band that migrated to Azure more than a year ago and has not formally revisited cost since the migration closed.
A score in the low forties has a recognisable composition. Visibility usually scores moderately, because the Cost Management tool is present in every tenant by default and somebody has at least opened it. Alerting scores poorly, because budgets require a deliberate act of configuration and anomaly detection is not switched on for you. Attribution scores worst, because meaningful tagging requires a policy applied at creation time and almost nobody retrofits tags to an existing estate voluntarily.
The encouraging side of a low score is that the remedies are cheap. Moving from forty-two to somewhere in the seventies is largely a matter of configuration rather than expenditure: budgets, anomaly detection, a required-tag policy, auto-shutdown schedules and a calendar entry. The work that costs real money — re-architecting to platform services, moving to containers, adopting autoscaling — sits above eighty and is not where an organisation at forty-two should be spending its attention.
It is also worth being honest about what the score does not measure. A tenant can be extremely well governed and still expensive, because the workload is genuinely large. Cost management is about paying a defensible amount for what you have chosen to run, not about minimising the number at all costs. An organisation that cuts its backup retention to save £200 a month and then cannot meet its own recovery point objective has not optimised anything, a trade-off we look at in more detail in our guide to Azure disaster recovery and failover planning.
Benchmarks — what good looks like against what we usually find
The rows below compare the practices that constitute competent Azure cost management against the proportion of UK tenants we review that actually have them in place. The percentages are adoption rates, not quality scores: a tenant counts as having budgets configured if any budget exists at any scope, which is a generous reading and still produces the figures shown.
Adoption of core cost controls in UK SME Azure tenants
The gradient down that list is the whole story. Seventy-one per cent have looked at the data; twelve per cent have a process that makes them look at it on a schedule. Everything between those two numbers is the difference between awareness and control, and the items that fall furthest — tagging policy, lifecycle rules, scheduled review — are the ones that require a decision to be made once and then enforced by a system rather than by memory.
The forecasted-alert figure at twenty-nine per cent is the most consequential gap relative to its cost. Adding a forecasted threshold to an existing budget takes under a minute per budget and roughly halves the detection lag. There is no technical obstacle and no additional charge. It is simply a setting that most people do not know is there, because the default budget creation flow leads naturally to an actual-spend threshold and does not insist on anything else.
The single number that predicts bill shock
If an organisation could track only one metric, it would be the proportion of monthly Azure spend that can be attributed to a named owner through tagging. It correlates more strongly with whether a tenant experiences unexplained cost increases than any other single measure we look at, and it does so for a straightforward reason: spend that belongs to nobody is spend that nobody reviews.
Thirty-seven per cent means roughly two-thirds of the bill arrives each month as an undifferentiated total. When that total moves, there is no starting point for the investigation other than working backwards through the cost analysis view resource by resource. When it is seventy or eighty per cent tagged, the same movement is immediately narrowed to a team, a project or an environment, and the investigation becomes a conversation rather than an archaeology exercise.
Getting the number up is less daunting than it looks, because spend is heavily concentrated. Tagging the top twenty resources by cost in most SME tenants covers well over half the bill. The approach that works is to tag the expensive things manually as a one-off, then enforce a required-tag policy through Azure Policy so that everything created from that point forward carries the tags automatically or is denied. Tag inheritance from resource group or subscription level in Cost Management covers a further slice without touching the resources at all.
Pick a small tag set and hold to it. Owner, environment, cost centre and application is enough for almost any SME, and a schema with four mandatory tags is one people comply with. Schemas with fourteen optional tags produce inconsistent values, which is worse than no tags, because a report grouped by a tag that has been spelled six different ways looks authoritative and is not. The same discipline that makes reporting data trustworthy elsewhere applies here, a theme we explore in our guide to data warehouses and reporting databases.
The monthly cost review — an hour that catches spend creep
The review is the mechanism that converts all of the configuration above into a durable outcome. It needs a named owner, a fixed slot in the calendar shortly after the invoice date, and about sixty minutes. It does not need a large audience: the person responsible for the Azure estate, somebody from finance who owns the budget line, and the application owner for anything under discussion is sufficient. Larger meetings produce longer meetings and no better decisions.
The agenda that works
Start with the total against forecast and last month, then move straight to the largest movements by service and by resource group rather than reviewing everything. Ten minutes on variance, fifteen on the specific resources that moved, ten on any alerts that fired during the month and what was done about them, ten on the orphan report, ten on the commitment position, and five to confirm actions with owners and dates. Anything that cannot be resolved in the meeting becomes a ticket rather than a discussion point carried over indefinitely.
Two standing items earn their place permanently. The first is the orphan report — the same Resource Graph queries from the cleanup phase, run monthly, so that the categories that were emptied in week six do not silently refill. The second is the commitment expiry horizon: reservations and savings plans reaching the end of their term within ninety days, so that renewal is a decision rather than an automatic continuation of a shape that may no longer fit.
What to record
Keep the output short and consistent: total spend, variance against forecast, the explanation for any movement above a threshold you set, the actions agreed and the run-rate impact expected from them. Over six months this becomes the document that lets finance forecast Azure with confidence, which is the actual objective. Cost management is often framed as reducing the bill, but for most organisations the more valuable outcome is a bill that behaves predictably, because a predictable cost can be planned around and an unpredictable one cannot.
A daily scheduled export of amortised cost data to a storage account is worth configuring to support this. It gives a history independent of portal retention limits, it can be pointed at Power BI or a reporting database for trend analysis, and it means the review is working from a consistent dataset rather than whatever the portal happens to show on the day. Microsoft also publishes an open-source FinOps toolkit with hub deployments and pre-built Power BI reports, which is a reasonable starting point for organisations that want the reporting without building it.
What this looks like in practice
A 96-person professional services firm in the West Midlands migrated its on-premises estate to Azure across 2024 and closed the project the following spring. The migration was competently done: servers moved, users noticed very little, and the monthly Azure invoice settled at roughly £5,200 against a business case that had modelled £4,900. Nobody regarded the variance as a problem.
Fifteen months later the invoice was £7,850. Headcount had grown by eleven. Nothing had been deliberately added to the platform beyond a reporting server stood up the previous autumn. The finance director asked for an explanation and the internal IT manager, who had no particular reason to have been watching, could account for perhaps £600 of the £2,650 increase.
The review took three days and found five things. A verbose diagnostic setting applied during troubleshooting in January had never been reverted, adding roughly £310 a month of Log Analytics ingestion. Nine unattached premium disks remained from VMs rebuilt during and after the migration, at £164 a month. Two virtual machines used for a finance system upgrade had been shut down from within Windows fourteen months earlier and were still billing full compute at £295 a month between them. Seven public IP addresses had no association. And no Windows Server workload in the tenant had Azure Hybrid Benefit applied, despite the firm holding Software Assurance on the licences it had migrated, which alone accounted for just over £900 a month.
The cleanup and the hybrid benefit toggle took an afternoon and removed £1,690 of monthly run rate. Right-sizing four over-provisioned VMs against measured utilisation removed a further £340. The reporting server, which was the only genuinely new workload, turned out to account for £480 — a legitimate cost that the business was happy to pay once it could see it in isolation. What remained was a bill of roughly £5,820 for an estate that had grown, against £5,200 for one that had not, which is a variance the finance director could explain to the board.
The number that bothered us was never the total. It was that nobody could tell me what the extra two and a half thousand pounds was buying. Once we could see it broken down, most of it turned out to be things we were not using at all, and the part that was real we were perfectly happy to pay for. Now I get an alert when something moves and we spend an hour a month on it, which is considerably less time than we spent arguing about one invoice.
The detail that generalises from this is the hybrid benefit finding. It was the largest single item, it required no cleanup, no risk and no downtime, and it had been available from the day the workloads landed in Azure. It went unclaimed for fifteen months because applying it is an explicit action that nobody had been asked to take, and because the migration project had been measured on whether the servers worked rather than on whether they were billed correctly. That gap between technical success and commercial success is where most Azure overspend lives.
Common mistakes that turn a manageable bill into a shock
The failures below are the ones we see repeatedly, and they are notable for being process failures rather than technical ones. Every organisation in this list had competent engineers. What they lacked was a mechanism that made the cost consequence of a change visible to somebody at the moment it happened.
- Treating a budget as a cap. Setting a budget and assuming Azure will stop spending at the threshold. It will not. The budget sends an alert and the meter keeps running, so a budget with no recipient who acts on it is decoration.
- Alerting only on actual spend at 100 per cent. By the time actual spend reaches the threshold, the month is nearly over and the money is committed. Without a forecasted threshold the alert is a notification of history.
- Shutting VMs down from inside the guest OS. A machine stopped in Windows or Linux retains its compute allocation and bills in full. Only deallocation stops the compute meter, and the portal state that matters is stopped (deallocated), not stopped.
- Committing to reservations before right-sizing. A three-year reservation on an oversized SKU locks in the wrong shape for the full term and turns a reversible mistake into a contractual one. Measure utilisation first, resize, then commit.
- Enabling diagnostics broadly during an incident and never reverting. Verbose logging switched on to troubleshoot a problem in February is still ingesting in November. Log Analytics ingestion scales with configuration, not with users, so nothing about the workload signals the change.
- Leaving fixed-hourly appliances running on non-production networks. Firewalls, gateways, Bastion hosts and NAT gateways bill at the same rate whether they are processing traffic or sitting idle. A proof of concept that was never torn down is a four-figure annual charge.
- Deferring tagging until later. Retrofitting tags to a live estate is tedious enough that it rarely happens, so the tenant permanently lacks attribution. Enforcing required tags at creation costs nothing and is the difference between a cost report and a cost mystery.
- Assuming the partner or the migration project handled licensing. Azure Hybrid Benefit is not applied automatically, and a marketplace Windows image defaults to the full rate. Nobody is checking this on your behalf unless you have asked them to.
The most expensive version of the diagnostics mistake involves Microsoft Defender for Cloud. Enabling a Defender plan at subscription scope applies it to every eligible resource in that subscription, including ones added later, and the per-resource charges accumulate quietly. Defender is frequently the right choice and the protection is worth paying for — the mistake is enabling it without anyone modelling the cost first and then discovering the figure on an invoice. Review the plan selection per subscription, not once at the tenant level.
The 12-point Azure cost control checklist
This is the sequence to work through, in order. Items one to four are configuration and can be completed in an afternoon with no risk to production. Items five to eight involve changes to running resources and need the evidence and quarantine discipline described earlier. Items nine to twelve are the guardrails that stop the estate drifting back.
- Enumerate every subscription under the billing account. Not the ones visible in your directory — the full list under the billing profile, with an owner and a current run rate recorded against each.
- Create budgets at subscription and major resource-group scope. Actual thresholds at 50, 80 and 100 per cent; forecasted thresholds at 90 and 100 per cent.
- Route alerts to an action group, not to a named individual. A distribution list, shared mailbox, Teams channel or ticket queue survives staff turnover in a way a personal email address does not.
- Enable cost anomaly detection on every subscription. It is free, it evaluates daily against your own baseline, and it catches changes too small to move a budget threshold.
- Run the orphan inventory across all subscriptions. Unattached disks, unassociated public IPs, stopped-not-deallocated VMs, empty load balancers and gateways, snapshots outside retention.
- Quarantine before deleting. Tag with a review date, snapshot anything whose purpose is unclear, circulate the list, allow fourteen days for objections, then delete what remains unclaimed.
- Right-size against at least 30 days of measured utilisation. Azure Advisor recommendations alongside CPU, memory and disk metrics — never on intuition, and never before the cleanup.
- Apply Azure Hybrid Benefit to every eligible Windows Server and SQL Server workload. Confirm the Software Assurance entitlement first, then toggle it; no redeployment is required.
- Model reservations and savings plans against the post-right-sizing baseline. Reservations for stable SKUs, savings plans where the estate is still moving, nothing where the workload is temporary.
- Enforce a four-tag minimum through Azure Policy. Owner, environment, cost centre, application. Deny or auto-append at creation so compliance is structural rather than cultural.
- Automate the obvious schedules. Auto-shutdown on development VMs outside working hours, storage lifecycle rules moving cold data to cool or archive, per-table retention on Log Analytics.
- Put a monthly review in the calendar with a named owner. Sixty minutes, shortly after the invoice date, with the orphan report and the commitment expiry horizon as standing items.
Items one to four deliver most of the protective value and none of the risk, which makes them the right place to start even if there is no appetite for a full programme. An organisation that does nothing else but complete the first four items will still find out about its next cost-increasing change within a day or two rather than five weeks later, and that alone removes the majority of the financial exposure that bill shock represents.
At a glance — Azure cost management summary
| Question | Short answer |
|---|---|
| What causes most Azure bill shock? | A small set of predictable items — orphaned resources, undeallocated VMs, log ingestion changes and unapplied licensing — rather than genuine workload growth. |
| Typical waste in an unmanaged tenant | 18–32 per cent of monthly spend |
| Does a budget stop spending? | No. Budgets alert; they do not cap. Azure has no hard spending cap on standard commercial agreements. |
| Fastest single improvement | Adding forecasted alert thresholds to existing budgets — under a minute each, roughly halves detection lag |
| Highest-value licensing check | Azure Hybrid Benefit on eligible Windows Server and SQL Server VMs; commonly around 40 per cent off the compute line |
| Stopped versus deallocated | Stopped in-guest still bills full compute; only deallocation releases it. Disks bill either way. |
| Cost data latency | Typically 8–24 hours for most meters, so next-day is the realistic best case for alerting |
| Correct order of operations | Visibility, then cleanup, then right-sizing, then commitment. Committing early locks in the wrong shape. |
| Right-sizing evidence needed | Minimum 30 days of CPU, memory and disk metrics plus Azure Advisor recommendations |
| Minimum useful tag set | Owner, environment, cost centre, application — enforced at creation via Azure Policy |
| Review cadence | Monthly, 60 minutes, named owner, shortly after the invoice date |
| Time to first meaningful result | An afternoon for alerting configuration; six weeks to a completed cleanup; 90 days to a working discipline |
| Typical immediate reduction from cleanup | 5–15 per cent of monthly run rate |
| Primary objective | A bill that behaves predictably and can be attributed — not simply the smallest possible number |
How Cloudswitched works with UK businesses on Azure cost
Cloudswitched supports UK organisations running production workloads in Azure, and cost discipline is part of how we run those estates rather than a separate engagement. That covers the initial review across every subscription under the billing account, the alerting and anomaly configuration, the orphan inventory and quarantined cleanup, right-sizing against measured utilisation, the licensing and commitment position, and the recurring monthly review with a named owner on our side. Where an internal team wants to run the discipline themselves, we will set the controls up and hand them over with the queries and the agenda.
Get a clear view of your Azure spend
We review UK Azure estates across every subscription, identify what is being paid for and not used, and put the alerting in place so the next change is visible within a day rather than on the next invoice.
Talk to an Azure SpecialistFrequently Asked Questions
What is Azure cost management and what does the tool actually do?
Azure cost management is the practice of understanding, attributing and controlling what an organisation spends on Azure. Microsoft Cost Management is the built-in tool that supports it, and it is included at no additional charge in every Azure subscription. It provides cost analysis with filtering and grouping by service, resource group, location and tag; budgets with configurable alert thresholds; cost anomaly detection; scheduled exports of usage and amortised cost data; and integration with Azure Advisor for optimisation recommendations. What it does not do is enforce spending limits. It is an analysis and alerting tool, and the control comes from the process built around it.
Can I set a hard spending limit on Azure so it stops when I hit a number?
Not on a standard commercial agreement. Azure offers a spending limit on free trial and certain sponsored or credit-based subscriptions, where reaching the limit disables the services, but that mechanism does not apply to pay-as-you-go, Enterprise Agreement, Microsoft Customer Agreement or CSP subscriptions. Budgets on those subscriptions alert rather than enforce. Organisations that want enforcement build it themselves by binding a budget alert to an action group that triggers an automation runbook — for example deallocating VMs carrying a particular tag when a threshold is reached. That is achievable but should be treated carefully, because automation that turns off production resources at a spending threshold can cause more damage than the overspend.
How do I find orphaned resources costing money in my Azure tenant?
Azure Resource Graph is the most efficient route because it queries across every subscription you have access to in a single pass. The categories worth enumerating are managed disks in an unattached state, public IP addresses with no IP configuration bound to them, virtual machines whose power state is stopped rather than deallocated, load balancers and application gateways with empty backend pools, VPN and NAT gateways on networks with no live traffic, and snapshots or restore points older than your stated retention. Azure Advisor covers a subset of the same ground with curated recommendations and is worth running alongside, but it is conservative and will not surface everything. Combine the two, and quarantine before deleting.
Why is my Azure bill going up when nothing has changed?
In most cases something did change, but not in a way that was visible to the people looking. The usual candidates are a diagnostic or logging setting enabled during troubleshooting and never reverted, a Defender for Cloud plan switched on at subscription scope, a backup or replication job that started moving data across regions, storage growing steadily in the hot tier, or a resource created for a short-term purpose that outlived it. Set cost analysis to daily granularity across the last 60 days and group by service name; a step change on a specific day in a specific service will usually be visible, and the activity log for that date will name what was created or modified.
What is the difference between a stopped and a deallocated Azure VM?
A stopped VM has been shut down from within the guest operating system, or by a process inside it. The virtual machine retains its allocation on the underlying host, and the compute meter continues to bill at the full hourly rate. A deallocated VM has been stopped through the Azure control plane — portal, CLI, PowerShell or automation — which releases the compute allocation and stops the compute charge. In both cases the managed disks continue to bill, because they still exist and still occupy provisioned capacity. The portal shows the distinction explicitly as Stopped versus Stopped (deallocated), and it is worth checking rather than assuming, because a VM that somebody shut down a year ago can represent one of the largest single items of waste in a tenant.
How should I set Azure budget alerts so they are actually useful?
Use both alert types. Actual-spend thresholds at 50, 80 and 100 per cent give you the confirmation trail, and forecasted thresholds at 90 and 100 per cent give you the early warning, because a forecasted alert evaluates projected end-of-period spend and fires when the trajectory breaches the threshold rather than waiting for the total to get there. Scope budgets where somebody can act on them — resource group level in most SME tenants, since resource groups usually map onto projects or systems. Route the alerts to an action group targeting a shared mailbox, Teams channel or ticket queue rather than to an individual, so the alerting survives someone leaving. Then enable anomaly detection alongside, because it catches changes too small to trouble a percentage threshold.
How much can a UK business realistically save on Azure?
For a tenant that has been running for more than a year without a cost discipline, a first review typically identifies somewhere between eighteen and thirty-two per cent of monthly spend as recoverable, of which five to fifteen percentage points usually come out immediately through cleanup and licensing changes with no architectural work. The remainder comes from right-sizing and commitment, which take longer and require evidence. A tenant that is already well governed will find far less, and that is the correct outcome rather than a failed review. The figures depend heavily on the estate, so treat them as a basis for asking questions rather than as a target to be promised.
Is Azure Hybrid Benefit worth applying, and how do I know if I qualify?
It is usually the single largest saving available that requires no technical change. Azure Hybrid Benefit lets organisations with Windows Server or SQL Server licences covered by active Software Assurance, or with qualifying subscription licences, pay the base compute rate rather than the Windows rate on eligible virtual machines. The saving on Windows Server workloads is commonly around forty per cent of the compute line, and considerably more on SQL Server where licensing dominates. Eligibility depends on your volume licensing position, so check the Software Assurance status on the agreement before enabling it — applying the benefit is an assertion about entitlement. It can be toggled on an existing VM without redeployment.
Should I buy reserved instances or a savings plan?
It depends on how stable the workload is. A reservation commits to a specific VM size in a specific region for one or three years and carries the larger discount. A savings plan commits to an hourly spend figure across eligible compute and accepts a somewhat smaller discount in exchange for the freedom to change SKU without stranding the commitment. Stable, long-lived servers — domain controllers, line-of-business application servers that have not changed size in years — suit reservations. Estates that are still being re-architected suit savings plans, or nothing at all until they settle. In every case, right-size first: committing to three years on an oversized machine turns a correctable mistake into a contractual one.
How often should we review Azure costs?
Monthly, as a scheduled meeting with a named owner, shortly after the invoice date, taking about an hour. That is frequent enough to catch drift while it is small and infrequent enough that people actually attend. The alerting does the daily work, so the review is not a monitoring exercise — it is where variance gets explained, actions get owners and dates, and the orphan report and commitment expiry horizon get their standing slot. Quarterly is too slow to prevent a full quarter of accrual on something avoidable, and weekly produces meetings with nothing new in them. If only one thing from this guide gets implemented, the alerting is more valuable; if two, add the review.
Does moving to Azure UK South rather than a European region cost more?
Regional list prices differ, and UK regions are not always the cheapest option in Europe on a like-for-like basis. For most UK organisations, however, the region decision should be led by data residency, latency and any contractual or regulatory commitments about where personal data is processed rather than by the price differential, which is usually modest relative to the risk of getting residency wrong. Where UK South is the right choice for those reasons, the saving opportunities discussed here — cleanup, right-sizing, hybrid benefit, commitment — are all available within the region and will comfortably exceed what region-shopping would have delivered.
Who should own Azure cost management in a business of 100 people?
One named person in IT, with a counterpart in finance who owns the budget line. It does not need a dedicated role at that size and it should not be spread across a team, because shared ownership of a recurring review reliably becomes no ownership. The IT owner runs the queries, maintains the alerting and chairs the monthly session; the finance counterpart holds the forecast and asks the questions that keep the exercise commercially grounded. Where there is no internal capacity for it, this is a natural component of a managed Azure service, and the important part is that the ownership is explicit either way.
Related reading
More guidance on planning, running and paying for UK cloud and IT infrastructure:
Azure spend you can explain
Cloudswitched reviews UK Azure estates end to end — every subscription, the orphaned resources, the licensing position and the commitment options — and puts the budgets, anomaly detection and monthly review in place so the next movement in your bill is one you already know about.
Talk to an Azure Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
