Azure cost is not primarily a technical problem. It is an ownership problem wearing a technical costume. Every over-provisioned VM, every un-purchased reservation, every terabyte of hot-tier storage nobody has read in three years traces back to the same root cause: no single person had "Azure cost" as a deliverable, so the signals Azure was already sending went to nobody.
The tools to fix this are all built into Azure and mostly free to turn on. What's usually missing is the operating model that turns those tools into a monthly rhythm someone owns. This guide is that operating model — the one we deploy on a Cost & Governance engagement — in the order we deploy it. For the fast version of the symptoms, our companion insight on the five Azure cost leaks is the two-minute read; this is the system that keeps them plugged.
Layer 1: visibility you can act on
You cannot govern what you cannot see, and the default Azure cost view is not actionable — it's a total with no story. The first job is to make spend legible along the dimensions that map to decisions.
Azure Cost Management is the tool; the work is in how you slice it. The dimension that matters most is tags, because tags are how you answer "who spent this and why." A tagging strategy doesn't need to be elaborate — three tags carry most of the weight:
owner— the person or team accountable for the resource. This is the tag that turns an anonymous line item into a conversation.cost-center— how spend rolls up for chargeback or showback.environment— prod / non-prod / sandbox, so you can see at a glance what fraction of your bill is non-production (it's usually more than anyone expects).
Set up cost analysis views grouped by these tags, and configure budgets with alerts at the subscription and resource-group level so overspend surfaces as a notification, not a quarter-end surprise. Enable anomaly detection so a sudden spike pages someone the day it happens rather than showing up on next month's invoice.
The honest catch: tags only work if they're applied consistently, and humans are not consistent. Which is why visibility depends on the next layer.
Layer 2: policy guardrails
Governance that relies on people remembering to do the right thing is not governance. Azure Policy makes the right thing automatic and the wrong thing hard.
For cost specifically, the high-value guardrails are:
- Require
ownerandcost-centertags at creation. Deny resources without them, or auto-inherit from the resource group. This is what makes Layer 1's visibility real instead of aspirational — every resource is attributable by construction. - Restrict allowed SKUs and regions. Stop someone from spinning up a GPU VM family or a premium tier in a region you don't operate in. The best cost control is the expensive resource that was never created.
- Enforce auto-shutdown tags on non-prod compute, so the machinery in Layer 4 can act on them.
As with any policy rollout: deploy in audit mode first, see what the existing estate violates, remediate the backlog, then switch to deny. Flipping deny policies on over a live environment without looking first is how you break a deployment and lose your mandate.
Layer 3: commitment-based discounts
Pay-as-you-go is the most expensive way to run anything on Azure. For any workload with predictable, steady usage — which is most of production — you are leaving 30 to 60 percent on the table by not committing.
Two instruments, and the distinction matters:
- Azure Reservations commit you to a specific resource type (a VM size in a region, a SQL tier, Cosmos DB throughput) for one or three years in exchange for a steep discount. Best for stable, well-understood workloads you're confident will keep running as-is.
- Azure savings plans for compute commit you to an hourly dollar amount of compute for one or three years, and apply automatically across VM families and regions. More flexible than reservations, slightly smaller discount. Best when your compute mix shifts but your baseline spend is stable.
The practical failure modes are both about neglect, not analysis: teams that never buy any because they "didn't have time to model it," and teams that bought three years ago and never renewed because the renewal email got missed — Azure does not auto-renew. Both are fixed by making commitment analysis a recurring task with an owner, which is Layer 4.
Azure's own Cost Management surfaces reservation and savings-plan recommendations based on your actual usage. You do not need a third-party tool to start — you need someone whose job it is to read the recommendation and act on it.
Layer 4: the right-sizing cadence
Commitments handle the workloads you keep as-is. Right-sizing handles the workloads that are simply too big. Premium SKUs chosen at deployment because someone clicked the recommended option, VMs running at 12% utilization, SQL tiers provisioned for a load test that ended a year ago — this is pure waste, and it accumulates silently.
Azure Advisor generates the right-sizing list for you automatically: underutilized VMs, idle resources, unattached disks, and the specific SKU downgrades it recommends. The list is not the hard part. The hard part is that acting on it requires someone to own the review, validate each recommendation against real workload behavior, and make the change.
So make it a cadence, not a project:
- Monthly: review Advisor cost recommendations, act on the safe ones (unattached disks, obviously idle resources), and queue the ones that need validation.
- Non-prod, always: auto-shutdown schedules on dev and staging compute (built into Azure, free), and storage lifecycle policies moving cold blobs down the tiers. This alone is routinely 40–60% of non-prod spend.
- Quarterly: the commitment review from Layer 3 — buy new reservations for newly-stable workloads, renew expiring ones.
None of these are clever. All of them are skipped when nobody owns them.
Layer 5: chargeback, showback, and the ownership problem
Here is the layer that decides whether the other four hold. You can build perfect visibility, guardrails, commitments, and a right-sizing cadence — and watch it all erode within two quarters if the people spending the money never see the bill.
Showback means reporting each team's Azure spend back to them, using the tag structure from Layer 1, so cost becomes visible to the people who create it. Chargeback goes further and actually allocates the cost to their budget. Even showback alone changes behavior remarkably — a team that sees its own monthly Azure number, broken out by resource, starts asking its own questions. Cost governance stops being the platform team nagging and becomes each team managing its own line.
This is the resolution of the ownership problem we opened with. The tags make spend attributable. The showback report makes it visible to the owner. The owner, now able to see their waste, acts on it — because it's finally theirs.
What it looks like in practice
This operating model reflects the cost-governance work David Faleye has performed during his engineering career. It describes the capability behind a Falstech engagement; it is not presented as one Falstech client result. Client outcomes will be published separately only when the engagement and evidence can be verified and disclosed.
Where to start
Don't try to stand up all five layers at once. Start with visibility and tagging — you cannot manage what you can't attribute. Add the policy guardrails so the tags stay honest. Then commitments (the biggest single dollar lever), then the right-sizing cadence, and finally the showback reporting that makes it self-sustaining. Each layer makes the next one work better.
If your bill has gotten away from you and you want a structured engagement to map it, plug the leaks, and install the operating model that keeps them plugged, that's the Cost & Governance service — book a discovery call and we'll tell you roughly where the recoverable spend is before you commit to anything.