DTL helps developers within teams to efficiently self-manage virtual machines (VMs) and PaaS resources without waiting for approvals, providing a worry-free self-service environment. It adds great value for key scenarios, especially when you're getting started on Azure, such as developer desktops, test environments, training sessions and sandboxed investigations. The built-in lab policies and thresholds help to effortlessly reduce costs.
This article includes recommendations across Management group and Subscription topology, Networking, Identity, Enterprise Agreement offers, Application automation, and Security for DevTest workloads in the context of DTL.
Enterprises migrating DevTest workloads at large scale can benefit from setting up this enterprise-scale architecture and can achieve:
Reduced operational overhead for application teams as they can focus on their application development/testing with DTL and leave all the platform management, networking, security, and identity setup with a Central IT team.
Centralized enforcement of organizational compliance across DevTest workloads.
Potential Use Cases
This architecture is useful for organizations who require:
A fully integrated operations control plane for DevTest workloads from the start.
A clear separation of concerns between platform and application workloads.
Traditionally, this architecture would serve as a starting point for large-scale deployments of DevTest workloads across subscriptions.
The application team’s responsibility lies with provisioning the core DTL resources in the DevTest subscriptions, shown in the bottom-right of the following diagram. Doing so uses the already set up foundation. The policies applied to Management groups trickle down to the DevTest subscription and resources.
Although DTL alone doesn't have built-in limits, other Azure resources used in the lab might extend beyond the Azure subscription limits. In these cases, multiple Azure subscriptions might be needed to cover large deployments of DTL.
The Network Administrator creates a spoke VNet and other network resources like NSG, UDR in the network resource group that is peered with the hub VNet. The peering is created by Azure policies assigned to the Corp management group per the ESLZ automation. This peering lets corporate users access the lab VMs over VPN/ExpressRoute with a private IP.
The Lab Owner configures built-in Lab policies per project requirements. You can review all available policies at Manage all policies for a lab in Azure DevTest Labs. Here are a few policies relevant to this article:
Configure the virtual network setting so that all lab VMs are created in the spoke VNet.
Configure lab settings so that all lab VMs are created in the designated Lab resource group. In this way, they won't be distributed across multiple resource groups.
Enable Browser Connect to use the Bastion host deployed in hub VNet to secure RDP/SSH access to lab VMs over Internet without public IP.
Configure Lab users and assign appropriate roles based on least privilege. DTL provides three built-in roles – Owner, Contributor, and User.
Configure the domain join artifact as a mandatory artifact in the lab if there's a requirement to domain join the Lab virtual machine.
Configure a private GitHub/ADO repository in the lab for artifacts and environment templates. The repository can be used to store application codebase as well.
The Application Team can spin up the Lab resources (VMs and PaaS environments) manually or they can set up Azure Pipelines to deploy resources using DTL tasks.
Enterprise-scale landing zone (ESLZ) is an architectural approach and a reference implementation that enables effective construction and operationalization of landing zones on Azure, at scale. Azure Landing Zones are the output of a multi-subscription Azure environment that accounts for scale, security, governance, networking, and identity. DTL can be deployed in the DevTest landing zone or sandbox subscription as discussed in Management group and subscription topology.
Azure DevTest Labs (DTL) is a fully managed service that developers and testers use to quickly provision development and test environments. DTL lets users create virtual machines and PaaS resources. While VM creation is supported natively, creation of PaaS resources can be achieved using environment templates.
Let you control costs and minimize waste in your labs by managing policies (settings) for each lab. Using DTL policy, you can minimize lab waste by specifying which VM sizes are allowed in the lab. If this policy is active, only VM sizes from the list can be used to create VMs.
Hub and spoke configurations
Provide benefits that include cost savings, overcoming subscription limits, and workload isolation. The hub virtual network acts as a central point of connectivity to many spoke virtual networks and to on-premises networks. The spoke virtual networks peer with the hub and can be used to isolate workloads. DTL can be placed in the spoke network so that Enterprises can have a central control over security features, such as a firewall in the hub as a DMZ, Express Route/VPN connectivity, and segregated management for the workload. Traditionally, the VNets, including the spoke VNet, is provided by the platform administrator. The app team can provision the DTL in the specified subnet.
Azure Bastion is a fully managed service that provides more secure and seamless Remote Desktop Protocol (RDP) and Secure Shell Protocol (SSH) access to VMs without any exposure through public IP addresses. DTL can use the Bastion host to securely RDP/SSH to VMs without exposing them directly over the Internet as discussed in Networking Topology. By default, DTL allows connectivity to VM through Public IP or Shared Public IP.
DTL artifacts let you specify actions that are performed when the VM is provisioned, such as running Windows PowerShell scripts, running Bash commands, and installing software. Artifact parameters let you customize the artifact for your scenario. The public artifact repository, maintained by DevTest Labs, provides many common tools for both Windows and Linux. A link to this repository is automatically added to your lab.
Azure DevTest Labs
A formula in Azure DevTest Labs is a list of default property values used to create a virtual machine.
DTL environments let users deploy complex infrastructures in a consistent way within the confines of the lab. You can use Azure Resource Manager templates to create environments with sets of resources in DevTest Labs. These environments can contain any Azure resources that Resource Manager templates can create.
Customers can build a solution similar to DevTest Labs by putting together multiple services with Azure native features like Policies, RBAC Groups, VM Extensions, and Automation.
The primary advantage of using DevTest Labs is its out-of-the-box integrated features and intuitive interface, which makes it easy for new users (Admins and Developers) who don't have deep skills on Azure. In this way, DTL, saves time and effort in implementation and maintenance.
Enterprise Agreement for DevTest
Enterprise Agreement customers have a great way to run their development and testing workloads on Azure by signing up for lower rates on dev/test workloads as described at Enterprise Dev/Test. Enabling the DevTest subscription within the Azure Enterprise portal lets an organization:
Run client operating systems that aren't typically available in an Azure enterprise subscription
Use enterprise software in which they pay only for the compute
Feel confident about licensing
Security and Compliance
This security baseline applies guidance from the Azure Security Benchmark version 2.0 to DTL.
The following links address governance and compliance for DTL: