{"id":421,"date":"2026-04-14T00:08:14","date_gmt":"2026-04-14T00:08:14","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-devtest-labs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools\/"},"modified":"2026-04-14T00:08:14","modified_gmt":"2026-04-14T00:08:14","slug":"azure-devtest-labs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-devtest-labs-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-developer-tools\/","title":{"rendered":"Azure DevTest Labs Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Developer Tools"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Developer Tools<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure DevTest Labs is an Azure service designed to help teams create and manage dev\/test environments quickly, safely, and cost-effectively\u2014without requiring every developer to be an Azure infrastructure expert.<\/p>\n\n\n\n<p>In simple terms: <strong>Azure DevTest Labs lets you create \u201ca lab\u201d where developers can spin up pre-approved virtual machines (VMs) and environments, with guardrails like auto-shutdown, quotas, and allowed VM sizes<\/strong>. This reduces cloud waste and improves consistency across teams.<\/p>\n\n\n\n<p>Technically, Azure DevTest Labs is a <strong>policy-driven management layer<\/strong> over Azure IaaS (primarily Azure Virtual Machines, networking, and storage). A \u201clab\u201d is an Azure resource that provisions and governs compute in a subscription\/resource group using lab-wide settings (like allowed images\/sizes), per-user quotas, schedules (auto-shutdown\/auto-start), and reusable templates (formulas, artifacts, and ARM-template-based environments).<\/p>\n\n\n\n<p>It solves a common problem in engineering organizations: <strong>dev\/test cloud sprawl<\/strong>. Without guardrails, dev\/test VMs are often oversized, duplicated, left running overnight, and deployed inconsistently\u2014leading to higher bills, security drift, and operational headaches.<\/p>\n\n\n\n<blockquote>\n<p>Service status note: <strong>Azure DevTest Labs<\/strong> is a long-running Azure service and remains available in the Azure portal at the time of writing. Azure has also introduced newer developer-environment options (for example, Microsoft Dev Box and Azure Deployment Environments). If you\u2019re starting new platform initiatives, <strong>verify the latest positioning and roadmap in official documentation<\/strong>.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure DevTest Labs?<\/h2>\n\n\n\n<p><strong>Official purpose<\/strong><br\/>\nAzure DevTest Labs helps development and test teams <strong>quickly create environments in Azure while minimizing waste and controlling cost<\/strong> through policies and automation.<\/p>\n\n\n\n<p><strong>Core capabilities<\/strong>\n&#8211; Create dev\/test VMs from curated base images (Marketplace, custom images, Shared Image Gallery\/Azure Compute Gallery images\u2014depending on your configuration).\n&#8211; Apply <strong>lab policies<\/strong> (allowed VM sizes, allowed images, VM count limits, auto-shutdown requirements, etc.).\n&#8211; Enforce <strong>cost controls<\/strong> (e.g., auto-shutdown schedules, quotas, and governance patterns).\n&#8211; Standardize VM configuration using <strong>artifacts<\/strong> (post-deploy actions like installing software) and <strong>formulas<\/strong> (reusable VM definitions).\n&#8211; Enable <strong>self-service<\/strong> provisioning with guardrails (developers can create what they need within constraints).<\/p>\n\n\n\n<p><strong>Major components<\/strong>\n&#8211; <strong>Lab<\/strong>: The main DevTest Labs resource. It holds policy, configuration, and artifacts\/formulas.\n&#8211; <strong>Lab virtual machines<\/strong>: Azure VMs created \u201cinside\u201d the lab, governed by lab settings.\n&#8211; <strong>Artifacts<\/strong>: Reusable deployment actions (scripts\/packages) to install and configure software on VMs.\n&#8211; <strong>Formulas<\/strong>: \u201cGolden\u201d VM definitions (base image + size + artifacts + settings) for consistent provisioning.\n&#8211; <strong>Policies<\/strong>: Rules and limits controlling what can be created and when it runs.\n&#8211; <strong>Users\/Access<\/strong>: Azure RBAC access to the lab resource and related resource groups\/resources.\n&#8211; <strong>Networking<\/strong>: Lab VNet options (create new or use existing, depending on supported configurations and permissions).<\/p>\n\n\n\n<p><strong>Service type<\/strong>\n&#8211; Azure resource provider: <strong>Microsoft.DevTestLab<\/strong>\n&#8211; Category fit: <strong>Developer Tools<\/strong>, with strong overlap into cost governance and self-service infrastructure.<\/p>\n\n\n\n<p><strong>Scope (subscription\/resource grouping)<\/strong>\n&#8211; A lab is created within an <strong>Azure subscription<\/strong> and placed in a <strong>resource group<\/strong>.\n&#8211; The lab then provisions Azure resources (VMs, NICs, disks, public IPs, VNets, etc.) into resource groups according to lab configuration.\n&#8211; Most governance is applied at the <strong>lab level<\/strong>, with additional constraints possible via Azure Policy at the subscription\/resource group level.<\/p>\n\n\n\n<p><strong>Regional\/global\/zonal considerations<\/strong>\n&#8211; Azure DevTest Labs is generally <strong>regional<\/strong>, because it provisions <strong>regional resources<\/strong> (VMs, managed disks, VNets).\n&#8211; Feature availability (images, VM sizes, underlying compute features like Availability Zones) depends on the <strong>Azure region<\/strong> and the chosen VM SKU. <strong>Verify region support in official docs<\/strong>.<\/p>\n\n\n\n<p><strong>How it fits into the Azure ecosystem<\/strong>\nAzure DevTest Labs sits between:\n&#8211; <strong>Developers\/testers<\/strong> who need fast self-service environments, and\n&#8211; <strong>Azure governance\/operations\/security<\/strong> teams who need guardrails (cost control, compliance, least privilege, standardized builds)<\/p>\n\n\n\n<p>It integrates naturally with:\n&#8211; <strong>Azure Virtual Machines<\/strong> (core compute)\n&#8211; <strong>Azure Virtual Network<\/strong> (networking and isolation)\n&#8211; <strong>Azure Monitor<\/strong> (metrics\/logs for VMs and platform activity)\n&#8211; <strong>Azure RBAC<\/strong> and <strong>Microsoft Entra ID<\/strong> (identity and authorization)\n&#8211; <strong>Azure Policy<\/strong> (organization-wide controls, complementary to lab policies)\n&#8211; <strong>Azure Compute Gallery (formerly Shared Image Gallery)<\/strong> for curated images (common in mature enterprises)\n&#8211; CI\/CD and automation tooling (Azure DevOps, GitHub Actions, PowerShell, ARM\/Bicep, REST APIs\u2014verify the latest task\/extensions availability)<\/p>\n\n\n\n<p>Official docs entry point:<br\/>\nhttps:\/\/learn.microsoft.com\/azure\/devtest-labs\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure DevTest Labs?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower cloud spend for non-production<\/strong>: Auto-shutdown and quotas reduce \u201cforgotten VM\u201d costs.<\/li>\n<li><strong>Faster time-to-environment<\/strong>: Developers don\u2019t wait for ops tickets; they self-serve within constraints.<\/li>\n<li><strong>Standardization<\/strong>: Formulas\/artifacts reduce configuration drift and \u201cworks on my machine\u201d issues.<\/li>\n<li><strong>Chargeback\/showback alignment<\/strong>: Labs can be organized by team\/project with clear ownership tags and budgets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Curated images and sizes<\/strong>: Limit VM SKUs to what\u2019s approved (security, cost, compatibility).<\/li>\n<li><strong>Repeatable VM builds<\/strong>: Formulas + artifacts create consistent environments.<\/li>\n<li><strong>Controlled networking<\/strong>: Labs can be aligned to standard network segmentation patterns (within supported capabilities).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policy-driven operations<\/strong>: Centralized rules for shutdown, quotas, and allowed configurations.<\/li>\n<li><strong>Reduced toil<\/strong>: Less manual provisioning; fewer exceptions.<\/li>\n<li><strong>Lifecycle hygiene<\/strong>: Claimable VMs, expiration, and schedules help keep environments current.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Least privilege<\/strong> via Azure RBAC: developers can be restricted to lab resources.<\/li>\n<li><strong>Approved images<\/strong>: helps avoid unpatched\/unapproved OS images.<\/li>\n<li><strong>Network boundary control<\/strong>: supports patterns where dev\/test is isolated from production networks.<\/li>\n<li><strong>Auditing<\/strong>: Azure Activity Log visibility plus VM diagnostics via Azure Monitor.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Scaling is mainly determined by underlying Azure Compute limits (VM quotas, regional capacity).<\/li>\n<li>DevTest Labs improves <strong>operational scalability<\/strong> (many developers self-serving) rather than improving VM performance itself.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Azure DevTest Labs<\/h3>\n\n\n\n<p>Choose it when you need:\n&#8211; Self-service dev\/test VMs for teams\n&#8211; Guardrails to control cost and sprawl\n&#8211; Standard VM setups through reusable configurations\n&#8211; A lab \u201clanding zone\u201d for development teams that is faster than building a custom portal<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Avoid (or reconsider) when:\n&#8211; You primarily need <strong>PaaS<\/strong> environments rather than VMs (consider ARM\/Bicep + platform automation; Azure Deployment Environments may be a better fit\u2014verify).\n&#8211; You need <strong>managed developer desktops<\/strong> with centralized policy, identity integration, and lifecycle at scale (evaluate Microsoft Dev Box\u2014verify).\n&#8211; Your org already has a mature internal developer platform with golden images, budgets, quotas, and self-service workflows; DevTest Labs may overlap or add another layer.\n&#8211; You require features outside DevTest Labs\u2019 current scope (for example, advanced multi-region orchestration, deep environment catalog with approvals, etc.).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure DevTest Labs used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Software\/SaaS<\/li>\n<li>Financial services (sandboxed dev\/test with tight guardrails)<\/li>\n<li>Healthcare and life sciences (controlled access, standardized builds)<\/li>\n<li>Retail\/e-commerce (feature testing, load testing labs)<\/li>\n<li>Education\/training departments (though Azure Lab Services is often evaluated for classroom scenarios\u2014verify best fit)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Application development teams<\/li>\n<li>QA and test automation teams<\/li>\n<li>DevOps\/platform engineering teams providing self-service<\/li>\n<li>Security engineering teams that want standardized images and reduced shadow IT<\/li>\n<li>Consulting\/partner teams building repeatable demo\/test environments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Dev\/test VMs for application development<\/li>\n<li>Integration test environments<\/li>\n<li>Build agents (self-hosted, ephemeral, or scheduled\u2014depending on your strategy)<\/li>\n<li>PoC and prototype environments<\/li>\n<li>Training labs for internal teams (with cost controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures and deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single team lab per product<\/li>\n<li>Shared lab per department with per-user quotas<\/li>\n<li>Enterprise hub-and-spoke network with labs in spokes<\/li>\n<li>Hybrid orgs where dev\/test is in Azure while production is elsewhere (or on-prem)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<p>Azure DevTest Labs is designed for <strong>non-production<\/strong> environments. While it provisions standard Azure resources, using it for production is usually not the intent because:\n&#8211; its policies are optimized for cost control and self-service,\n&#8211; the operational model is different from production landing zones,\n&#8211; production typically requires stricter change control and availability patterns.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Azure DevTest Labs fits well.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Standardized developer VMs with auto-shutdown<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Developers create VMs manually, leave them running, and use inconsistent configurations.<\/li>\n<li><strong>Why it fits<\/strong>: Lab policies enforce auto-shutdown and constrain VM sizes\/images.<\/li>\n<li><strong>Example<\/strong>: A .NET team provisions Windows or Ubuntu dev VMs that automatically shut down at 7 PM local time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) QA test rigs for reproducible testing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: QA needs consistent test machines and fast rebuilds when tests fail.<\/li>\n<li><strong>Why it fits<\/strong>: Formulas + artifacts allow rebuilding a known baseline quickly.<\/li>\n<li><strong>Example<\/strong>: QA rebuilds an \u201cSelenium Test Agent\u201d VM formula with browser + drivers + test tools.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Disposable PoC environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Proof-of-concept projects create cloud sprawl and surprise bills.<\/li>\n<li><strong>Why it fits<\/strong>: Quotas and schedules reduce risk; expiration policies encourage cleanup.<\/li>\n<li><strong>Example<\/strong>: A team spins up a short-lived VM for evaluating a new database connector.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Shared \u201cclaimable\u201d VMs for expensive tooling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Some tools require high-memory VMs; giving one per developer is too expensive.<\/li>\n<li><strong>Why it fits<\/strong>: Claimable VMs can be shared across a team under policy controls.<\/li>\n<li><strong>Example<\/strong>: A graphics\/rendering team shares a few larger VMs that developers claim when needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Golden image rollout and controlled experimentation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security needs patch-compliant images; developers need flexibility.<\/li>\n<li><strong>Why it fits<\/strong>: Approved images can be curated; artifacts can add dev tools without breaking baselines.<\/li>\n<li><strong>Example<\/strong>: Security publishes a monthly patched image; devs use artifacts to add language runtimes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Self-hosted build\/test agents with schedules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Build agents run 24\/7 though pipelines run only business hours.<\/li>\n<li><strong>Why it fits<\/strong>: Auto-start\/auto-shutdown schedules reduce compute time.<\/li>\n<li><strong>Example<\/strong>: A nightly build VM starts at 1 AM, runs tests, then shuts down automatically.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Hackathon \/ internal innovation labs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Events require fast provisioning and cost ceilings.<\/li>\n<li><strong>Why it fits<\/strong>: Labs provide self-service with quotas and allowed SKUs.<\/li>\n<li><strong>Example<\/strong>: A 3-day hackathon uses a lab with strict VM size limits and daily shutdown.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Vendor demo and sales engineering environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Demo environments must be consistent and easy to reset.<\/li>\n<li><strong>Why it fits<\/strong>: Formulas and artifacts standardize demos; environments can be rebuilt quickly.<\/li>\n<li><strong>Example<\/strong>: Sales engineers deploy a demo VM with preinstalled sample data and demo scripts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Secure sandbox for untrusted code testing<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need isolation to run potentially risky tests.<\/li>\n<li><strong>Why it fits<\/strong>: Labs can be placed in isolated VNets with limited inbound\/outbound.<\/li>\n<li><strong>Example<\/strong>: A security team runs malware-analysis-like behavior testing in isolated dev\/test VMs (with strong controls).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Migration rehearsal environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams need temporary environments to test migration steps.<\/li>\n<li><strong>Why it fits<\/strong>: Quick provisioning with known VM baselines; cleanup enforced.<\/li>\n<li><strong>Example<\/strong>: A team creates a VM to rehearse a legacy app upgrade or data migration script.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Training environments for internal enablement<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Trainers need consistent lab machines and predictable cost.<\/li>\n<li><strong>Why it fits<\/strong>: Controlled images and auto-shutdown prevent runaway spend.<\/li>\n<li><strong>Example<\/strong>: An internal course provides one VM per attendee for two days, with strict quotas.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Development environments with network access to shared dev services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Developers need VMs that can reach dev databases, caches, or internal APIs.<\/li>\n<li><strong>Why it fits<\/strong>: Labs can be configured to use specific VNets\/subnets aligned to dev shared services.<\/li>\n<li><strong>Example<\/strong>: A lab VM sits in a dev subnet with controlled access to an Azure SQL dev instance.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Feature availability can vary by region and by the service\u2019s current state. Always <strong>verify in official docs<\/strong> for the latest behavior.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Lab policies (guardrails)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Controls what users can create (VM sizes, images), how many they can create, and how resources behave (shutdown schedules).<\/li>\n<li><strong>Why it matters<\/strong>: Prevents sprawl and enforces organization standards.<\/li>\n<li><strong>Practical benefit<\/strong>: Lower costs, fewer security exceptions, less operational clean-up.<\/li>\n<li><strong>Caveats<\/strong>: Lab policies complement but do not replace <strong>Azure Policy<\/strong>. Use Azure Policy for subscription-wide enforcement.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Auto-shutdown schedules<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Shuts down lab VMs at specified times (and can optionally notify users).<\/li>\n<li><strong>Why it matters<\/strong>: Most dev\/test waste is from compute running idle.<\/li>\n<li><strong>Practical benefit<\/strong>: Significant reduction in monthly compute hours.<\/li>\n<li><strong>Caveats<\/strong>: Shutdown stops compute charges but disks and some IP resources may still incur costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Quotas and per-user limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Limits number of VMs per user, total VMs, and potentially allowed VM sizes.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents one user or team from exhausting budget or quotas.<\/li>\n<li><strong>Practical benefit<\/strong>: Predictable spend and capacity.<\/li>\n<li><strong>Caveats<\/strong>: Underlying Azure quotas (regional vCPU quotas, public IP quotas) still apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Artifacts (post-deploy configuration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Applies scripts\/packages to configure a VM after provisioning (install tools, set registry, configure services).<\/li>\n<li><strong>Why it matters<\/strong>: Speeds up and standardizes VM setup.<\/li>\n<li><strong>Practical benefit<\/strong>: New VM becomes \u201cdeveloper-ready\u201d in minutes.<\/li>\n<li><strong>Caveats<\/strong>: Artifact success depends on network access (package repos), OS compatibility, and script reliability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Formulas (reusable VM definitions)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Saves a VM \u201crecipe\u201d (image + size + artifacts + settings) so users can create consistent VMs repeatedly.<\/li>\n<li><strong>Why it matters<\/strong>: Standardization and repeatability reduce drift.<\/li>\n<li><strong>Practical benefit<\/strong>: Consistent dev\/test machines across teams.<\/li>\n<li><strong>Caveats<\/strong>: Keep formulas maintained as images\/tooling versions evolve.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Custom images and curated base images<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Marketplace images and\/or your organization\u2019s custom images.<\/li>\n<li><strong>Why it matters<\/strong>: Security and compliance often require managed images.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster provisioning and better patch compliance.<\/li>\n<li><strong>Caveats<\/strong>: Image pipelines and lifecycle management are your responsibility (often via Azure Compute Gallery and image building pipelines).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) VM claiming (claimable VMs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows shared VMs that users can claim for temporary use.<\/li>\n<li><strong>Why it matters<\/strong>: Efficient sharing of expensive compute.<\/li>\n<li><strong>Practical benefit<\/strong>: Lower costs than one-VM-per-developer for specialized needs.<\/li>\n<li><strong>Caveats<\/strong>: Governance and cleanup are important; treat claimable VMs as shared assets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Repository integration for artifacts (Git-based)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports using repositories as sources for artifacts (commonly GitHub or Azure Repos).<\/li>\n<li><strong>Why it matters<\/strong>: Infrastructure\/config becomes version-controlled.<\/li>\n<li><strong>Practical benefit<\/strong>: Change management for developer workstation setup.<\/li>\n<li><strong>Caveats<\/strong>: Secure repository access and review artifact scripts like any other code.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Environment deployment via templates (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Deploys multi-resource environments using templates (historically ARM templates).<\/li>\n<li><strong>Why it matters<\/strong>: Some dev\/test needs more than a VM (e.g., VM + database + networking).<\/li>\n<li><strong>Practical benefit<\/strong>: One-click deployment of a small stack.<\/li>\n<li><strong>Caveats<\/strong>: This capability has evolved across Azure services; <strong>verify current DevTest Labs \u201cenvironments\u201d support and best practice<\/strong> in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Centralized lab administration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a single place to manage lab-wide settings, policies, and user access.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces admin overhead compared to per-VM manual controls.<\/li>\n<li><strong>Practical benefit<\/strong>: Scales operationally across many developers.<\/li>\n<li><strong>Caveats<\/strong>: Organizational governance still needs Azure Policy, tagging standards, and RBAC design.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Azure DevTest Labs is a control-plane service that provisions and manages Azure resources under the hood:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: The lab resource (Microsoft.DevTestLab\/labs) stores configuration and policies.<\/li>\n<li><strong>Data\/compute plane<\/strong>: Actual workloads run on standard Azure resources\u2014primarily Azure VMs, disks, VNets, NICs, and IPs.<\/li>\n<li><strong>Identity plane<\/strong>: Microsoft Entra ID + Azure RBAC govern who can create\/manage lab resources.<\/li>\n<li><strong>Automation plane<\/strong>: Schedules\/policies and artifacts automate creation and lifecycle actions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Request \/ data \/ control flow (typical VM creation)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A user (developer) requests a VM from the lab (portal\/API).<\/li>\n<li>Azure DevTest Labs checks lab policies: allowed image, size, quota, schedule requirements.<\/li>\n<li>The service provisions an Azure VM and associated resources in the configured resource group(s).<\/li>\n<li>After provisioning, selected artifacts run to install\/configure software.<\/li>\n<li>Schedules enforce auto-shutdown (and possibly auto-start if configured\/available).<\/li>\n<li>Ops teams monitor via Azure Activity Log and Azure Monitor VM insights\/diagnostics.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Virtual Machines<\/strong>: Actual compute instances.<\/li>\n<li><strong>Azure Virtual Network<\/strong>: Network isolation and routing.<\/li>\n<li><strong>Azure Compute Gallery<\/strong> (common enterprise pattern): Curated images.<\/li>\n<li><strong>Azure Monitor<\/strong>: Metrics\/logs\/alerts for VMs and operations.<\/li>\n<li><strong>Azure Policy<\/strong>: Additional governance controls beyond lab policies.<\/li>\n<li><strong>Azure Key Vault<\/strong>: Secure secret storage for scripts and build pipelines (recommended).<\/li>\n<li><strong>CI\/CD<\/strong> (optional): Pipeline-driven provisioning and teardown (verify supported tasks\/APIs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Storage (managed disks) for VM OS\/data disks<\/li>\n<li>Networking resources for VM connectivity<\/li>\n<li>Public IPs and NSGs for inbound connectivity (if enabled)<\/li>\n<li>Azure resource provider registration: <strong>Microsoft.DevTestLab<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Authentication: Microsoft Entra ID.<\/li>\n<li>Authorization: Azure RBAC roles applied at lab\/resource group\/subscription scope.<\/li>\n<li>Lab-specific roles and permissions may be provided via built-in roles (verify current roles in docs), but the reliable baseline is Azure RBAC + resource scopes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>Common patterns:\n&#8211; <strong>Simple<\/strong>: Lab creates its own VNet and subnet; VMs get public IPs for RDP\/SSH.\n&#8211; <strong>Enterprise<\/strong>: Lab uses a pre-created VNet\/subnet connected to hub-spoke; inbound access via Bastion or jump boxes; outbound via firewall.<\/p>\n\n\n\n<p>If you need strict control:\n&#8211; Prefer private access patterns (Azure Bastion, private subnets, controlled egress).\n&#8211; Use NSGs, UDRs, and firewall rules consistent with your landing zone.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Azure Activity Log<\/strong> for control-plane operations (create\/update\/delete).<\/li>\n<li>Use <strong>Azure Monitor<\/strong> and VM diagnostics for guest OS logs and metrics.<\/li>\n<li>Apply consistent tagging and naming conventions.<\/li>\n<li>Use Azure Policy for: required tags, allowed regions, allowed SKUs, deny public IP creation (if desired), etc.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer] --&gt;|Azure Portal \/ API| DTL[Azure DevTest Labs (Lab)]\n  DTL --&gt;|Policy checks| Policies[Lab Policies &amp; Quotas]\n  DTL --&gt;|Provision| VM[Azure Virtual Machine]\n  DTL --&gt;|Attach| Disk[Managed Disks]\n  DTL --&gt;|Connect| VNet[Virtual Network\/Subnet]\n  DTL --&gt;|Run post-deploy| Artifacts[Artifacts (scripts\/packages)]\n  VM --&gt;|Metrics\/Logs| Mon[Azure Monitor]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Identity[\"Identity &amp; Governance\"]\n    Entra[Microsoft Entra ID]\n    RBAC[Azure RBAC]\n    AzPolicy[Azure Policy]\n  end\n\n  subgraph Ops[\"Operations\"]\n    Monitor[Azure Monitor \/ Log Analytics]\n    Activity[Azure Activity Log]\n    KV[Azure Key Vault]\n  end\n\n  subgraph Network[\"Enterprise Network (Hub-Spoke)\"]\n    Hub[Hub VNet\\nFirewall\/Bastion\/DNS]\n    Spoke[Spoke VNet (Dev\/Test)]\n    Hub --- Spoke\n  end\n\n  subgraph DevTest[\"Dev\/Test Subscription or RG\"]\n    Lab[Azure DevTest Labs]\n    Repo[Artifacts Repo (GitHub\/Azure Repos)\\nVersion controlled]\n    Gallery[Azure Compute Gallery\\nCurated images]\n    VM1[Lab VM(s)]\n  end\n\n  Entra --&gt; RBAC --&gt; Lab\n  AzPolicy --&gt; DevTest\n  Lab --&gt;|Uses| Gallery\n  Lab --&gt;|Fetch artifacts| Repo\n  Lab --&gt;|Provision| VM1\n  VM1 --&gt; Spoke\n  Hub --&gt;|Secure access| VM1\n  VM1 --&gt; Monitor\n  Lab --&gt; Activity\n  Repo --&gt; KV\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/subscription requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>Azure subscription<\/strong> where you can create resources.<\/li>\n<li>The <strong>Microsoft.DevTestLab<\/strong> resource provider must be registered in the subscription (often auto-registered when creating the first lab, but not always).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum, for the lab creator:\n&#8211; <strong>Contributor<\/strong> on the target resource group (or subscription), plus permissions to create networking and compute resources.\nFor lab users (developers):\n&#8211; RBAC roles scoped to the lab\/resource group that allow creating VMs inside the lab (commonly Contributor-like permissions, but many orgs scope permissions more tightly).<\/p>\n\n\n\n<p>Because RBAC needs vary by org:\n&#8211; Start with least privilege and expand based on observed authorization failures.\n&#8211; <strong>Verify built-in DevTest Labs roles and recommended RBAC patterns in official docs<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A payment method associated with the subscription (unless using a sponsored\/education subscription with credits).<\/li>\n<li>Spending will primarily come from VMs and storage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools<\/h3>\n\n\n\n<p>For this tutorial:\n&#8211; Azure Portal (web)\n&#8211; Optional: <strong>Azure CLI<\/strong> (helpful for resource group creation and cleanup)\n  &#8211; Install: https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose an Azure region that supports your target VM sizes and images.<\/li>\n<li>DevTest Labs is tied to the region of deployed resources.<br\/>\nIf you rely on specific SKUs or images, confirm availability in your chosen region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure subscription\/regional quotas for:<\/li>\n<li>vCPU (VM family quotas)<\/li>\n<li>Public IP addresses<\/li>\n<li>Storage and disks<\/li>\n<li>Network interfaces<\/li>\n<li>DevTest Labs may also have service-specific limits. <strong>Verify in official docs<\/strong> if you anticipate large scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required beyond what Azure provisions automatically (VM, disk, networking), but in enterprise setups you may need:<\/li>\n<li>Existing VNet\/subnet<\/li>\n<li>Azure Compute Gallery for approved images<\/li>\n<li>Log Analytics workspace for monitoring<\/li>\n<li>Key Vault for secrets used in artifacts\/scripts<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (accurate framing)<\/h3>\n\n\n\n<p>Azure DevTest Labs is primarily a <strong>management layer<\/strong>. In typical usage:\n&#8211; <strong>You pay for the underlying Azure resources<\/strong> created in the lab (VM compute, disks, storage, networking, public IPs, outbound data transfer, etc.).\n&#8211; The DevTest Labs service itself is generally not billed as a separate metered item (confirm in current official docs\/pricing pages for your scenario).<\/p>\n\n\n\n<p>Official references:\n&#8211; DevTest Labs documentation: https:\/\/learn.microsoft.com\/azure\/devtest-labs\/\n&#8211; Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/\n&#8211; Azure pricing pages (search for DevTest Labs pricing in your region; if a dedicated page is not available, rely on VM\/storage\/network pricing and verify via docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what drives cost)<\/h3>\n\n\n\n<p><strong>Direct cost drivers<\/strong>\n&#8211; <strong>VM compute hours<\/strong> (largest factor): size\/SKU, OS type, region, pay-as-you-go vs reservations\/savings plans (if applicable to dev\/test).\n&#8211; <strong>Managed disks<\/strong>: OS disk + data disks (billed even when VM is stopped\/deallocated, depending on disk type).\n&#8211; <strong>Public IP addresses<\/strong>: some public IP SKUs are billable even when not attached\u2014verify current pricing rules.\n&#8211; <strong>Network egress<\/strong>: outbound data transfer to the internet or across regions.\n&#8211; <strong>Load balancers\/NAT gateways\/firewalls<\/strong> (if part of your network design).<\/p>\n\n\n\n<p><strong>Indirect\/hidden costs<\/strong>\n&#8211; <strong>Idle but not deallocated VMs<\/strong>: \u201cStopped\u201d vs \u201cStopped (deallocated)\u201d affects billing. DevTest Labs auto-shutdown usually stops\/deallocates, but always verify state in portal.\n&#8211; <strong>Orphaned disks<\/strong>: deleting a VM may leave disks\/snapshots if configured or if deletion fails.\n&#8211; <strong>Shared infrastructure<\/strong>: Log Analytics ingestion costs if collecting detailed logs.\n&#8211; <strong>Custom image pipelines<\/strong>: image building and storage in Azure Compute Gallery.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (practical levers)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce <strong>auto-shutdown<\/strong> for all lab VMs.<\/li>\n<li>Set <strong>per-user VM quotas<\/strong> and restrict high-cost SKUs.<\/li>\n<li>Prefer smaller VM sizes and scale up only when needed.<\/li>\n<li>Use <strong>shared\/claimable VMs<\/strong> for expensive workloads.<\/li>\n<li>Clean up unused VMs\/disks regularly; consider expiration policies where supported.<\/li>\n<li>Use standardized images to reduce \u201cpet VM\u201d behavior and rebuild instead of keeping long-lived VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated numbers)<\/h3>\n\n\n\n<p>A minimal lab with one small Linux VM will cost roughly:\n&#8211; VM compute for the hours it\u2019s running (e.g., business hours only if auto-shutdown is set)\n&#8211; OS disk storage (billed monthly)\n&#8211; Possibly a small public IP cost depending on SKU and region\n&#8211; Minimal outbound data transfer<\/p>\n\n\n\n<p>Because exact pricing varies by region and SKU:\n&#8211; Use the Azure Pricing Calculator with:\n  &#8211; 1 small VM in your region\n  &#8211; Managed disk type\/size\n  &#8211; Expected hours per month (e.g., ~160 hours for business hours)\n  &#8211; Any monitoring logs you plan to collect<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For a department-wide lab supporting 50\u2013200 developers:\n&#8211; vCPU quota management becomes important.\n&#8211; Savings come mainly from:\n  &#8211; strict shutdown schedules,\n  &#8211; eliminating oversized VMs,\n  &#8211; enforcing expiration\/cleanup,\n  &#8211; minimizing public IP usage (use Bastion\/jump access),\n  &#8211; standardized images and rebuild patterns.\n&#8211; Monitoring costs can become material if you ingest verbose logs from many VMs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create an <strong>Azure DevTest Labs<\/strong> lab with guardrails, provision a low-cost Linux VM inside the lab, apply an artifact-like configuration (or minimal bootstrapping), enable auto-shutdown, validate access, and clean up safely.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a resource group.\n2. Create an Azure DevTest Labs <strong>lab<\/strong>.\n3. Configure <strong>auto-shutdown<\/strong> and basic policies.\n4. Create a <strong>Linux VM<\/strong> in the lab (Ubuntu or similar).\n5. Connect to the VM, validate it works, and confirm shutdown scheduling.\n6. Clean up by deleting the resource group.<\/p>\n\n\n\n<p>This is designed to be low-cost:\n&#8211; Use a small VM size\n&#8211; Enable auto-shutdown soon after creation\n&#8211; Delete everything at the end<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a resource group (Azure CLI)<\/h3>\n\n\n\n<p><strong>Action<\/strong>\n1. Open a terminal with Azure CLI installed.\n2. Sign in and select your subscription.\n3. Create a resource group.<\/p>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account set --subscription \"&lt;YOUR_SUBSCRIPTION_ID&gt;\"\naz group create --name rg-devtestlabs-lab01 --location eastus\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A new resource group named <code>rg-devtestlabs-lab01<\/code> exists in your chosen region.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az group show --name rg-devtestlabs-lab01 --query \"{name:name, location:location}\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create an Azure DevTest Labs lab (Azure Portal)<\/h3>\n\n\n\n<p><strong>Action (Portal)<\/strong>\n1. Go to the Azure portal: https:\/\/portal.azure.com\n2. Search for <strong>DevTest Labs<\/strong>.\n3. Select <strong>DevTest Labs<\/strong> \u2192 <strong>Create<\/strong>.\n4. Fill out:\n   &#8211; <strong>Lab name<\/strong>: <code>dtl-lab01<\/code>\n   &#8211; <strong>Subscription<\/strong>: your subscription\n   &#8211; <strong>Resource group<\/strong>: <code>rg-devtestlabs-lab01<\/code>\n   &#8211; <strong>Location<\/strong>: choose the same region as the resource group (for simplicity)\n5. Review and create.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The lab resource is created and you can open it in the portal.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the lab overview blade, confirm:\n  &#8211; Provisioning state succeeded\n  &#8211; You can see sections for VMs, policies\/configuration, artifacts\/formulas (names may vary slightly by portal UX updates)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Configure auto-shutdown and basic cost guardrails<\/h3>\n\n\n\n<p><strong>Action (Portal)<\/strong>\n1. In your lab (<code>dtl-lab01<\/code>), find <strong>Configuration and policies<\/strong> (or similar).\n2. Configure <strong>Auto-shutdown<\/strong> policy:\n   &#8211; Enable auto-shutdown\n   &#8211; Set time to ~30\u201360 minutes from now (for quick validation), then later change it to your preferred daily schedule\n   &#8211; Configure notification email if desired\n3. Configure <strong>Allowed virtual machine sizes<\/strong> to restrict to small, low-cost SKUs (choose from what your region supports).\n4. Optionally set:\n   &#8211; Maximum VMs per user (e.g., 1\u20132 for a small test)\n   &#8211; Maximum number of VMs in lab<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Lab has guardrails to prevent accidental high spend.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Re-open policy settings and confirm your changes are saved.<\/p>\n\n\n\n<p><strong>Common mistake<\/strong>\n&#8211; Setting auto-shutdown but leaving VMs in states that still incur costs (for example, disks always cost money). Auto-shutdown mainly reduces compute hours.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Linux VM inside the lab<\/h3>\n\n\n\n<p><strong>Action (Portal)<\/strong>\n1. In the lab, go to <strong>Virtual machines<\/strong> \u2192 <strong>Add<\/strong> (or <strong>+ Create<\/strong>).\n2. Choose a base image:\n   &#8211; Ubuntu LTS (or another Linux distribution you prefer)\n3. Choose a VM size allowed by your policy (smallest practical for SSH + a web server).\n4. Configure authentication:\n   &#8211; Prefer <strong>SSH public key<\/strong> (recommended)\n   &#8211; Or password (less recommended; restrict inbound if you do)\n5. Networking:\n   &#8211; For simplest validation, allow inbound SSH (port 22) from your IP if the UI offers this.\n   &#8211; In stricter environments, you would use Bastion\/jump host and no public IP. For a simple lab, public IP is acceptable if locked down.\n6. Select any available <strong>artifacts<\/strong> if the UI offers a built-in \u201cinstall nginx\/apache\u201d artifact.<br\/>\n   &#8211; If you don\u2019t see such artifacts, proceed without artifacts and you\u2019ll install nginx manually after connecting.\n7. Create the VM.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A VM appears in the lab\u2019s VM list.\n&#8211; VM provisioning completes successfully.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the VM in the lab and confirm:\n  &#8211; Status is Running\n  &#8211; It has an IP or connection method available (public IP or internal IP if using private access)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Connect via SSH and install a simple web server (manual bootstrap)<\/h3>\n\n\n\n<p>If you used an artifact to install software, you can validate that instead. Otherwise, do a manual install to confirm the VM is usable.<\/p>\n\n\n\n<p><strong>Action<\/strong>\n1. From your terminal, connect to the VM (use the public IP shown in the portal):<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh &lt;username&gt;@&lt;vm_public_ip&gt;\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Install nginx (Ubuntu\/Debian example):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get install -y nginx\nsudo systemctl enable --now nginx\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Confirm nginx is running:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">systemctl status nginx --no-pager\ncurl -I http:\/\/localhost\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; <code>nginx<\/code> service is active\/running.\n&#8211; <code>curl -I<\/code> returns an HTTP 200\/302 response.<\/p>\n\n\n\n<p><strong>Verification from your workstation<\/strong>\n&#8211; If HTTP (port 80) is allowed inbound, test:\n  &#8211; <code>http:\/\/&lt;vm_public_ip&gt;\/<\/code> in a browser<br\/>\nIf not allowed inbound (common), that\u2019s fine\u2014SSH validation is sufficient.<\/p>\n\n\n\n<p><strong>Common errors and fixes<\/strong>\n&#8211; <strong>SSH timeout<\/strong>: inbound port 22 blocked by NSG or your corporate network.\n  &#8211; Fix: check NSG rules, ensure your IP is allowed, or use Bastion (recommended for enterprise).\n&#8211; <strong>apt-get fails<\/strong>: outbound internet blocked.\n  &#8211; Fix: allow outbound via firewall\/proxy or use internal package mirrors.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Validate auto-shutdown behavior<\/h3>\n\n\n\n<p><strong>Action (Portal)<\/strong>\n1. In the lab, open the VM\u2019s settings and confirm it has an auto-shutdown schedule applied (either inherited or explicitly set).\n2. Wait for the configured shutdown time.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The VM transitions to stopped\/deallocated (wording may vary).\n&#8211; Compute charges should stop when deallocated; disks still incur storage cost.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the VM status in the portal, confirm it is not \u201crunning\u201d.\n&#8211; (Optional) Use Azure CLI to query the VM instance view if you know the underlying VM resource name in the VM\u2019s resource group.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You have successfully completed the lab if:\n&#8211; The <strong>Azure DevTest Labs<\/strong> lab exists and contains at least one VM\n&#8211; Lab policies (at least auto-shutdown and allowed sizes) are configured\n&#8211; You can SSH into the VM and run a basic command\n&#8211; Auto-shutdown stops\/deallocates the VM at the expected time<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p><strong>Issue: Cannot create the lab (provider not registered)<\/strong>\n&#8211; Symptom: Error about <code>Microsoft.DevTestLab<\/code> not registered.\n&#8211; Fix: Register the resource provider:\n  &#8211; Azure portal: Subscription \u2192 Resource providers \u2192 search <code>Microsoft.DevTestLab<\/code> \u2192 Register\n  &#8211; Or CLI (if you have permission):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az provider register --namespace Microsoft.DevTestLab\n<\/code><\/pre>\n\n\n\n<p><strong>Issue: VM creation fails due to quota<\/strong>\n&#8211; Symptom: vCPU quota exceeded.\n&#8211; Fix: Request quota increase for the VM family\/region or choose a smaller VM size.<\/p>\n\n\n\n<p><strong>Issue: VM image not available<\/strong>\n&#8211; Symptom: selected image is unavailable in region.\n&#8211; Fix: choose a different region or image. For enterprises, publish an image to Azure Compute Gallery.<\/p>\n\n\n\n<p><strong>Issue: Auto-shutdown didn\u2019t reduce costs<\/strong>\n&#8211; Cause: VM may be stopped but not deallocated, or disks\/IPs still incur charges.\n&#8211; Fix: confirm VM state is deallocated; review disk and IP billing; remove unused disks.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the resource group (this deletes the lab, VM, disks, networking created inside that RG).<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete --name rg-devtestlabs-lab01 --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az group exists --name rg-devtestlabs-lab01\n<\/code><\/pre>\n\n\n\n<p>When it returns <code>false<\/code>, cleanup is complete.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Align labs to your org structure:<\/li>\n<li>One lab per team\/product for clear ownership, or<\/li>\n<li>One shared lab per department with strict per-user quotas<\/li>\n<li>Prefer standardized images via <strong>Azure Compute Gallery<\/strong> in enterprises.<\/li>\n<li>Use formulas for repeatability; treat them like product artifacts with versioning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong>:<\/li>\n<li>Give developers access to the lab scope, not the entire subscription.<\/li>\n<li>Separate roles:<\/li>\n<li>Lab admins manage policies\/images\/formulas<\/li>\n<li>Lab users create and operate their own VMs within guardrails<\/li>\n<li>Require MFA and conditional access via Microsoft Entra ID (organization-wide).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce auto-shutdown for every VM.<\/li>\n<li>Set allowed VM sizes; remove expensive SKUs by default.<\/li>\n<li>Use per-user quotas and require justification for exceptions.<\/li>\n<li>Prefer ephemeral rebuild over long-lived \u201cpet\u201d VMs.<\/li>\n<li>Tag consistently (owner, costCenter, app, environment, expiryDate).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep base images lean; install heavy tools via artifacts only when needed.<\/li>\n<li>Use appropriate disk types for dev\/test; avoid premium disks by default unless required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat lab VMs as non-production:<\/li>\n<li>Automate rebuilds<\/li>\n<li>Store code in repos and data in durable services, not only inside VM disks<\/li>\n<li>For shared\/claimable VMs, implement a reset\/reimage process.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize logging\/monitoring:<\/li>\n<li>Use Azure Monitor\/Log Analytics for VM telemetry.<\/li>\n<li>Automate cleanup:<\/li>\n<li>Scheduled audits for unused VMs\/disks<\/li>\n<li>Expiration policies where available<\/li>\n<li>Track failures:<\/li>\n<li>Artifact failures should be visible and actionable (log output, versioning, rollbacks).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming convention examples:<\/li>\n<li>Lab: <code>dtl-&lt;org&gt;-&lt;team&gt;-&lt;region&gt;<\/code><\/li>\n<li>VM: <code>vm-&lt;app&gt;-&lt;user&gt;-&lt;purpose&gt;-&lt;nn&gt;<\/code><\/li>\n<li>Enforce tags with Azure Policy:<\/li>\n<li><code>owner<\/code>, <code>costCenter<\/code>, <code>dataClassification<\/code>, <code>expiryDate<\/code>, <code>environment=devtest<\/code><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure DevTest Labs uses <strong>Microsoft Entra ID<\/strong> for authentication and <strong>Azure RBAC<\/strong> for authorization.<\/li>\n<li>Apply RBAC at the narrowest scope:<\/li>\n<li>Lab resource group or the lab resource itself where possible.<\/li>\n<li>Consider separate admin and user groups:<\/li>\n<li><code>dtl-lab-admins<\/code><\/li>\n<li><code>dtl-lab-users<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure managed disks are encrypted at rest by default (Azure Storage encryption).<\/li>\n<li>For stricter needs, evaluate customer-managed keys (CMK) for disks and supporting services\u2014availability depends on configuration and region. <strong>Verify in official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid broad inbound rules (0.0.0.0\/0) for SSH\/RDP.<\/li>\n<li>Preferred enterprise pattern:<\/li>\n<li>No public IP on lab VMs<\/li>\n<li>Access via <strong>Azure Bastion<\/strong> or a controlled jump host<\/li>\n<li>Controlled outbound via firewall\/NAT with logging<\/li>\n<li>Use NSGs and route tables consistent with your landing zone.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not bake secrets into artifacts or formulas.<\/li>\n<li>Store secrets in <strong>Azure Key Vault<\/strong> and retrieve them at runtime using managed identity where possible.<\/li>\n<li>If artifacts require credentials, use short-lived tokens and least privilege.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use:<\/li>\n<li>Azure Activity Log (who created\/changed resources)<\/li>\n<li>Azure Monitor \/ Log Analytics for VM logs<\/li>\n<li>Consider sending logs to a SIEM (e.g., Microsoft Sentinel) if required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Azure DevTest Labs is a management service; compliance posture largely depends on:\n&#8211; Subscription governance (Azure Policy)\n&#8211; Network isolation\n&#8211; Approved images and patching\n&#8211; Logging and access controls<\/p>\n\n\n\n<p>Always map your control requirements to the underlying resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leaving SSH\/RDP open to the internet.<\/li>\n<li>Allowing any Marketplace image without review.<\/li>\n<li>Giving developers Contributor on the whole subscription.<\/li>\n<li>Long-lived VMs with no patching strategy.<\/li>\n<li>Artifact scripts with embedded secrets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use curated images, patch monthly (or more often).<\/li>\n<li>Restrict inbound access; prefer Bastion.<\/li>\n<li>Enforce tagging and expiration.<\/li>\n<li>Use Azure Policy to deny public IP creation if your model supports private access.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Azure DevTest Labs is a managed service with opinionated workflows, expect constraints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ operational gotchas (commonly encountered)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Quota collisions<\/strong>: Lab quotas don\u2019t override Azure regional quotas; both can block provisioning.<\/li>\n<li><strong>\u201cStopped\u201d vs \u201cDeallocated\u201d confusion<\/strong>: Cost savings depend on actual deallocation state.<\/li>\n<li><strong>Disk costs persist<\/strong>: Even when VMs are deallocated, managed disks continue billing.<\/li>\n<li><strong>Networking complexity<\/strong>: Enterprise hub-spoke, private DNS, forced tunneling, and firewalls can break artifact installs or provisioning workflows if not planned.<\/li>\n<li><strong>Artifact reliability<\/strong>: Scripts can fail due to package repository downtime, proxy needs, or OS differences.<\/li>\n<li><strong>Image availability<\/strong>: Marketplace images and VM sizes differ by region and may change over time.<\/li>\n<li><strong>RBAC complexity<\/strong>: Least-privilege setups can require iterative tuning when users hit authorization errors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some VM families are not available in all regions.<\/li>\n<li>Availability Zone support depends on region and VM SKU; DevTest Labs doesn\u2019t change that.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public IP charges (depends on SKU\/rules).<\/li>\n<li>Log Analytics ingestion if you enable verbose logs at scale.<\/li>\n<li>Orphaned disks\/snapshots.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If using custom VNets, ensure DNS, outbound access, and required endpoints are available.<\/li>\n<li>If using private-only networks, plan for secure access (Bastion\/jump box).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you decide later to move from DevTest Labs to another developer environment platform:<\/li>\n<li>VMs are still Azure VMs, but formulas\/policies\/artifacts are service-specific.<\/li>\n<li>Plan to represent standard builds in IaC and image pipelines to reduce lock-in.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure DevTest Labs is one option among several ways to deliver dev\/test environments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure DevTest Labs<\/strong><\/td>\n<td>Self-service dev\/test <strong>VMs<\/strong> with guardrails<\/td>\n<td>Lab policies, auto-shutdown, artifacts\/formulas, fast provisioning<\/td>\n<td>Service-specific constructs; primarily VM-centric<\/td>\n<td>You want VM-based dev\/test with centralized cost control<\/td>\n<\/tr>\n<tr>\n<td><strong>Microsoft Dev Box<\/strong><\/td>\n<td>Managed developer workstations<\/td>\n<td>Centralized management, dev workstation experience<\/td>\n<td>Different model than self-managed VMs; may require licensing\/constraints<\/td>\n<td>You want standardized developer desktops (verify fit)<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Deployment Environments<\/strong><\/td>\n<td>Standardized app environments using templates<\/td>\n<td>Environment catalog, IaC-driven, platform approach<\/td>\n<td>May be more suited to app stacks than single VMs<\/td>\n<td>You want platform-engineering style environment provisioning (verify)<\/td>\n<\/tr>\n<tr>\n<td><strong>Plain Azure VMs + IaC (Bicep\/Terraform)<\/strong><\/td>\n<td>Full control and portability<\/td>\n<td>Maximum flexibility; no service-specific layer<\/td>\n<td>You must build governance, schedules, self-service UX<\/td>\n<td>You already have a platform team and want custom workflows<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Lab Services<\/strong><\/td>\n<td>Training\/classroom labs (often)<\/td>\n<td>Classroom management model<\/td>\n<td>Different target use case from DevTest Labs<\/td>\n<td>Choose for formal training labs if it meets requirements (verify current status\/roadmap)<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS EC2 + Service Catalog \/ CloudFormation<\/strong><\/td>\n<td>AWS-based dev\/test environments<\/td>\n<td>Strong IaC and catalog patterns<\/td>\n<td>Must design cost controls and self-service patterns<\/td>\n<td>Your org is AWS-first<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Compute Engine + templates<\/strong><\/td>\n<td>GCP dev\/test VMs<\/td>\n<td>Strong VM platform<\/td>\n<td>Similar need to build guardrails<\/td>\n<td>Your org is GCP-first<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed (vSphere\/on-prem) + automation<\/strong><\/td>\n<td>On-prem dev\/test<\/td>\n<td>Data locality, existing tooling<\/td>\n<td>Capacity constraints, slower provisioning<\/td>\n<td>You must stay on-prem for compliance or latency<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated industry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A bank has 300 developers. Dev\/test VMs were created manually across subscriptions, with inconsistent OS baselines and high monthly spend due to always-on VMs.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>One DevTest Labs lab per line-of-business in a dev\/test subscription.<\/li>\n<li>Curated images stored in <strong>Azure Compute Gallery<\/strong> built from hardened baselines.<\/li>\n<li>Hub-spoke networking with:<ul>\n<li>Private subnets for lab VMs<\/li>\n<li>Azure Bastion for access<\/li>\n<li>Central firewall for outbound with logging<\/li>\n<\/ul>\n<\/li>\n<li>Azure Policy enforces:<ul>\n<li>Required tags<\/li>\n<li>Approved regions<\/li>\n<li>No public IPs<\/li>\n<\/ul>\n<\/li>\n<li>Lab policies enforce:<ul>\n<li>Allowed VM sizes<\/li>\n<li>Max VMs per user<\/li>\n<li>Auto-shutdown schedules<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why Azure DevTest Labs was chosen<\/strong><\/li>\n<li>Rapid self-service with guardrails, without building an internal portal from scratch.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Reduced dev\/test compute hours via enforced shutdown<\/li>\n<li>Improved compliance through curated images and controlled network access<\/li>\n<li>Better auditability and ownership tagging<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A 12-person SaaS startup needs repeatable dev\/test VMs for integration testing and demos, but keeps forgetting to shut down machines.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Single lab with:<ul>\n<li>Allowed small VM sizes only<\/li>\n<li>Auto-shutdown at 7 PM<\/li>\n<li>One VM per user quota<\/li>\n<\/ul>\n<\/li>\n<li>A couple of formulas:<ul>\n<li>\u201cDemo VM\u201d (installs demo stack)<\/li>\n<li>\u201cTest Agent VM\u201d (installs CI tools)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why Azure DevTest Labs was chosen<\/strong><\/li>\n<li>Quick setup, simple guardrails, no need for complex platform engineering.<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Lower surprise bills<\/li>\n<li>Faster onboarding (new devs create a VM from a formula)<\/li>\n<li>Reduced variance in dev environments<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure DevTest Labs the same as Azure DevOps?<\/strong><br\/>\nNo. Azure DevTest Labs is an Azure service for provisioning and governing dev\/test environments (mostly VMs). Azure DevOps is a suite for repos, pipelines, boards, and artifacts.<\/p>\n\n\n\n<p>2) <strong>Do I pay for Azure DevTest Labs itself?<\/strong><br\/>\nTypically, you pay for the underlying Azure resources (VMs, disks, networking). Confirm the latest billing details in official docs for your subscription and region.<\/p>\n\n\n\n<p>3) <strong>What\u2019s the biggest way DevTest Labs saves money?<\/strong><br\/>\nAuto-shutdown and VM size restrictions. Most dev\/test waste comes from always-on compute and oversized VMs.<\/p>\n\n\n\n<p>4) <strong>Does auto-shutdown delete the VM?<\/strong><br\/>\nNo\u2014auto-shutdown generally stops\/deallocates the VM. Disks usually remain and continue to incur storage costs.<\/p>\n\n\n\n<p>5) <strong>Can I restrict which VM sizes developers can use?<\/strong><br\/>\nYes, via lab policies. Pair this with Azure Policy if you need enforcement beyond the lab.<\/p>\n\n\n\n<p>6) <strong>Can I require tags on lab VMs?<\/strong><br\/>\nDevTest Labs has its own governance features, but the most consistent way to require tags is <strong>Azure Policy<\/strong> at the subscription\/resource group level.<\/p>\n\n\n\n<p>7) <strong>Can DevTest Labs deploy full environments (VM + database + app services)?<\/strong><br\/>\nDevTest Labs has historically supported template-based environments (often ARM templates). The exact current capabilities and recommended approach can evolve\u2014verify in official docs and consider Azure Deployment Environments for broader environment catalogs.<\/p>\n\n\n\n<p>8) <strong>How do artifacts work?<\/strong><br\/>\nArtifacts are post-deployment actions that run on the VM to install\/configure software (scripts, package installs). Treat them like code: version control, code review, and testing.<\/p>\n\n\n\n<p>9) <strong>Can I use my own custom images?<\/strong><br\/>\nYes. Many enterprises use Azure Compute Gallery for curated images and then allow those images in the lab.<\/p>\n\n\n\n<p>10) <strong>Is DevTest Labs suitable for production workloads?<\/strong><br\/>\nIt\u2019s intended for dev\/test. Production typically requires different governance, reliability patterns, and change control.<\/p>\n\n\n\n<p>11) <strong>How do I prevent public internet exposure?<\/strong><br\/>\nUse private subnets, deny public IP creation with Azure Policy, and provide access through Azure Bastion or a jump host.<\/p>\n\n\n\n<p>12) <strong>What if developers need admin rights on their VMs?<\/strong><br\/>\nThat\u2019s common for dev\/test. Mitigate risk with isolated networks, approved images, endpoint protection, and strict RBAC at the subscription level.<\/p>\n\n\n\n<p>13) <strong>How do I handle patching for lab VMs?<\/strong><br\/>\nUse monthly patched images and rebuild often, or implement a patching solution (Update Manager\/guest patching strategy). Standardize via images instead of patching long-lived VMs.<\/p>\n\n\n\n<p>14) <strong>How do I troubleshoot VM creation failures?<\/strong><br\/>\nCheck:\n&#8211; Azure Activity Log for errors\n&#8211; Subscription quotas (vCPU, IPs)\n&#8211; Lab policies (allowed sizes\/images)\n&#8211; Network constraints that may block provisioning scripts\/artifacts<\/p>\n\n\n\n<p>15) <strong>Can I integrate DevTest Labs with CI\/CD pipelines?<\/strong><br\/>\nOften yes via APIs and automation, but specific pipeline tasks\/extensions can change over time. Verify current guidance in Microsoft Learn docs and supported tooling.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the difference between formulas and images?<\/strong><br\/>\nImages are OS\/base disk templates. Formulas are higher-level VM definitions (image + size + artifacts + settings) to standardize builds.<\/p>\n\n\n\n<p>17) <strong>How should I structure labs in a large organization?<\/strong><br\/>\nCommon patterns:\n&#8211; One lab per team\/product (clear ownership)\n&#8211; One lab per department with strict per-user quotas\nChoose based on governance needs, network isolation requirements, and cost allocation.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure DevTest Labs<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure DevTest Labs docs (Microsoft Learn) \u2014 https:\/\/learn.microsoft.com\/azure\/devtest-labs\/<\/td>\n<td>Primary source for features, configuration, and concepts<\/td>\n<\/tr>\n<tr>\n<td>Official quickstarts\/tutorials<\/td>\n<td>Browse DevTest Labs tutorials in Microsoft Learn \u2014 https:\/\/learn.microsoft.com\/azure\/devtest-labs\/<\/td>\n<td>Step-by-step guidance aligned to current portal\/API behavior<\/td>\n<\/tr>\n<tr>\n<td>REST API reference<\/td>\n<td>DevTest Labs REST API (Microsoft.DevTestLab) \u2014 https:\/\/learn.microsoft.com\/rest\/api\/azure\/devtestlabs\/<\/td>\n<td>Automate labs, VMs, policies, artifacts via API<\/td>\n<\/tr>\n<tr>\n<td>Azure CLI<\/td>\n<td>Azure CLI documentation \u2014 https:\/\/learn.microsoft.com\/cli\/azure\/<\/td>\n<td>Helpful for provisioning, cleanup, and scripting around labs<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Azure Pricing Calculator \u2014 https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<td>Estimate VM\/disk\/network costs that dominate lab spend<\/td>\n<\/tr>\n<tr>\n<td>Governance<\/td>\n<td>Azure Policy documentation \u2014 https:\/\/learn.microsoft.com\/azure\/governance\/policy\/<\/td>\n<td>Enforce org-wide controls (tags, SKUs, regions, public IP restrictions)<\/td>\n<\/tr>\n<tr>\n<td>Monitoring<\/td>\n<td>Azure Monitor documentation \u2014 https:\/\/learn.microsoft.com\/azure\/azure-monitor\/<\/td>\n<td>Monitor VM performance, logs, and alerts for lab resources<\/td>\n<\/tr>\n<tr>\n<td>Identity<\/td>\n<td>Azure RBAC documentation \u2014 https:\/\/learn.microsoft.com\/azure\/role-based-access-control\/<\/td>\n<td>Design least-privilege access to labs and lab VMs<\/td>\n<\/tr>\n<tr>\n<td>Images<\/td>\n<td>Azure Compute Gallery documentation \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-machines\/azure-compute-gallery<\/td>\n<td>Enterprise pattern for curated images used in labs<\/td>\n<\/tr>\n<tr>\n<td>Updates<\/td>\n<td>Azure Updates \u2014 https:\/\/azure.microsoft.com\/updates\/<\/td>\n<td>Track announcements that may affect DevTest Labs and adjacent services<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, platform teams<\/td>\n<td>DevOps and Azure tooling; environment automation; governance basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>SCM + DevOps fundamentals; practical labs<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, SREs<\/td>\n<td>Cloud operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations engineers<\/td>\n<td>Reliability engineering, observability, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, monitoring automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify offerings)<\/td>\n<td>Engineers seeking practical DevOps guidance<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training platform (verify course list)<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps services\/training platform (verify services)<\/td>\n<td>Teams needing short-term DevOps help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training services (verify scope)<\/td>\n<td>Ops\/DevOps teams needing support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact offerings)<\/td>\n<td>Dev\/test governance, automation, cost controls<\/td>\n<td>DevTest Labs setup, RBAC model, network integration, cost optimization<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training (verify exact offerings)<\/td>\n<td>Platform enablement, automation, CI\/CD integration<\/td>\n<td>Standardized dev\/test VM patterns, artifacts\/formulas strategy, governance<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact offerings)<\/td>\n<td>DevOps process\/tooling, cloud operations<\/td>\n<td>Dev\/test lab design, automation, monitoring, security reviews<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure DevTest Labs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure fundamentals:<\/li>\n<li>Subscriptions, resource groups, regions<\/li>\n<li>Azure Virtual Machines, disks, VNets, NSGs<\/li>\n<li>Identity and access:<\/li>\n<li>Microsoft Entra ID basics<\/li>\n<li>Azure RBAC and scopes<\/li>\n<li>Basic governance and cost:<\/li>\n<li>Tags, budgets, quotas<\/li>\n<li>Azure Policy basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure DevTest Labs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Image engineering:<\/li>\n<li>Azure Compute Gallery<\/li>\n<li>Automated image building pipelines (Packer\/Azure Image Builder\u2014verify best fit)<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Bicep\/ARM or Terraform<\/li>\n<li>Secure access patterns:<\/li>\n<li>Azure Bastion<\/li>\n<li>Hub-spoke networking, private DNS, firewall egress control<\/li>\n<li>Observability:<\/li>\n<li>Azure Monitor, Log Analytics, alerting, dashboards<\/li>\n<li>Platform engineering:<\/li>\n<li>Self-service portals, golden paths, environment catalogs (evaluate Azure Deployment Environments\u2014verify)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud engineer \/ cloud operations engineer<\/li>\n<li>DevOps engineer<\/li>\n<li>Platform engineer<\/li>\n<li>Solutions architect<\/li>\n<li>Security engineer (governance\/controls for dev\/test)<\/li>\n<li>QA\/test automation engineer (environment provisioning)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Azure certifications change over time; DevTest Labs is typically covered indirectly via:\n&#8211; Azure fundamentals and administration (VMs, networking, RBAC, governance)\n&#8211; DevOps and security certifications<br\/>\nChoose the cert aligned to your role and verify current Microsoft certification paths:\nhttps:\/\/learn.microsoft.com\/credentials\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a lab with:<\/li>\n<li>Allowed image list from a compute gallery<\/li>\n<li>Strict VM size policy<\/li>\n<li>Auto-shutdown<\/li>\n<li>A formula for \u201cDev VM\u201d and \u201cTest Agent VM\u201d<\/li>\n<li>Create an artifact repository and implement:<\/li>\n<li>OS hardening steps<\/li>\n<li>Tool installation (language runtime, Docker, editors)<\/li>\n<li>Logging agent installation<\/li>\n<li>Implement governance:<\/li>\n<li>Azure Policy for tags and deny public IPs<\/li>\n<li>Budget alerts for the dev\/test subscription<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact<\/strong>: A post-deployment action (script\/package install) applied to a VM to configure it.<\/li>\n<li><strong>Auto-shutdown<\/strong>: A schedule-based feature to stop\/deallocate VMs at a set time to reduce compute cost.<\/li>\n<li><strong>Azure Compute Gallery<\/strong>: Service for managing and sharing custom VM images at scale (formerly Shared Image Gallery).<\/li>\n<li><strong>Azure Policy<\/strong>: Governance service to enforce rules across subscriptions\/resource groups (e.g., allowed SKUs, required tags).<\/li>\n<li><strong>Azure RBAC<\/strong>: Role-based access control for Azure resources.<\/li>\n<li><strong>Claimable VM<\/strong>: A shared VM that can be temporarily claimed by a user for use.<\/li>\n<li><strong>Formula<\/strong>: A reusable VM definition (image + size + artifacts + settings) for consistent deployments.<\/li>\n<li><strong>Hub-spoke network<\/strong>: A network topology where a central hub provides shared services (firewall, Bastion, DNS) to multiple spoke VNets.<\/li>\n<li><strong>Lab<\/strong>: The Azure DevTest Labs resource that stores policies\/config and provisions governed dev\/test resources.<\/li>\n<li><strong>Managed disk<\/strong>: Azure block storage for VM OS\/data disks with independent lifecycle and billing.<\/li>\n<li><strong>NSG (Network Security Group)<\/strong>: Azure firewall rules for subnets\/NICs controlling inbound\/outbound traffic.<\/li>\n<li><strong>Quota<\/strong>: A subscription\/regional limit (e.g., vCPUs) that can block provisioning.<\/li>\n<li><strong>Stopped (deallocated)<\/strong>: VM state where compute billing typically stops; storage still billed.<\/li>\n<li><strong>VNet (Virtual Network)<\/strong>: Azure networking construct for isolated IP spaces and routing.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure DevTest Labs (Azure) is a <strong>Developer Tools<\/strong> service that helps teams provision dev\/test VMs quickly while enforcing <strong>guardrails<\/strong> like auto-shutdown, quotas, and approved VM configurations. It fits best when your organization needs <strong>self-service VM environments<\/strong> without sacrificing cost control and governance.<\/p>\n\n\n\n<p>From a cost perspective, the biggest savings come from <strong>reducing VM runtime<\/strong> (auto-shutdown) and preventing oversized deployments (allowed sizes\/quotas). From a security perspective, success depends on <strong>RBAC least privilege<\/strong>, curated images, and safe network access patterns (prefer private access via Bastion\/jump host and avoid broad inbound rules).<\/p>\n\n\n\n<p>Use Azure DevTest Labs when VM-based dev\/test is a primary need and you want policy-driven control with minimal platform build-out. If you need more application-environment catalog capabilities or managed developer desktops, evaluate adjacent Azure services and confirm the latest guidance in official documentation.<\/p>\n\n\n\n<p>Next step: review the official Azure DevTest Labs documentation and then expand this lab by introducing <strong>custom images (Azure Compute Gallery)<\/strong>, <strong>artifact repositories<\/strong>, and <strong>Azure Policy<\/strong> for organization-wide governance.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Developer Tools<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,18,43],"tags":[],"class_list":["post-421","post","type-post","status-publish","format-standard","hentry","category-azure","category-developer-tools","category-devops"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=421"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/421\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}