Skip to article
Compute Virtual Machines

VM stop operation

VM stop operation is the Azure Compute action that powers off a running virtual machine. It stops the guest from running workloads, but it is different from deallocation; use deallocate when the goal is to release compute allocation and avoid VM compute charges.

Source: Microsoft Learn - az vm stop Reviewed 2026-05-29

Exam trap
Using az vm stop for cost savings when az vm deallocate or an auto-shutdown policy was actually required.
Production check
List target VMs with name, power state, tags, size, and owner before running any stop command.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
VM stop operation, vm stop operation
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-29
Review level
field-manual
Article depth
operator-field-manual
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

VM stop operation powers off an Azure VM from the Azure side. It is useful when you need a clean shutdown, a maintenance pause, or a controlled halt before another operation. The important learner trap is cost and state: stopping is not always the same as deallocating. A stopped VM may still keep allocated compute and continue billing, while disks and related resources remain either way. Operators use stop carefully because users lose service, scheduled jobs pause, and applications may need graceful shutdown steps before power is removed.

Why it matters

VM stop operation matters because shutdown semantics are a common source of outages and cost surprises. A team may stop a VM thinking spend has ended, only to learn compute is still billed until deallocation. Another team may stop a server too abruptly and corrupt an in-memory queue, leave a database transaction half-finished, or interrupt a deployment. Used correctly, stop gives operators a controlled way to halt a workload before patching, resizing, imaging, or dependency maintenance. Used casually, it creates downtime, confusion about power states, and tickets from users who expected the service to remain online. That is why wording and runbook intent must be unambiguous.

Technical context

Technically, stop is a Microsoft.Compute action on an existing virtualMachines resource. It changes the VM power state and asks the platform to power off the guest, with an option in CLI to skip shutdown and power off immediately. It preserves the VM resource, disks, NICs, identity, tags, and configuration. It sits near start, deallocate, restart, redeploy, and resize, but its billing and allocation semantics differ from deallocate. Logs, instance view, boot diagnostics, guest shutdown events, and Activity Log provide the operational evidence.

Exam context

What to know

operator-ready

Compare with

VM deallocate operation VM start operation VM restart operation

Where it is used

Where you see it

  1. In Azure CLI help, az vm stop appears as a separate command from az vm deallocate, with different billing and allocation implications. during planned maintenance and cost reviews.
  2. In the Azure portal VM Overview blade, power controls show Stop alongside Restart, Start, and other operations that affect service availability. that can interrupt running workloads.
  3. In Activity Log, stop events mark the operator, timestamp, and target VM, helping teams explain planned downtime or accidental service interruption. or explain why users lost access.

Common situations

  • Gracefully halt a VM before guest maintenance, software installation, image capture, or dependency changes.
  • Pause a nonproduction server briefly while preserving allocation, then start it again after a controlled window.
  • Stop one cluster node only after traffic draining and quorum checks prove the workload can tolerate it.
  • Contain a suspicious server while preserving disks and evidence for later investigation or snapshot capture.
  • Separate operational shutdown from deallocation so teams choose the right action for availability versus cost reduction.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Film archive stops transcoder before storage maintenance Film archive stops transcoder before storage maintenance: Stop is useful when the goal is a controlled short pause, not necessarily cost release.
Scenario

A public film archive ran a VM-based transcoder that wrote large files to a shared storage target scheduled for maintenance.

Goals
  • Prevent partial video outputs during the storage window.
  • Stop the VM only after active transcode jobs drained.
  • Avoid confusing stop with deallocation because the maintenance window was short.
  • Record exactly when processing capacity was removed.
Approach using VM stop operation

The media operations engineer used VM stop operation after the archive scheduler showed zero active transcode jobs. CLI output captured the VM name, owner tag, job queue depth, and current power state before shutdown. Because the storage team needed a 30-minute pause rather than cost savings, the runbook used az vm stop instead of deallocate, preserving allocation for a faster restart. Activity Log evidence was attached to the maintenance ticket, and the scheduler was held in paused mode until storage health probes passed. After restart, a checksum job verified that no partial outputs were published.

Potential outcomes
  • No corrupted or partial video files were created during storage maintenance.
  • The VM restarted seven minutes faster than prior deallocate/start maintenance cycles.
  • Processing downtime stayed within the approved 45-minute archive window.
  • The team added explicit stop-versus-deallocate wording to maintenance templates.
What to learn

Stop is useful when the goal is a controlled short pause, not necessarily cost release.

Scenario 02 Training platform pauses exam sandbox during licensing update Training platform pauses exam sandbox during licensing update: A stop operation should be coordinated with application draining, not treated as the first step.
Scenario

