Inactive and Stopped VM

These idle VMs are often remnants of retired workloads, temporary environments, or paused projects that were never fully cleaned up. Without clear ownership or automated cleanup, they can persist unnoticed and accumulate avoidable charges.

While compute charges stop when a VM is in a deallocated (stopped) state, storage costs for the attached OS and data disks continue to accrue. Public IP addresses (Standard SKU, which are always static) continue to be billed while they exist, and snapshots and backup configurations may also generate charges.

• Identify virtual machines that have remained in a stopped (deallocated) state for the entire lookback period
• Flag VMs in the Stopped (allocated) state separately, for example VMs shut down from inside the guest OS or with the PowerOff operation: they are still billed for compute, so deallocate or delete them
• Review whether any activity has occurred from the associated managed disks, network interfaces, or backup processes
• Evaluate whether the VM is part of a dev/test or legacy environment with no recent usage
• Check for active reservations or static public IPs still assigned to the VM
• Validate with the application owner whether the VM or its data is still needed

Delete stopped VMs that are confirmed to be inactive and no longer required. Ensure that managed disks, static IPs, and snapshots are reviewed and cleaned up accordingly. If the data may be needed later, consider creating a snapshot or exporting the disk before deletion. Implement scheduled reviews of deallocated VMs to minimize waste across environments.

• Linux Virtual Machines Pricingazure.microsoft.com
• States and billing status of Azure Virtual Machineslearn.microsoft.com