Skip to article
Compute Virtual Machine Scale Sets

VM scale set instance

A VM scale set instance is an individual virtual machine that belongs to an Azure Virtual Machine Scale Set. Operators can inspect, restart, reimage, update, delete, or run commands against specific instances while the scale set manages the broader group model.

Source: Microsoft Learn - Virtual Machine Scale Set VMs - REST API Reviewed 2026-05-29

Exam trap
Running instance actions with wildcard IDs and accidentally restarting or reimaging every VM in the scale set.
Production check
List instances and confirm the exact ID, zone, power state, and health status before action.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
VM scale set instance, vm scale set instance
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-29
Review level
field-manual
Article depth
operator-field-manual
Learning paths Graph VM compute operations VM scale set instance
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A VM scale set instance is one VM inside a scale set. The scale set defines the model and capacity, but users and incidents often happen at the instance level: instance 3 is unhealthy, instance 7 has an extension problem, or instance 12 needs reimage. In uniform scale sets, instances are meant to be interchangeable. In flexible scale sets, they can be managed more like individual VMs while still belonging to the scale set grouping. Understanding the instance helps operators avoid treating the whole fleet as one anonymous block.

Why it matters

VM scale set instance matters because production failures rarely announce themselves as “the whole scale set is broken.” More often, one instance fails health probes, keeps an old model, loses an extension, fills a disk, or behaves differently during rolling upgrade. Instance-level visibility lets operators repair the smallest possible unit instead of disrupting the entire fleet. It also helps architects reason about scale-in protection, upgrade domains, load-balancer membership, zone spread, and health signals. Without instance awareness, teams either ignore bad nodes or overreact with full fleet redeployments, both of which increase downtime and operational risk. Record the selected instance ID and expected fleet behavior before acting.

Technical context

Technically, a scale set instance is represented under Microsoft.Compute/virtualMachineScaleSets/virtualMachines with an instance ID. It has instance view, power state, health status, network interfaces, extension status, disks, and sometimes protection policy settings. Azure CLI exposes instance-level actions through az vmss list-instances, get-instance-view, restart, reimage, delete-instances, run-command, and update-instances. The instance sits below the scale set model and above the guest OS, bridging fleet orchestration, load balancing, application health, and VM-level troubleshooting. Record the selected instance ID and expected fleet behavior before acting.

Exam context

Compare with

Virtual machine Virtual machine scale set Scale set capacity

Where it is used

Where you see it

  1. In the VM scale set Instances blade, each row shows instance ID, power state, health, zone, latest model status, and available operator actions for production review.
  2. In Azure CLI, az vmss list-instances and get-instance-view expose per-instance IDs, statuses, update state, extension results, and troubleshooting clues for one node for production review.
  3. In autoscale and health logs, instance events show when Azure created, removed, upgraded, restarted, or replaced individual nodes during capacity or repair activity for production review.

Common situations

  • Repair one unhealthy backend instance without restarting or reimaging the entire scale set fleet.
  • Find instances that have not applied the latest scale set model after a manual or rolling upgrade.
  • Protect or inspect specific instances that hold temporary state during a controlled scale-in event.
  • Run targeted diagnostics on one VMSS instance that fails health probes while neighbors remain healthy.
  • Correlate instance ID, zone, and health data during autoscale or load-balancer incident reviews.

Illustrative Azure scenarios

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

Scenario 01 E-commerce search tier repairs one bad backend E-commerce search tier repairs one bad backend: Instance-level operations let teams fix the smallest broken unit in a scale set instead of disturbing the entire fleet.
Scenario

An e-commerce marketplace ran search workers on a VM scale set, and one backend instance began failing health probes after a rolling extension update.

Goals
  • Identify the exact unhealthy instance without disrupting healthy search capacity.
  • Restore full backend pool health before the evening traffic peak.
  • Preserve enough serving capacity during repair.
  • Understand whether the issue was model drift or guest extension failure.
Approach using VM scale set instance

The operations team used VM scale set instance visibility instead of redeploying the whole fleet. Azure CLI listed instances with power state and latest model status, then get-instance-view exposed that instance 18 had a failed monitoring extension and stale application process. The load balancer had already removed it from rotation, so the team had enough healthy capacity to repair one node. They invoked a small run command on instance 18 to collect logs, then restarted only that instance. When the extension still failed, they reimaged the same instance and let the scale set apply the current model. After reimage, the instance passed health probes and rejoined the backend pool. The incident notes recorded instance ID, zone, model version, and remediation timeline.

Potential outcomes
  • Full backend health returned 37 minutes before the traffic peak.
  • Healthy instances continued serving search with no site-wide outage.
  • Reimage of one instance replaced a risky full-fleet rollback.
  • The extension rollout pipeline gained a canary instance-view gate.
What to learn

Instance-level operations let teams fix the smallest broken unit in a scale set instead of disturbing the entire fleet.

