Azure Virtual Machine
Does ZopNight manage Azure Virtual Machine?
An Azure VM bills per second for its allocated compute while running or merely stopped; only deallocation ends the compute meter. ZopNight discovers every VM through one Resource Graph query, watches 60 days of Azure Monitor metrics, and deallocates idle machines on schedule while managed disks and static IPs keep billing.
Rules that fire on Azure Virtual Machine
At a glance
| Field | Value |
|---|---|
| Scheduling notes | stopped via deallocate, which releases compute capacity and halts compute billing; started via the standard VM start operation. |
Azure Virtual Machines provide on-demand, scalable compute capacity for Windows and Linux workloads. Because VMs bill for every hour they are allocated, idle dev, test, and staging machines are one of the largest sources of avoidable Azure spend.
What the VM meter actually charges
A VM bills for its allocated compute, the vCPU and memory of its size, from the moment capacity is allocated until it is deallocated. The guest OS state is irrelevant to the meter: a machine shut down from inside Windows or Linux still holds its host allocation and still bills. Alongside compute, each VM accrues separate meters for its managed disks (billed on provisioned size), any static public IP, and OS licensing where Hybrid Benefit is not applied. Deallocation stops only the compute meter; the disk and IP meters continue.
How ZopNight discovers and evaluates VMs
Discovered in bulk via a single Azure Resource Graph query. Azure Monitor metrics with a 60-day lookback (for example Percentage CPU) feed idle and rightsizing detection, actual spend is attributed from the Cost Management query API, and recommendation rules cover rightsizing, dev/test Spot, Premium-to-Standard SSD, Hybrid Benefit, and reserved instances. Schedules and manual actions start and deallocate the VM.
Deallocate, never power off
ZopNight stops a VM via deallocate rather than a guest-OS shutdown, because only deallocation releases the compute reservation and halts billing. VMs in managed groups (VMSS members or Databricks-managed workers) are gated from individual scheduling, since their controllers would fight the schedule. Deallocation has trade-offs worth knowing: dynamic IPs are released, and constrained SKUs can hit capacity errors on restart.
Waste patterns worth checking first
Three patterns recur. Nightly shutdown scripts that power off the guest OS but never deallocate, which change nothing on the invoice. Non-production VMs running 168 hours a week when the team uses them for roughly 45. And deallocating VMs covered by a reservation: an Azure Reserved VM Instance bills regardless of state, so scheduling those saves nothing.
Where to find it in the portal
Azure portal → Virtual machines lists every VM in the subscription. Each VM’s Overview blade shows its status, whether Running, Stopped, or Stopped (deallocated), and only the last of these has actually stopped the compute meter.