A certification provider hosted exam sandbox software on a Windows VM and needed to pause it while a third-party license server changed keys.

Goals
  • Stop the sandbox before candidates could launch unstable exam sessions.
  • Preserve VM allocation for a fast return after vendor validation.
  • Warn support teams with an accurate downtime timeline.
  • Avoid terminating queued reports stored on attached managed disks.
Approach using VM stop operation

The platform owner first blocked new exam launches at the application layer, then waited for active sessions to close. They used VM stop operation through CLI, not deallocate, because the vendor expected testing to resume within the hour. The command output, Activity Log record, and application-drain timestamp were copied to the support bridge. During the stop period, license keys were rotated and the database team verified that report queues were empty. The VM was started again only after the vendor endpoint and sandbox health check succeeded. A later review turned the process into a checklist for future vendor maintenance.

Potential outcomes
  • Candidate disruption was limited to 11 scheduled users, all rebooked before the next day.
  • No exam reports were lost or duplicated after the sandbox returned.
  • Support tickets used the planned timeline instead of conflicting outage guesses.
  • The licensing maintenance checklist cut the next pause from 54 minutes to 31 minutes.
What to learn

A stop operation should be coordinated with application draining, not treated as the first step.

Scenario 03 Utility simulator is stopped for controlled incident containment Utility simulator is stopped for controlled incident containment: Stop can be an incident containment tool when it is paired with evidence capture and network controls.
Scenario

An electric utility's engineering team noticed unusual outbound connections from a VM that simulated grid devices for testing vendor software.

Goals
  • Stop possible outbound activity without deleting forensic evidence.
  • Preserve disks for later malware and configuration review.
  • Keep production grid systems unaffected by the simulator incident.
  • Document the containment timeline for cyber leadership.
Approach using VM stop operation

The security engineer confirmed the VM was a lab simulator and not part of production control. Because network isolation was already applied through NSG changes, the team used VM stop operation to halt guest activity while preserving the VM resource and attached disks. They captured Activity Log entries, NIC configuration, Defender alerts, and the exact stop timestamp before taking disk snapshots for analysis. The runbook specifically avoided deallocation language because the immediate goal was containment and evidence preservation, not cost optimization. A separate decision later determined whether the VM would be rebuilt from a clean image.

Potential outcomes
  • Suspicious outbound traffic stopped within six minutes of the containment decision.
  • Forensic snapshots were captured before any rebuild or cleanup changed evidence.
  • Production monitoring showed no related alerts in the grid operations subscription.
  • The cyber timeline met internal reporting requirements with exact Azure operation IDs.
What to learn

Stop can be an incident containment tool when it is paired with evidence capture and network controls.

Azure CLI

I use Azure CLI for stop operations because stopping servers is a high-consequence action that benefits from filtering, evidence, and automation. With CLI, I can preview candidate VMs by tag, exclude production, capture owner and power state, then stop only the approved machines. A ten-year Azure engineer also wants the exact command in the change ticket, not a vague memory of a portal click. CLI supports bulk stops, wait logic, JSON output, and integration with schedules. It also makes the difference between az vm stop and az vm deallocate explicit, which prevents expensive misunderstanding. It also avoids confusing shutdown with real cost release.

Useful for

  • Stop one approved VM with az vm stop after owner, environment, and dependency checks pass.
  • Bulk-stop tagged development machines while excluding production and stateful cluster members.
  • Use --skip-shutdown only for emergency containment where graceful guest shutdown is not possible.
  • Compare stopped VMs against deallocated VMs to find machines that still create compute charges.
  • Export before-and-after power states for a maintenance record or incident timeline.

Before you run a command

  • Confirm whether the business goal is shutdown, deallocation, restart, or deletion before choosing the command.
  • Verify subscription, resource group, VM name, environment tag, and owner approval because stop causes downtime.
  • Check dependencies, load balancer membership, running jobs, database role, replication state, and backup activity first.
  • Understand that stopped is not necessarily stopped-deallocated, so compute billing may continue.
  • Avoid --skip-shutdown unless immediate power-off is safer than waiting for the guest to shut down cleanly.

What the output tells you

  • Instance view shows whether the VM moved from running to stopped, stopping, or another transitional state.
  • Activity Log output records the caller, operation name, target resource ID, result, and timing of the stop.
  • Cost and power-state reports help identify stopped machines that still have allocated compute resources.
  • Guest shutdown logs reveal whether services exited cleanly or were interrupted before completing work.
  • Tag and ID fields confirm automation stopped the intended environment rather than a similarly named production VM.

Mapped commands

