The principle: you only pay for compute while the VM runs
A VM is billed on usage. When it is stopped, compute is no longer billed: only the disks and a few associated resources keep costing money. On Azure, beware of a classic trap: a VM shut down from inside the operating system stays allocated, and therefore billed. It must be in the "Stopped (deallocated)" state.
Non-prod environments (development, test, acceptance, POC) and virtual desktops (VDI) have no reason to run at night and on weekends. Hence the idea of Stop/Start.
The math: why a fixed schedule disappoints
A month has about 730 hours. Take a non-prod VM at €30 a day (illustrative amount) and compare the options:
| Option | Billed hours / month | Compute savings |
|---|---|---|
| VM running 24/7, no commitment | 730 | 0% |
| Reserved Instance or savings plan | 730, at a reduced rate | ≈ 50% |
| Fixed-schedule Stop/Start (8am-8pm on weekdays) | ≈ 260 in theory | ≈ 64% in theory, 50 to 60% in practice |
| Automatic Stop + Start on demand | The time actually used | ≈ 90% |
In practice, a fixed schedule quickly widens: you start earlier for early birds, stop later for batch jobs, handle exceptions. The real saving drops to 50 or 60%. That is barely better than a simple reservation, for much more effort: schedules per team, exception requests, complaints when a VM isn't ready.
The trap: reservations and Stop/Start don't stack
A reservation is a payment commitment, whether the VM runs or not. A reserved VM that is shut down at night keeps paying for its reservation: the shutdown saves nothing. You have to choose:
- In prod, the VM runs continuously: the reservation applies.
- In non-prod and on VDIs, the VM can be stopped: Stop/Start applies, and not just any Stop/Start.
What really works: automatic Stop + Start on demand
The idea is simple: instead of guessing when teams will need their VMs, let them start them themselves, and stop them automatically.
- Automatic Stop every evening, and ideally after a period of inactivity.
- Start on demand: the VM only restarts when someone needs it, through a self-service button, an internal portal, a Teams bot or a native mechanism.
Some services offer it natively. On Azure Virtual Desktop, the "Start VM on Connect" feature starts the virtual desktop when the user connects. On AWS WorkSpaces, AutoStop mode stops the desktop after a period of inactivity. For other VMs, a few automations are enough.
The result: a test VM used a few hours a week only costs those few hours. Savings reach about 90%.
Implementation: best practices
- Rely on tagging. The environment (prod or non-prod) must be known, through a tag or the CMDB. See our guide on FinOps tagging.
- Enable it by default. Auto Stop + Start on demand becomes a non-prod building block: every new VM gets it from day one. That is the principle of FinOps by design.
- Handle exceptions through tags, explicitly and for a limited time (for example during a performance test campaign).
- Plan for dependencies: some applications need their VMs started in a specific order.
- Communicate with the teams: a simple button to start a VM beats a long rulebook.
Measuring the result
One simple KPI: the share of non-prod VMs and VDIs with an uptime below 50% over the month. A target of 80% is a good goal. This KPI is tracked in our dashboard, with the list of VMs still running 24/7.
Where to apply it, and where not to
- Yes: development, test, acceptance and POC environments, VDIs, internal tools used during office hours.
- No: prod that must respond 24/7, to be covered by a reservation.
- Case by case: clusters and managed services. Some can be stopped or paused (for example certain databases or data capacities), often with constraints to check.