Your Azure bill went up and nothing changed. Here's what I check first.

00

“Nothing changed” is a symptom, not a diagnosis

A stable codebase can produce an unstable bill. A scheduled job can begin retrying. Log volume can double. A storage account can keep every backup it receives. An App Service Plan can sit at a tier chosen two years ago. A reservation can expire. A credit can run out.

None of that needs a release.

So I do not begin by asking who touched production. I begin by asking what Azure charged for. That keeps the investigation factual and, just as importantly, keeps it out of the blame game.

01

First, prove the increase is real

Before opening individual resources, make sure the two numbers are comparable. I have seen teams spend hours investigating a “spike” that was a longer billing period, a one-off purchase, an expired credit, or a tax and currency difference between the Cost Management view and the invoice.

Actual Cost shows what was charged in the period. That is useful when reconciling an invoice, but a reservation or Savings Plan purchase can make one month look dramatic. Amortized Cost spreads eligible commitment charges across the time and resources that used them. I want to see both before I decide whether the operating cost really changed.

02

Then find the line that moved

The total bill tells you there is a problem. It does not tell you where the problem is.

In Azure Cost Management, I compare the periods and group cost by service. Which service created most of the increase: Virtual Machines, App Service, Azure SQL, Storage, Log Analytics, bandwidth, backup, or something else?

Then I open that service and group by resource. If the resource view is still too broad, I go to the meter or charge type. The investigation should keep narrowing:

This sounds obvious. It is also the step most people skip. They open a crowded dashboard, notice six expensive things, and start trying to optimise all six. I care about the line that changed. An expensive resource that cost the same last month did not cause this month’s spike.

Microsoft’s Cost Analysis guidance covers the available views. The useful habit is simpler: sort by the difference between periods, not just by total spend.

03

Check whether a discount disappeared before blaming the infrastructure

If usage looks steady but cost moved, I check the commercial layer next.

• Did a reservation or Savings Plan expire?
• Did its scope change, leaving the intended workload uncovered?
• Did utilisation fall because the workload moved or changed size?
• Did Azure Hybrid Benefit stop applying?
• Did a grant, free credit, or negotiated discount end?

A workload can consume the same number of hours and cost more because the rate attached to those hours changed. That is why usage graphs alone do not settle the question.

I also avoid buying a new commitment as the first response. Right-size first. Confirm the workload is stable. Then commit. Reserving oversized capacity does not remove waste; it gives the waste a contract.

04

Look for usage that grows quietly

No deployment does not mean no demand change. The application can do more work without new code.

These are the quiet movers I see most often:

• Autoscaling: more instances ran, or they stayed out longer than usual.
• Retries and failed jobs: the same business task consumed two or ten attempts instead of one.
• Logs and telemetry: ingestion or retention grew after a noisy error, debug setting, or new data source.
• Storage and backup: data accumulated, snapshots multiplied, or retention never expired.
• Data transfer: traffic crossed a region, zone, or service boundary more often.
• Database activity: heavier queries, longer jobs, or elastic scaling used more provisioned or serverless capacity.

The practical check is to place the cost trend beside the workload metric that should explain it: requests, executions, instance count, ingested gigabytes, stored gigabytes, backup size, egress, DTUs, vCores, or node hours.

If cost rose and the matching workload metric rose with it, you may not have waste. You may have growth, a reliability problem, or inefficient work. Those lead to different decisions.

05

Now inspect the things that bill while looking idle

A quiet resource is not necessarily a free resource.

An App Service Plan can keep billing with almost no requests. A stopped VM can still be allocated; it needs to be deallocated for the compute charge to stop. Its disks, snapshots, backups, IP configuration, and connected services can continue to cost money either way. Azure SQL, gateways, and other provisioned services charge for the capacity you keep available, not for how busy the dashboard looks.

This is where orphaned resources show up: disks left behind after a VM disappeared, old snapshots, forgotten test environments, duplicate monitoring workspaces, and tiers selected for a launch that never reached the expected load.

In the Magrid Azure cost reduction case study, the large number was not one exotic mistake. It was App Service Plans sized for load that was not arriving, oversized VMs, SQL configuration that had never been revisited, unattached disks, and old service tiers. After the workload was understood, stable capacity was covered with reservations. Roughly EUR 3,000 per month came out of an approximately EUR 4,500 monthly baseline. I unpack the operating conditions behind that result in why a 65% Azure saving was available.

That result is not a benchmark. It is a useful picture of how ordinary decisions accumulate when nobody has a reason to go back.

06

Do not turn a cost spike into a production incident

Finding an expensive resource is not the same as proving it is safe to change.

Before I recommend deleting, resizing, scheduling, or changing a tier, I want a representative period of Azure Monitor metrics, the workload owner’s context, known peak events, dependencies, availability requirements, and a rollback path. Fourteen days may be enough for a steady workload. It is not enough if month-end, payroll, a seasonal sale, or a quarterly reporting run sits outside that window.

Azure Advisor cost recommendations are useful leads. They are not production approval. Azure cannot know that the quiet VM runs a regulator’s export on the final day of every quarter unless your operating context makes that visible.

The cost question is “what can we save?” The engineering question is “what happens if we do?” You need both answers.

07

Make the next Azure cost spike obvious

A good investigation should leave more than a lower number. It should leave a baseline.

For every material workload, record who owns the cost, what normal monthly and daily spend look like, which metric explains demand, what commitment covers it, and when its size was last reviewed. Add budgets and anomaly alerts at a scope that reaches a person who can act.

Then review the exceptions. Do not turn FinOps into a monthly meeting where somebody reads every line of the invoice aloud. Focus on what changed, why it changed, and who owns the next decision.

If your environment keeps drifting back after clean-up, Azure Managed Governance exists to keep that baseline visible. But even without a service, one named owner and a monthly delta review will beat a dashboard nobody is responsible for.