Azure Cost Management: how to identify and eliminate waste in 20 minutes per month

Cost optimization in the cloud almost always fails in the same way. Someone does a big cleanup, cuts 30% of the bill, everyone is happy — and in six months the cost is back to where it started, because in the meantime new resources have been created and no one looked again.

The difference between a cleanup and a process is that the process has a rhythm and lasts short enough so it is not postponed. This article is about building that process in Azure.

So far we have talked about architecture: Function plans, scaling rules, configuration parameters. Now we move to tooling — because, in the absence of visibility, all previous decisions silently degrade.

Step zero: tagging, or why you can’t answer any question

Open Cost Analysis on an untagged subscription and try to answer: how much does the staging environment cost us? Or: how much does client X cost? Or: what part of the bill belongs to product A compared to product B?

You can’t. You can see that you spent an amount on App Service, but you can’t separate production from test, because the platform doesn’t know the difference. And a bill you can’t segment is a bill you can’t act on.

Tagging is the infrastructure on which everything else rests. My recommendation: a minimal set, applied consistently, is infinitely more valuable than an elaborate taxonomy followed by half the team.

• Environment — prod / staging / dev
• Application — the name of the product or service
• Owner — the responsible team or person
• CostCenter — if you need accounting allocation

Four tags. That’s it.

Manual tagging doesn’t work

This is not an opinion, it is an empirical observation. Any process that depends on someone’s discipline at 6:30 PM on Friday, when they quickly create a resource for a test, will have gaps.

The solution is to move tagging application to two automated places:

In Infrastructure as Code. If resources are created through Bicep or Terraform, tags are part of the definition and cannot be missing:

param environment string
param application string

var standardTags = {
  Environment: environment
  Application: application
  Owner: 'platform-team'
  ManagedBy: 'bicep'
}

resource app 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  tags: standardTags
  properties: { ... }
}

In Azure Policy. For what slips through, policies can automatically inherit tags from the resource group or can directly block the creation of a resource without the mandatory tags. The second option is aggressive but works — and it is the only one that guarantees full coverage.

A missing tag is not a cleanup issue. It is a line on the bill you will never be able to answer “whose is it?”.

Cost Analysis: the four views that matter

Cost Analysis offers many combinations of filters and groupings. In practice, four cover almost everything.

1. Grouped by Resource, sorted descending

The simplest and most useful. The first five to ten lines usually represent most of the bill. The question for each: do I know why it is there and is it proportional to the value it produces?

2. Grouped by the Environment tag

This is where the real surprises appear. If non-production environments exceed 25–30% of the total, you have a significant problem — and usually one that is easy to fix by scheduled shutdown.

3. Grouped by Service, over 6 months, as a chart

The absolute value matters less than the slope. A service that grows steadily without traffic increasing is a signal. Log Analytics and Application Insights are usual suspects: they grow with log volume, not business volume.

4. Cost per business unit

This is not native, but it can be built: you export the monthly cost, divide it by the number of active tenants, clients, or processed documents, and track the series over time.

It is the only metric on which you can say whether your architecture scales economically. Total cost always increases when the business grows — that tells you nothing. The cost per unit should decrease.

Budgets and alerts: moving feedback closer to decision

In the first article I said the cloud feedback loop is temporally broken — the effect of a decision appears 30 days later. Budgets are the tool that fixes this.

An Azure budget doesn’t stop anything (although it can trigger an Action Group that stops). It is a threshold with alerts. The key is to configure alerts on forecasted cost, not just on actual cost.

The difference is essential: an alert at 100% of actual cost tells you that you have exceeded the budget — too late. An alert at 80% of the forecasted cost tells you on the 12th of the month that, at the current pace, you will exceed the budget. You have time to intervene.

The configuration I use:

• One budget per environment, based on the Environment tag
• Alert at 80% of forecast — warning, sent by email
• Alert at 100% of forecast — investigation, also sent to the team channel
• Alert at 100% actual — escalation

Anomaly detection: the alert that catches what you didn’t foresee

Budgets catch slow growth. They don’t catch sudden jumps in a service that was small anyway — because the total remains below the threshold.

Anomaly detection looks at pattern, not absolute value. A service that cost 3 dollars a month and suddenly jumps to 40 is an anomaly, even if 40 dollars doesn’t trigger any budget. Usually it means a loop, a retry without backoff, or a job running much more often than it should.

It’s free to activate and it is the only alert that catches the class of problems “something broke and costs money”.

The hunt for orphaned resources

This category appears in almost any subscription older than a year, because deletions in Azure are often partial. You delete a virtual machine, the disk remains.

Usual suspects:

• Unattached disks — left after deleted VMs, fully billed
• Reserved public IP addresses — unused but allocated
• Old snapshots — created “before migration”, never cleaned
• Load balancers and NAT Gateways without backend
• Empty App Service Plans — deleted apps, plan remains, billed at its tier

Azure Advisor flags some of them, but not all. For a quick inventory, Resource Graph is more efficient than any portal click:

resources
| where type =~ 'microsoft.compute/disks'
| where properties.diskState == 'Unattached'
| project name, resourceGroup, location,
          sizeGB = properties.diskSizeGB,
          sku = sku.name
| order by sizeGB desc

The same logic applies for public IPs without ipConfiguration or for plans without associated sites. A saved query, run once a month, covers everything.

The 20-minute monthly audit

Here everything ties together. The process must be short enough not to be postponed — otherwise it is not a process, it is an intention.

1. (3 min) Cost Analysis, last month vs. previous month, grouped by Service. What grew by more than 15%?
2. (3 min) Grouped by the Environment tag. What percentage is non-production?
3. (5 min) Run Resource Graph queries for orphaned resources. Delete what is obviously dead.
4. (3 min) Open Azure Advisor, Cost section. Are there new right-sizing recommendations?
5. (3 min) Check resources without tags. How many? Who created them?
6. (3 min) Update the cost per business unit metric. Is it rising or falling?

Twenty minutes, once a month, in the calendar as a recurring event. It’s not glamorous. It’s the only option that works long term.

Conclusion

The tools in Azure Cost Management are good and, for the most part, free. The problem is never the tooling — it’s that no one has scheduled the moment to look at it.

If you remember one thing from this article: apply tags automatically, through IaC or Policy. Without segmentation, the rest of the tools show you numbers you can’t assign to anyone and therefore no one can act on.

In the last article of the series we talk about the financial side: Reserved Instances, Savings Plans, and pay-as-you-go — what you commit to, for how long, and why the right strategy is almost always layered, not a single choice.