VM stop operation operations

direct 
az vm stop --name <vm-name> --resource-group <resource-group>
az vmoperateCompute
mutating Microsoft Learn 
az vm stop --ids $(az vm list -g <resource-group> --query "[].id" -o tsv)
az vmoperateCompute
mutating Microsoft Learn 
az vm deallocate --name <vm-name> --resource-group <resource-group>
az vmoperateCompute
cost-impacting Microsoft Learn 
az vm get-instance-view --name <vm-name> --resource-group <resource-group> --output json
az vmdiscoverCompute
read-only Microsoft Learn 
az monitor activity-log list --resource-group <resource-group> --offset 2h
az monitor activity-logdiscoverCompute
read-only Microsoft Learn

Architecture context

Architecturally, VM stop operation belongs to lifecycle control and maintenance orchestration. It is not a resilience feature; it intentionally removes a VM from service. In a well-designed workload, stop is coordinated with load balancer draining, application shutdown hooks, job schedulers, backup windows, and dependency notifications. For stateful systems, the architecture must decide whether the application can tolerate a stopped node, whether quorum remains, and whether data is safely flushed. For nonproduction environments, stop may be part of cost governance, but deallocation or auto-shutdown is usually the stronger FinOps control when compute allocation should be released. The stop plan should therefore be owned by the workload, not only infrastructure.

Security
Security impact is indirect but meaningful. Stopping a VM can pause monitoring agents, vulnerability scans, endpoint protection reporting, and log forwarding, which may create blind spots until the VM starts again. It can also preserve a vulnerable disk image that later returns with the same risks. Access control matters because anyone who can stop production VMs can cause an availability incident. Confirm RBAC, change approval, and Activity Log evidence before stopping sensitive servers. If the stop is part of incident containment, preserve disk snapshots and forensic logs before shutdown when possible. Security teams should know when protective telemetry is intentionally silent.
Cost
Cost impact is frequently misunderstood. The stop action itself does not delete disks, snapshots, backups, public IPs, licenses, or monitoring resources. More importantly, az vm stop powers off the VM but does not release compute allocation; deallocation is the command that stops compute charges for the VM. That difference matters in dev/test and lab environments where teams expect savings. The practical FinOps pattern is to use stop only when allocation must be preserved briefly, and use deallocate or auto-shutdown when the goal is cost reduction. Audit stopped-but-still-billed VMs regularly. Dashboards should call out this difference in plain language.
Reliability
Reliability impact is direct because stop removes compute capacity. It may be safe for a single development server, but dangerous for quorum-based clusters, schedulers, domain services, jump hosts, or legacy applications that do not restart cleanly. Reliable use means draining traffic, pausing jobs, checking replication, notifying owners, and verifying enough remaining instances exist. A graceful stop is preferable to immediate power off for most workloads, but even graceful shutdown must be tested. After a stop, runbooks should define who can start the VM, how health is verified, and when deallocation is appropriate. Use stop only when the remaining architecture can absorb the capacity loss.
Performance
Performance impact is operational rather than tuning. Stopping a VM drops workload throughput to zero, clears in-memory caches, closes connections, and may force recovery work during the next start. For applications with long warm-up, stop can create later latency spikes even if the shutdown was planned. Immediate power-off can worsen recovery by bypassing graceful service shutdown. Performance-sensitive runbooks drain traffic first, record queue depth, stop during low demand, and verify startup behavior afterward. In batch environments, stop timing determines whether jobs resume cleanly or reprocess work when the VM returns. That evidence prevents surprises when the server is started again.
Operations
Operators stop VMs during maintenance, cost controls, incident containment, and environment schedules. The operational pattern starts with inventory: owner, environment, role, current power state, dependencies, and whether the VM participates in a scale set, cluster, or load-balanced pool. Then the operator drains or notifies users, performs the stop, and confirms the resulting state. Good scripts produce a before-and-after report and flag VMs that failed to stop. Operations teams should also distinguish stop from deallocate in naming, tickets, and runbooks, because that distinction changes billing and future allocation behavior. This reporting prevents abandoned stopped servers and accidental production interruptions during audits.

Common mistakes

  • Using az vm stop for cost savings when az vm deallocate or an auto-shutdown policy was actually required.
  • Stopping a VM that owns quorum, scheduling, licensing, or database primary duties without draining or failover.
  • Assuming a stopped VM no longer needs patching, monitoring, encryption review, or vulnerability tracking.
  • Using immediate power-off for convenience and causing longer recovery or data consistency checks later.
  • Bulk-stopping all VMs in a resource group that mixes dev, shared services, and production workloads.