Scenario 02 Telematics provider traces zone-specific autoscale failures Telematics provider traces zone-specific autoscale failures: Scale set instance data is what turns a vague fleet issue into a precise zone, model, or node-level diagnosis.
Scenario

A telematics platform noticed delayed vehicle-position processing after autoscale added capacity, but only new instances in one availability zone failed to process messages.

Goals
  • Correlate failed workers with instance IDs and zones.
  • Maintain ingestion capacity while investigating the bad zone pattern.
  • Capture enough instance evidence for Azure and network teams.
  • Avoid deleting healthy instances created during the same autoscale event.
Approach using VM scale set instance

Engineers exported az vmss list-instances output and joined it with application heartbeat data. The failing instances shared one zone and a new model version, while older instances in other zones processed normally. Instance view showed successful provisioning but a custom extension timeout. The team protected healthy instances from scale-in, paused further autoscale increases, and ran a diagnostic command on two failed instance IDs to check package repository access. The output pointed to a zone-scoped route table change affecting extension downloads. Network engineers reverted the route, and the platform team reimaged only the failed instances so they could rebuild from the corrected path. Fleet capacity and queue length were watched until the backlog cleared.

Potential outcomes
  • Average vehicle-position delay dropped from 9.5 minutes to 52 seconds after targeted repair.
  • Only seven failed instances were reimaged, avoiding disruption to 41 healthy workers.
  • Autoscale was paused for 28 minutes instead of being disabled for the day.
  • The team added zone and instance ID fields to the live operations workbook.
What to learn

Scale set instance data is what turns a vague fleet issue into a precise zone, model, or node-level diagnosis.

Scenario 03 Industrial IoT gateway protects state during scale-in Industrial IoT gateway protects state during scale-in: Even in scalable fleets, instance-level context matters when temporary state or safety-critical data exists on particular nodes.
Scenario

An industrial IoT provider used flexible VM scale sets for edge-ingestion gateways, and autoscale wanted to remove instances that still buffered plant telemetry during network outages.

Goals
  • Prevent scale-in from deleting instances with buffered telemetry.
  • Identify which instances held local queue state.
  • Reduce manual portal inspection during outage response.
  • Return to normal autoscale once queues drained.
Approach using VM scale set instance

The platform team added instance-aware operations to the outage runbook. A scheduled diagnostic collected local queue depth from each gateway instance and wrote a summarized status to monitoring. During a plant connectivity incident, engineers listed VM scale set instances, matched instance IDs to queue-depth alerts, and protected the three instances holding buffered telemetry from scale-in actions. Stateless instances remained eligible for autoscale. Once plant links recovered, run command verified that the protected queues drained to zero, and the protection flags were removed. The team did not change the scale set model; they used instance-level information to make a temporary operational exception that respected application state.

Potential outcomes
  • No buffered telemetry files were lost during the scale-in event.
  • Manual instance triage dropped from 45 minutes to under 10 minutes.
  • Autoscale still removed five stateless instances, saving compute during the outage.
  • Queue-drain confirmation became a required step before removing protection.
What to learn

Even in scalable fleets, instance-level context matters when temporary state or safety-critical data exists on particular nodes.

Azure CLI

I use Azure CLI for scale set instances because the portal becomes slow and imprecise when a fleet has dozens or hundreds of VMs. A senior Azure engineer wants to list instance IDs, power states, zones, latest model status, health, NICs, and extension failures quickly. CLI also lets you target one instance for restart, reimage, run command, or deletion while preserving the rest of the fleet. That precision is essential during rolling upgrades and incidents. It also produces repeatable evidence for autoscale reviews, load-balancer troubleshooting, and postmortems where instance 14 behaved differently from instance 15. Record the selected instance ID and expected fleet behavior before acting.

Useful for

  • List all instances with IDs, power states, zones, and latest model status for fleet triage.
  • Get instance view for one instance to inspect VM agent, extension, and health status.
  • Restart, reimage, delete, or run command against selected instance IDs instead of the whole scale set.
  • Export instance inventory before and after rolling upgrades or autoscale events for audit evidence.

Before you run a command

  • Confirm the scale set name, resource group, orchestration mode, and exact instance IDs before any instance-level action.
  • Check current capacity, load-balancer health, autoscale rules, and scale-in protection before removing or restarting instances.
  • Understand whether the instance is stateless, stateful, protected, or handling active sessions before repair.
  • Use table output for triage and JSON output for scripts that act on instance IDs.

What the output tells you

  • List-instances output identifies instance IDs, model status, zones, power state, and resource IDs used for precise targeting.
  • Instance-view output shows VM agent, extension, health, boot diagnostics, and status information for one scale set VM.
  • Run-command or restart results apply to selected instance IDs, so output must be matched back to each targeted instance.
  • Unexpected missing instances may indicate scale-in, failed provisioning, overprovisioning cleanup, or an autoscale action already completed.

