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.
Configuration All Policies
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:
- Cost monitoring and analysis
- Control what virtual machine series/sizes can be deployed
- Set up lab-wide or per-user quotas
- Enable/configure auto-shutdown and/or auto-start
- Define the available Marketplace and custom images
Allowed Virtual Machine Sizes
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.
Virtual Machines Per User/Lab
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:
- Do you want to limit the number of virtual machines?
- If so, what is the limit?
- Do you want to limit how many machines can use Premium (SSD) Storage?
- If so, how many Premium Storage-enabled machines should you allow?
Auto-Shutdown and Auto-Start
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:
- What time will virtual machines in the lab shut down start at?
- What time zone is that time in?
- Should you send a notification before the shutdown?
- If so, do you want to trigger a webhook (external process via URI) or send an email?
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:
- The time of day the startups will begin
- What time zone you are working in
- What days of the week you want the lab virtual machines to start up on
There can be costs associated with some Marketplace images. For example:
- All Windows virtual machines include the cost of Windows Server (per processor).
- Any virtual machine image with included paid-for software, such as SQL Server Standard, will have an additional software cost.
- Some Linux distros have an additional cost.
- There might be costs for expensive third-party appliances or software that will be automatically charged by Microsoft as soon as they are deployed.
- Some images are larger/smaller than others and this can impact storage costs.
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.