In this post, I will show you how to configure DevTest Labs to control what can be deployed by testers and developers, how much of it they can deploy, and importantly, what the cost of the service will be.
All settings for an Azure DevTest Lab can be found in Settings > Configuration And Policies. Here you can perform many things, including but not limited to:
By default, all virtual machine sizes are allowed. If you enable Allowed Virtual Machine Sizes, you can limit the available series/size of virtual machines that devs/testers can deploy.
The main cost of a DevTest Lab is the virtual machines that run in it, which are charged at the subscription’s normal virtual machine rates.
You can limit the number of machines that can be deployed in a DevTest Lab. This can be done per-user and/or per-lab. Both policies are enforced if you enable both and the lowest threshold will limit the users of the lab.
Both policies have identical settings:
An Azure customer only pays for virtual machines while the virtual machines are running. Performing a shutdown in the guest OS does not do an “Azure shutdown”. Note that other costs, such as storage, will still apply because they are not a part of the virtual machine runtime charge. You can minimize the costs of virtual machines by only running them at the required times.
You can automatically shut down virtual machines in several ways but Azure DevTest Labs allows you to configure a standard policy.
If you enable this policy, then the available settings are:
You might, but don’t have to, couple this by automatically starting virtual machines in the lab. If you do enable this policy then you can specify:
There can be costs associated with some Marketplace images. For example:
You can restrict which Marketplace images are used to create new virtual machines. Note that you can also supply custom images. If you choose to enforce restrictions, then you can search for and select images in Virtual Machine Bases > Marketplace Images.
In most “production” virtual machine scenarios, the costs are pretty predictable. Virtual machines either run all of the time or a planned amount of time and they each have a fixed per-minute run-time rate, based on the listed per-hour rate.
A DevTest Lab will be more fluid and very unpredictable. However, your quotas will limit the “damage” that devs and testers can do. You can track cost trends and manage a soft-spend threshold in Cost Tracking > Cost Trend. Various percentages of the soft-spend threshold can be used to create email alerts, be plotted on a chart, or trigger external processes to run via a webhook.
You can also track the costs of each resource created by users in the DevTest Labs in Cost Tracking > Cost By Resource.
A development and test can be a “wild west of IT” because of the bloat of machines, the ever-changing nature, and the constant changing needs of the business. However, with the above controls, you can control and understand the spending, while still giving developers and testers the flexibility to get work done in a timely manner.