I’ve seen it too many times. It all starts when somebody is given access to a new “production” Azure subscription that’s pay-as-you-go. A new resource is created for the first time on a Friday, running up costs over the weekend, resulting in a surprisingly large bill. The cloud is too expensive!
To help prevent these types of scenarios and do our best to have a predictable Azure bill, we can configure our subscriptions with the following tips in mind.
Use Free Azure Credits
Allow developers to use their free Azure credits included with their Visual Studio subscriptions (no credit card required). Developers should be using this as their playground to learn and experiment. When you reach the monthly cap for your credits, your Azure services will stop until your next monthly credits are added. This is up to $150 a month for some subscriptions. More info here.
Setup Management Groups
Setup Management groups for Non-Production and Production to keep them segmented. Put policies on each so that when you create a subscription and dump it into a group, it inherits all of the policies and things you’ve setup for them.
Restrict Production Access
Do not allow your developers access to deploy directly to production. Nothing should be manually setup in production for the first time. Everything should be deployed through a CI/CD pipeline. The pipeline should provide governance and quality gates to the production resources. For Azure Pipelines you can use controls like: pipeline, service connection, and agent pool permissions, and approvals and checks to require manual approvals or templates on production resources.
Setup Budgets
Setup budgets for development and test environments to prevent overspend. These environments should not contain “production” resources, so you can shut them down once the budget is reached. After the fact, analyze unexpected charges, identify ways to optimize costs, or increase budget. Alerts can be setup to notify you when spending exceeds a certain amount.
Use ARM Policies
Setup Azure resource manager policies to restrict the creation of certain resources, like large VM sizes. Policies can also be setup to do things like shutdown all VM’s at night, unless they’re part of an exclusion list.
Azure DevTest Labs
Consider using Azure DevTest Labs to provision development and test environments, setting lab policies to only allow certain VM sizes and auto shutdown policies.
This list is by no means comprehensive. Hopefully you’re already doing most of this, but found a tip or two to be helpful.