A stopped VM is a virtual machine that is powered off but still allocated to Azure host capacity. The operating system is not running, but the VM has not released its compute allocation. That distinction matters because a stopped VM can still create compute charges, unlike a stopped deallocated VM. People often think “off” means “not billed,” and that mistake becomes expensive. Operators use the VM power state to decide whether the machine is intentionally paused, accidentally idle, ready for maintenance, or should be deallocated to stop compute billing.
stopped-vm, Stopped VM, VM stopped, Stopped allocated VM, PoweredOff VM, Azure VM stopped state
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-25
Microsoft Learn
Microsoft Learn describes a stopped Azure virtual machine as allocated on a host but not running, also called PoweredOff or Stopped (Allocated). This state can result from guest operating system shutdown or the PowerOff operation, and the VM remains billed for compute.
In Azure architecture, stopped VM is a power-state condition on an Azure Virtual Machine resource. The VM resource, managed disks, NICs, identities, extensions, backup configuration, and metadata still exist. The important technical distinction is whether Azure still allocates host compute capacity. Stopped or PoweredOff means allocated; Stopped (deallocated) means the compute allocation is released. The state appears through instance view, portal status, Azure Resource Graph, CLI list details, and cost reviews. Automation often uses this state to decide whether to start, deallocate, patch, image, or clean up VMs.
Why it matters
Stopped VM matters because it is one of the fastest ways to misunderstand Azure compute cost and operations. A developer may shut down a VM from inside Windows or Linux, see that the workload is not running, and assume spend has stopped. In reality, the VM can remain allocated and billed. That affects lab environments, training machines, temporary migration hosts, build workers, and disaster-recovery drills. The state also matters operationally: a stopped VM may preserve host allocation for a planned restart, while deallocation may release dynamic public IPs or change placement. Good operators know the difference before promising savings, availability, or restart behavior.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Virtual Machines portal status column, where a machine can show Stopped instead of Stopped (deallocated), changing cost expectations immediately for owners and reviewers.
Signal 02
In az vm list -d output, where powerState values let operators filter allocated stopped machines across resource groups before cost cleanup during scheduled FinOps review.
Signal 03
In Cost Management reviews, where compute charges may continue even though the workload owner says the VM was shut down from the guest OS after shutdown.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Find VMs shut down from the guest OS that still accrue compute charges because they remain allocated.
Prepare maintenance steps where a VM must be powered off briefly but restarted with predictable allocation behavior.
Separate stopped allocated machines from deallocated machines during lab, migration, or proof-of-concept cleanup.
Investigate an apparent workload outage by confirming whether the VM is stopped rather than slow or unreachable.
Build FinOps automation that recommends deallocation, deletion, or owner review based on VM power state and tags.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Animation studio stops paying for idle render coordinators
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
An animation studio shut down render coordinator VMs from inside Linux after nightly jobs, but finance still saw compute charges every weekend.
🎯Business/Technical Objectives
Identify VMs in Stopped allocated state across project subscriptions.
Separate machines needed for fast restart from forgotten idle compute.
Cut weekend compute waste without deleting render disks.
Create evidence for department chargeback discussions.
✅Solution Using Stopped VM
The cloud operations lead used Azure CLI with detailed VM listing to filter for powerState VM stopped. The team reviewed owner tags, render calendar entries, disk attachments, and public IP dependencies before taking action. VMs needed for Monday morning scheduler continuity stayed stopped but allocated through documented exceptions. Forgotten test coordinators were deallocated, not deleted, so disks and configurations remained available. A weekly script exported stopped allocated VMs, sent owners a review table, and deallocated approved nonproduction machines. Cost Management reports were updated to distinguish running, stopped allocated, and deallocated resources during show-level chargeback meetings.
📈Results & Business Impact
Weekend compute spend dropped by 31 percent in the first month without losing render project data.
Twenty-four forgotten stopped VMs were deallocated after owner review.
Two maintenance-critical coordinators kept allocated status with documented business justification.
Finance disputes fell by 70 percent because the exported power-state evidence was clear.
💡Key Takeaway for Glossary Readers
Stopped VM inventory turns a vague cost complaint into a precise lifecycle decision for each machine.
Case study 02
Vocational school cleans up cloud lab shutdown mistakes
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A vocational school taught Azure administration in evening labs, and students often shut down VMs from the guest OS instead of deallocating them.
🎯Business/Technical Objectives
Stop compute charges after each lab night.
Teach the difference between stopped allocated and deallocated states.
Preserve student disks for the next class session.
Reduce instructor cleanup time before budget review.
✅Solution Using Stopped VM
The instructor built a CLI-based lab closing script that listed VMs with power state and highlighted machines in VM stopped state. Students had to explain whether each VM should be started, deallocated, or kept allocated for an approved exercise. The script then deallocated non-exempt lab VMs while leaving managed disks intact. A second report listed remaining disk and public IP costs so students did not think deallocation made every cost disappear. The lab guide was updated with screenshots from instance view and CLI output, but grading used command evidence rather than portal navigation.
📈Results & Business Impact
Monthly lab compute charges fell from $3,900 to $1,450 after deallocation became part of class closeout.
Instructor cleanup time dropped from 90 minutes to 20 minutes per lab night.
Student quiz scores on VM billing states improved from 62 percent to 91 percent.
No lab disks were deleted accidentally during the first semester of automated cleanup.
💡Key Takeaway for Glossary Readers
The stopped VM state is a practical teaching moment because it connects power operations directly to Azure billing.
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
A manufacturing systems integrator needed to pause a production support VM during plant network maintenance without changing restart timing or network assumptions.
🎯Business/Technical Objectives
Power off the support VM during a firewall replacement window.
Keep the maintenance team clear on stopped versus deallocated behavior.
Avoid accidental release of dynamic network resources.
Restart and validate the support agent before production lines resumed.
✅Solution Using Stopped VM
The operations team documented that the VM should be stopped, not deallocated, for the four-hour maintenance window. Before the change, they used Azure CLI get-instance-view and VM show output to record the VM ID, power state, NIC, disk, and public IP settings. The VM was stopped through Azure automation and monitored until instance view showed VM stopped. A separate runbook warned the night-shift engineer not to run deallocate because the support tool expected the same network path after restart. After the firewall work, operators started the VM, confirmed the agent heartbeat, and saved power-state evidence in the maintenance ticket.
📈Results & Business Impact
The maintenance window finished 35 minutes early because restart behavior was predictable.
No support-tool endpoint changes were required after the VM returned online.
The team avoided a previous failure mode where deallocation changed assumptions during restart planning.
Post-maintenance validation time dropped from 50 minutes to 18 minutes with CLI evidence captured.
💡Key Takeaway for Glossary Readers
Sometimes the right answer is to keep a VM stopped but allocated, as long as that choice is intentional and documented.
Why use Azure CLI for this?
After ten years of Azure engineering, I use Azure CLI for stopped VM checks because the portal does not scale across subscriptions, labs, and resource groups. CLI can list VMs with power state, filter for VM stopped, compare them with deallocated machines, and start or deallocate them in controlled scripts. That turns cost cleanup into evidence instead of guesswork. It is also safer during maintenance: operators can get instance view, confirm the target state, record the VM ID, and avoid touching the wrong machine. For FinOps reviews, CLI output makes idle allocated compute visible quickly. during budget reviews. across subscriptions.
CLI use cases
List VMs with power state and filter for VM stopped across a resource group or subscription.
Get instance view for one VM before deciding whether to start, deallocate, resize, or delete it.
Deallocate nonproduction stopped VMs after checking owner tags, exclusions, and maintenance calendars.
Start a stopped VM during an approved maintenance or recovery window and confirm the new power state.
Export stopped allocated VM inventory for FinOps review, owner follow-up, or automation backlog tracking.
Before you run CLI
Confirm the subscription and resource group because stopping or deallocating the wrong VM can become an outage.
Check whether the VM is production, maintenance, lab, or migration infrastructure before changing power state.
Review permissions carefully because start, stop, and deallocate are mutating operations with operational and cost impact.
Understand whether dynamic public IPs, placement, or scheduled tasks depend on the VM remaining allocated.
Use queries and table output for inventory, then JSON output when saving evidence for cost or incident records.
What output tells you
powerState shows whether the VM is running, stopped allocated, deallocating, or stopped deallocated for billing decisions.
Instance view statuses reveal both provisioning state and power state, which helps separate deployment issues from shutdown state.
VM IDs, resource groups, and tags identify ownership and reduce the risk of acting on the wrong machine.
Network and disk references explain which attached resources may keep creating charges after compute state changes.
Activity logs and timestamps help determine whether shutdown came from automation, a user action, or the guest operating system.
Mapped Azure CLI commands
Stopped VM inspection and lifecycle operations
direct
az vm list -d --query "[?powerState=='VM stopped'].{name:name,resourceGroup:resourceGroup,powerState:powerState}" --output table
az vmdiscoverCompute
az vm get-instance-view --name <vm-name> --resource-group <resource-group> --output json
az vmdiscoverCompute
az vm stop --name <vm-name> --resource-group <resource-group>
az vmoperateCompute
az vm deallocate --name <vm-name> --resource-group <resource-group>
az vmoperateCompute
az vm start --name <vm-name> --resource-group <resource-group>
az vmoperateCompute
Architecture context
Architecturally, a stopped VM is still part of the compute estate. I do not treat it as removed capacity, retired infrastructure, or free standby. It remains a resource with disks, identities, network attachments, backup state, tags, policy scope, and possible billing. Some teams intentionally keep a VM stopped but allocated because they need predictable restart behavior during a maintenance window. More often, stopped allocated VMs are drift: training labs, proof-of-concepts, migration jump boxes, or failed deployments that nobody deallocated. A mature architecture defines start-stop automation, tagging, owner accountability, backup expectations, and when deallocation is allowed. The goal is not simply stopping VMs; it is choosing the correct lifecycle state.
Security
Security impact is indirect but real. A stopped VM is not serving workload traffic, yet its disks, managed identity, extensions, network interface, public IP configuration, and role assignments remain part of the environment. If the VM is restarted by an attacker or careless operator, old vulnerabilities, local accounts, exposed ports, or stale agents may return. Secrets can remain on attached disks even while compute is stopped. Security teams should review ownership, patch status, disk encryption, just-in-time access, public IPs, and whether the VM should be deallocated, isolated, or removed. Stopped does not mean secure; it only means not currently running.
Cost
Cost impact is direct and often surprising. A stopped allocated VM can continue compute billing because the host allocation remains reserved. Disks, snapshots, backup, public IPs, and monitoring may also continue to generate charges whether the VM is running or deallocated. Deallocating the VM is normally the compute-cost saving action, but it can affect restart behavior or dynamic network assignments. FinOps reviews should search for VMs with powerState VM stopped, not just running machines. Add owner tags, expiration tags, and automation for nonproduction schedules. The expensive mistake is believing guest shutdown is the same as Azure deallocation. during each review.
Reliability
Reliability impact depends on why the VM is stopped. For planned maintenance, a stopped allocated VM may restart predictably because Azure host capacity remains assigned. For cost cleanup, however, leaving machines stopped instead of deallocated can hide unhealthy dependencies and waste recovery planning effort. Operators should know whether dependent services expect the VM to return, whether backups are current, whether dynamic IP behavior matters, and whether deallocation would change availability assumptions. A stopped VM can also confuse monitoring if alerts only track running workloads. Reliable operations require explicit state labels, owner tags, restart tests, and clear runbooks for start, stop, deallocate, and delete actions.
Performance
Runtime performance is not active while the VM is stopped, but performance planning is still affected. Keeping a VM stopped but allocated can support faster, more predictable restart during a maintenance window because capacity remains assigned. Deallocation can save compute cost but may add start delay, placement change, or warm-up time for agents and applications. Performance diagnostics also suffer if a stopped VM is mistaken for a slow VM. Operators should check power state before investigating CPU, memory, disk, or network metrics. In automation, filtering stopped machines quickly improves operational performance by focusing engineers on true running workload bottlenecks. during triage.
Operations
Operators inspect stopped VMs through instance view, VM list details, Resource Graph, tags, activity logs, and cost reports. Common actions include starting a VM, deallocating it to release compute billing, checking whether shutdown came from the guest OS, and validating whether disks or public IPs still create charges. Runbooks should separate stop from deallocate and define who can perform each action. During cleanup, operators should confirm owner, environment, backup requirement, maintenance window, and any dependency before deallocating. During incidents, power state checks help distinguish a workload outage from a VM that someone intentionally or accidentally shut down. with documented approval.
Common mistakes
Assuming guest OS shutdown stops Azure compute billing when the VM remains in Stopped or PoweredOff allocated state.
Deallocating a VM without checking whether dynamic public IP release or placement change will break a dependency.
Ignoring attached disks, backup, snapshots, or monitoring charges after compute has been stopped or deallocated.
Treating a stopped VM as retired infrastructure while stale identities, secrets, and public endpoints still exist.
Running cleanup scripts without owner tags or exclusions and powering down machines needed for maintenance windows.