Mapped commands

VM scale set instance operations

direct 
az vmss list-instances --resource-group <resource-group> --name <scale-set-name> --output table
az vmssdiscoverCompute
read-only Microsoft Learn 
az vmss get-instance-view --resource-group <resource-group> --name <scale-set-name> --instance-id <instance-id>
az vmssdiscoverCompute
read-only Microsoft Learn 
az vmss restart --resource-group <resource-group> --name <scale-set-name> --instance-ids <instance-id>
az vmssoperateCompute
mutating Microsoft Learn 
az vmss run-command invoke --resource-group <resource-group> --name <scale-set-name> --instance-id <instance-id> --command-id RunShellScript --scripts "<script>"
az vmss run-commandoperateCompute
mutating Microsoft Learn 
az vmss update-instances --resource-group <resource-group> --name <scale-set-name> --instance-ids <instance-id>
az vmssoperateCompute
mutating Microsoft Learn

Architecture context

Architecturally, scale set instances are the replaceable execution units behind a scalable compute tier. The scale set model defines the desired fleet, but each instance participates in networking, health probes, upgrade policy, zone placement, identity, extension execution, and application capacity. Good architecture assumes instances can be created, drained, repaired, and removed without drama. That requires stateless application design where possible, externalized state, rolling upgrade policy, monitoring per instance, and safe scale-in rules. For flexible orchestration, architects also account for more individual VM behavior while retaining group-level lifecycle and availability benefits. Record the selected instance ID and expected fleet behavior before acting.

Security
Security impact is direct at the operational boundary. Each instance can have guest vulnerabilities, extension failures, exposed public IP configuration, managed identity behavior, and local drift. The scale set model may be compliant while one instance is unhealthy or outdated. Operators should inspect instance extension status, patch state, identity use, network interface exposure, and run-command access before declaring the fleet safe. Limit instance-level actions to trusted roles because deleting, reimaging, or running commands on the wrong instance can disrupt service or expose data. Monitoring should identify security drift per instance, not only at the scale set resource. Record the selected instance ID and expected fleet behavior before acting.
Cost
The scale set resource itself has no extra charge beyond underlying compute, storage, and networking, but each instance contributes directly to spend. Instance count, size, disk configuration, public IPs, diagnostics, and extensions all matter. Bad instances can waste money by staying unhealthy but allocated, repeatedly failing upgrades, or causing scale-out compensation. Deleting or deallocating instances may reduce compute cost but can also reduce capacity below safe levels. FinOps reviews should correlate instance count with autoscale rules, utilization, health, and reservation coverage. A scale set full of idle instances is still a fleet of billable VMs. Record the selected instance ID and expected fleet behavior before acting.
Reliability
Reliability depends on instance health and how safely the fleet reacts when one unit fails. A scale set should tolerate unhealthy instances through load-balancer probes, application health, autoscale, automatic repairs, or rolling upgrades. Instance-level operations let teams restart, reimage, or delete one bad node while preserving capacity. The risk is targeting too many instances at once or ignoring scale-in protection for stateful roles. Track zones, update domains, latest model status, and application health per instance. During incidents, prefer canary repair on one instance, then expand only if telemetry proves the pattern. Record the selected instance ID and expected fleet behavior before acting.
Performance
Performance is visible at the instance level because averages hide bad nodes. One instance may have high CPU, disk pressure, slow boot, extension failure, cold cache, or poor application latency while fleet averages look acceptable. Operators should compare instance metrics, health probes, queue depth, and request distribution before deciding whether to resize, reimage, restart, or scale out. For rolling upgrades, watch whether new instances reach healthy state fast enough to maintain capacity. Performance tuning should distinguish fleet capacity from instance anomalies; otherwise teams add more VMs while one broken instance keeps dropping traffic. Record the selected instance ID and expected fleet behavior before acting.
Operations
Operators inspect scale set instances during upgrades, autoscale events, health probe failures, extension rollouts, and application incidents. Common tasks include listing instances, checking instance view, identifying stale model versions, running a diagnostic command on one node, restarting a bad instance, or deleting an instance so the scale set replaces it. Good runbooks record instance ID, zone, fault or update domain, health probe result, recent action, and owner service. After remediation, operators verify the instance rejoins the load balancer, reports healthy telemetry, and matches the expected model. Record the selected instance ID and expected fleet behavior before acting. Record the selected instance ID and expected fleet behavior before acting.

Common mistakes

  • Running instance actions with wildcard IDs and accidentally restarting or reimaging every VM in the scale set.
  • Troubleshooting only the scale set model while ignoring one unhealthy instance with bad extension or guest state.
  • Deleting a protected or stateful instance without understanding scale-in policy, local state, or active connections.
  • Assuming uniform and flexible orchestration expose exactly the same operational behavior for individual instances.