Lowering the cost of Azure dev and test environments comes down to two moves: switch eligible non-production workloads to Dev/Test pricing so you stop paying for Windows and other licenses you do not need outside production, and schedule those environments to shut down on nights and weekends so they only bill when someone is using them. A dev VM running around the clock for a 40-hour work week wastes roughly three quarters of its compute cost on idle time.
This article is part of our Azure cluster. For the wider context, start with the complete guide to Azure cost optimization, the pillar this piece links up to. Non-production waste is a classic Cut-step target in our See, Cut, Lock, Run method: spend that delivers nothing because the environment is idle most of the week.
A standard work week is about 40 hours out of 168. If a dev or test environment runs continuously but is only touched during working hours, you are paying for roughly 128 idle hours a week, around 76 percent of the bill, for nothing. Shut it down outside working hours and you keep only the time that matters. No rearchitecting, no risk to production, just a schedule.
Lever 1: Azure Dev/Test pricing
Azure offers reduced rates for development and testing workloads under Dev/Test pricing, available through Enterprise Dev/Test and Pay-As-You-Go Dev/Test subscription types tied to eligible subscriptions. The headline benefit is licensing: you do not pay for Windows Server, SQL Server, and certain other software licenses on Dev/Test VMs, because the rate excludes them. You still pay for the underlying infrastructure, but the license component, often a large share of a Windows VM's cost, comes off.
The trade-off is that Dev/Test subscriptions are for non-production use only and carry no production service-level agreement, which is exactly right for dev, test, staging, and QA. The practical step is to place those environments in a Dev/Test subscription rather than running them in your production subscription at full rate. This pairs naturally with the licensing reuse covered in Azure Hybrid Benefit: how to reuse Windows and SQL licenses, though the two are different mechanisms and you choose the one that fits each workload.
Lever 2: Auto-shutdown scheduling
Scheduling is where the compute savings come from. Several mechanisms do it:
| Mechanism | Best for | Notes |
|---|---|---|
| VM auto-shutdown | Individual VMs | Built into the VM blade, set a daily stop time |
| Start/Stop VMs solution | Groups of VMs | Start and stop on a schedule across a subscription |
| Automation runbooks | Custom logic | Tag-driven start/stop, exceptions, ramp schedules |
| DevTest Labs policies | Self-service dev environments | Auto-shutdown, auto-start, and per-lab quotas built in |
The most maintainable approach for most organizations is tag-driven scheduling: tag each non-production resource with its intended schedule, and let an automation runbook start and stop everything that carries the tag. That keeps the policy in one place and makes exceptions explicit. If you have not built the tagging model yet, set it up first using Azure tagging and management groups for cost allocation, then drive the schedule off those tags.
Paying production rates for environments nobody uses at night?
Our Azure cost audit finds every non-production environment, moves the eligible ones to Dev/Test pricing, and wires tag-driven shutdown schedules so they stop billing outside working hours. On the performance model, you pay only from realized savings. No savings, no fee.
Book an Azure cost audit →DevTest Labs: scheduling and pricing in one place
Azure DevTest Labs is purpose-built for this problem. It gives developers self-service environments inside guardrails: auto-shutdown and auto-start schedules, per-user and per-lab cost quotas, allowed VM sizes, and policies that cap how much anyone can spin up. For teams that constantly create and discard test environments, a lab enforces the savings automatically rather than relying on people to remember to shut things down. It is the difference between a policy and a hope.
Watch the things scheduling does not stop
Shutting a VM down stops its compute charge, but several costs continue while it is stopped. Managed disks keep billing because the storage still exists, public IP addresses can keep charging, and any database or platform service in the environment may bill independently of the VM. So pair scheduling with cleanup: delete the disks and resources behind environments that are truly finished, not just stopped. Our guide to finding idle and orphaned Azure resources covers the leftovers that survive a shutdown.
The Dev/Test subscription types, DevTest Labs features, and scheduling mechanisms described here reflect Azure as of May 2026. Eligibility rules and which licenses are excluded under Dev/Test pricing change, so verify the current terms in Microsoft's Azure documentation before you migrate subscriptions.
The Azure Cost Optimization Field Guide includes our non-production scheduling playbook and the Dev/Test eligibility checklist we run on engagements. It is the downloadable companion to this article.
The short version
Azure dev and test environments waste money two ways: they pay production licensing they do not need, and they run around the clock for a part-time workload. Move eligible non-production workloads to a Dev/Test subscription to drop the license cost, and schedule auto-shutdown, ideally tag-driven or through DevTest Labs, so compute only bills during working hours. Then clean up the disks and resources that keep billing after a VM stops. For the wider list of quick wins, see the Azure cost optimization checklist. When you want the whole non-production estate scheduled and re-priced for you, that is exactly what our Azure cost optimization service delivers.