Azure Policy has hundreds of built-in definitions. Cost governance has its own dedicated policy categories within the portal. And most engineering teams have zero cost-related policies enforced in their subscriptions — they have audit policies that surface violations nobody acts on, or they have nothing at all. This post is about three policies that, enforced correctly, prevent the most common cost architecture failures before they become budget conversations.
Why Audit Mode Is Not Governance
Azure Policy has three enforcement modes worth understanding: Audit surfaces violations in a compliance report. Deny blocks non-compliant resource creation. Modify auto-remediates at resource creation time, appending or replacing properties on resources before they land.
The mistake most teams make when implementing cost policies is defaulting to Audit mode because Deny “might break something.” That logic is understandable in the early days of a governance programme. It becomes self-defeating if Audit becomes the permanent state.
The accountability reality: If policies aren’t enforced, they’re not governance—they’re reporting. See Most Azure Governance Frameworks Are Policies Nobody Reads for how this gap becomes a permanent liability.
My Approach to Cleaning House: I always start with Audit mode to identify the “low hanging fruit” and the biggest spenders, but I don’t stay there long. When transitioning to Deny, I apply it to new resources only at first. This gives teams the breathing room to handle existing non-compliant debt without blocking their current work. For larger environments, I use the Management Group structure to roll this out in waves. The goal isn’t to surprise people; it’s to keep everyone in the loop early so that when the hard-stop arrives, it’s expected.
Policy 1: Restrict Expensive VM SKUs
The policy: deny creation of VM SKUs above a defined cost threshold without an explicit approval tag on the resource.
The built-in Azure Policy definitions for this — “Not allowed resource types” and “Allowed virtual machine size SKUs” — are blunt instruments. An allowlist of permitted SKUs means you must maintain the list as new SKU families are released. A tag-based approach is more operationally sustainable.
The Exemption Conversation: The most common pushback comes from Data Engineering and Machine Learning teams. They legitimately need heavier, memory-intensive machines for training or big data processing. However, even in those cases, I push for consumption-based resources in lower environments. The policy forces a conversation: “Do you really need this M-Series sitting idle, or can we move this to a containerized or serverless job?”
Assign this at the subscription level with exemptions for specific resource groups that legitimately house high-memory production workloads. Exempting at the resource group level rather than the subscription level keeps the policy meaningful for the 90% of resource groups where expensive SKUs are genuinely unexpected.
Policy 2: Enforce Auto-Shutdown on Non-Production Resources
The policy: require a shutdown-schedule tag on all VMs in non-production subscriptions, backed by an Azure Automation runbook.
The problem this solves is straightforward arithmetic. A VM running 168 hours per week costs roughly three times more than the same VM running 56 business hours. Non-production environments are rarely accessed outside business hours.
A $10,000 Lesson: I once worked with an organization that performed a “Lift and Shift” of their entire workload. They left their servers running 24/7/365, even though they only actually used them 3 or 4 times a week for a few hours at a time. They were paying over £10k a month for servers to sit there doing absolutely nothing. By teaching the team how to implement shutdown schedules, we didn’t just save money—we actually gave them the budget to run more instances in parallel when they did need them, speeding up their actual work.
Policy 3: Require Cost-Centre Tag at Resource Creation
The policy: a Modify mode policy that appends a cost-centre tag at resource creation if one is not already present, defaulting to an unallocated value.
The choice of Modify mode rather than Deny is intentional. A missing cost tag should not block resource creation — that creates friction that drives teams to work around governance. But an unallocated default in a cost report is a distinct, visible signal. Accountability shifts: instead of asking “where did this cost come from,” the question becomes “why does your team have unallocated resources this month?”
Making Policies Stick
Three policies in Deny mode will cause friction when first enforced. That friction is the point — it means the policies are working. But the change management side is consistently harder than the technical implementation.
Winning Over Developers: Developers will get frustrated by these restrictions—that’s a given. But I’ve found that the narrative is everything. If you explain that “we are doing this to save money so we can afford to extend your contract or fund that new project you’ve been wanting to start,” the resistance usually turns into collaboration. It’s about showing them that cost governance isn’t about saying “no”; it’s about making room for “yes” on the things that actually matter to them.
The right signal that governance is working is a decreasing trend in both Deny violations and Audit findings over time. The governance value of Azure Policy comes entirely from enforcement.
