Azure policies allow you to set rules for how your Azure environment will run. Microsoft Azure MVP and ShareGate's cloud architect Stephane Lapointe (@s_lapointe) recommends key Azure policies to help you manage and reduce your Azure costs.
There are several strategies to help keep your cost low in Azure. Among the top that comes to mind are right-sizing resources and cleaning unused resources. Those are great strategies, but they are reactive strategies, meaning that you’ll optimize or fix an issue after you notice the problem, and sometimes it's way later.
Another strategy is to prevent or catch problems before a resource is even created. In the same mindset as "Shift-left testing," the sooner you prevent something from happening, the smaller the impact it can have in your environment and on your bill.
Using Azure Policy is a great way to proactively stay in control of your Azure environment.
Whenever you’re using the REST API, Azure PowerShell, Azure CLI, or any Azure SDKs, Azure Policy acts as a middleman that inspects all your requests to Azure Resource Manager to ensure your policies are enforced. It enables you to audit, deny, or modify every resource in your environment.
And by managing what resources you’re using and how and where you’re using them, you can optimize your Azure spending.
This is the third and final blog in our series on Azure cost surveillance. You can read the first blog on cost efficiency habits to implement in your team or the second blog on Azure resources that can cause surprises in your bill for more Azure cost best practices.
Take control of your Azure spending—the easy way
No credit card required
Quick Azure Policy overview
This blog isn’t intended to be an Azure Policy 101 or fundamental article—if you need or want more information on Azure Policy, you can watch this Azure Policy essentials webinar I led with Microsoft’s Jussi Roine. But I thought it was important to do a quick overview of how Azure Policy works to make sure we’re all on the same page.
In a nutshell, when you assign a policy, you need to set at least 4 things, as shown below:
- Scope: This is the level at which your policy will be applied. You can select a Management Group, Subscription, or Resource Group, and all children will inherit that policy.
- Policy Definition: This is where you choose which policy definition you want to assign. You can select a built-in one or a custom policy you created. In this blog, I’m just going to be focusing on built-in policies.
- Policy Enforcement: A policy always has an effect configured that dictates what will happen if the policy condition is met. Enabled will honor the policy effect, Disabled will bypass the policy effect (i.e., it will deny the policy and won't deny resources), but it will still save the compliance state.
- Parameters: This is where you configure your policy (if applicable) and choose things like SKUs, Azure regions, etc.
Now that we’ve covered the very basics of assigning a policy, let’s continue with the 4 built-in policies that can help you control Azure costs if you use them wisely.
Controlling Azure costs through storage account SKUs
Policy: Allowed storage account SKUs
Azure description: This policy enables you to specify a set of storage account SKUs that your organization can deploy.
Make managing Azure costs fast, easy, and automated
Using this policy, you can decide that your organization wants to limit certain Azure Storage SKUs. Here is the list of possible SKUs at the time of writing this blog:
RAGRS and RAZGRS are storage options that provide extra high availability features in a paired Azure region or zone. There are cases where you’ll want to use them (for data resiliency, read fallback, etc.).
But in most cases, LRS or GRS is sufficient and will cost less to operate, so you can implement a policy that only allows those types of storage options to be deployed.
Always keep in mind that some parts of your business might require these more advanced and more expensive functionalities at some point—what you’re not using today might become a requirement tomorrow, so be flexible about changing your policies.
Setting VM size limits to prevent Azure cost spikes
Policy: Allowed virtual machine size SKUs
Azure description: This policy enables you to specify a set of virtual machine size SKUs that your organization can deploy.
Using this policy, you can decide that your organization wants to limit certain VM families and sizes. The list of possible SKUs is too big to fit in a screenshot but this will give you an idea of Azure's offerings:
This policy limits what VM families and SKUs can be used in your environment. In your organization, maybe you don’t need VMs with 16+ CPU cores or with a GPU.
Reducing human errors or poorly optimized solutions to run on big hardware will pay off in the end.
Optimizing costs through ‘not allowed’ resource types
Policy: Not allowed resource types
Azure description: This policy enables you to specify the resource types that your organization cannot deploy.
So far, we've seen policies that restrict SKUs on specific resource types (VM and Storage). In my opinion, among the best policies to prevent cost surprises is to control which resource types are allowed.
Again, the list of Azure resource types is way too long to fit in a screenshot, but here are some examples:
So, if you prefer to use storage queues, you might want to deny ServiceBus. Maybe Internet of things (IoT) or Machine Learning is outside of your playfield, so you don’t want people deploying them in your environment. That can be controlled using this policy.
There is also a policy named "Allowed resource types," it’s simply the opposite of this one and can be a double-edged sword. If you don’t fully grasp what you’re doing, it can lead to some vicious behaviors.
Filtering down what you don’t want with the "Not allowed resource types" is a better approach than blocking everything by default and whitelisting what you do want with the "Allowed resource types."
Trust me on this, I’ve been burned trying to block everything except those 54 resource types in the past. Things will stop working here and there in the portal and in scripts because you inevitably end up using resource types you didn’t think to whitelist before.
Deploying resources in strategic Azure locations
Policy: Allowed locations
Azure description: This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.
Of all things to consider when deploying to a region in Azure, cost should also be a factor. A resource in region A might not cost the same as in region B. Not all regions in Azure are alike.
You’ll want to select only the regions you are willing to work with in terms of resources types, availability, and latency for end users, but cost can definitely be a factor here. If you do your Azure region homework, you could save quite a bit.
I hope you enjoyed this tour of built-in Azure policies that can help you reduce your Azure spending. You can control a lot with these 4 policies, but they don’t cover it all. In a future article, we’ll see how to create your own custom policy definitions to have a finer control over resource configurations that can end up being extremely expensive like Ultra Disks and Application Insights.
If you're looking for more ways to optimize your Azure costs and to automate your cloud work, check out how ShareGate Overcast can save you time and money in Azure.
Happy cost management!
Want to make sure your Azure environment is running efficiently? Our checklist contains a complete action plan for reducing Azure costs—and keeping them where they should be. At ShareGate, we managed to save 30% on our Azure bill by following these exact tips.