Scheduling Azure Virtual Machine Scale Set
Can ZopNight schedule Azure Virtual Machine Scale Set?
Scale set schedules deallocate all instances rather than deleting them. Each VM keeps its identity, OS disk and data disks, and compute billing stops for the whole set. Restart reallocates capacity for N machines simultaneously, so a 20-instance set in a constrained SKU is a real 8am risk.
How the stop works
| Field | Value |
|---|---|
| Behaviour | instances are deallocated on stop and restarted on start, halting compute billing for the whole set. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Deallocated, every one of them
The schedule powers the set down by deallocating each instance in place. Instance IDs, OS disks, data disks and configuration all persist; compute billing stops across the set. This is the whole-set equivalent of stopping a single VM properly (released allocation, preserved machine), applied N times at once.
Not the same as scaling in
Azure offers another way to make a scale set cheap at night: drop the capacity so instances are deleted. The two differ exactly where it matters. Scale-in destroys the instances and their disks: no disk bill overnight, but a morning of fresh VMs, fresh extensions and cold caches. Deallocation keeps the machines. Disks bill through the night, but the morning is a resume, not a rebuild. Stateful or slow-to-provision workloads want deallocation; fully stateless fleets may prefer scale-in economics.
N simultaneous capacity requests at start
Starting the set asks the region for capacity for every instance at once. General-purpose sizes absorb that quietly; constrained SKUs such as GPU sizes and large memory-optimized machines can fail partially, leaving the set below strength at 8am. If mornings must be certain on a scarce SKU, that is the argument for capacity reservations, priced accordingly, or for not scheduling that particular set.
Autoscale keeps its own counsel
Autoscale rules attached to the set do not know about the calendar. Metric-based rules can add instances overnight in response to noise, and those additions bill. A scheduled set should have its autoscale profile aligned, with a night profile whose floor is zero, or the two systems will trade instances back and forth in the dark.
The overnight residual
Every deallocated instance’s disks keep billing per GB, multiplied by the instance count, plus any public load balancer and IP charges in front of the set. Per-instance disk cost times N is the floor the schedule cannot cross.