Cloud / Azure Virtual Machine Scale Sets Interview questions

An Azure Virtual Machine Scale Set (VMSS) is a compute resource that lets you create and manage a group of load-balanced virtual machines as one unit. The number of instances can grow or shrink automatically, based on demand or a schedule you define.

You describe the VM once (image, size, disks, network, extensions) and Azure stamps out as many copies as you ask for. That description is called the scale set model.

Scale sets are typically placed behind an Azure Load Balancer or Application Gateway, and they spread instances across fault domains or availability zones for resilience. There is no separate charge for the scale set itself, only for the VMs, disks and networking it uses.

A scale set gives you elasticity, consistency and availability without managing each VM by hand.

• Autoscale: add or remove instances based on metrics or schedules, so you pay for what you need.
• Consistency: every instance is built from the same model, which removes configuration drift.
• High availability: instances are spread across fault domains or availability zones.
• Scale: a single scale set can hold up to 1,000 instances.
• Easy updates: change the model once, then roll it out manually, automatically or in rolling batches.
• Integration: works natively with Load Balancer, Application Gateway, Azure Monitor and managed identities.

A scale set supports two orchestration modes: Uniform and Flexible. You pick the mode when you create the scale set, and it cannot be changed afterwards.

Uniform runs identical instances that are managed through scale-set specific APIs. It suits large, stateless fleets where every VM is a clone of the model.

Flexible treats each instance as a regular Azure VM resource. You can use normal VM operations on them and, in some cases, mix VM configurations. Microsoft recommends Flexible for new deployments.

A scale set can build instances from Azure Marketplace images, custom images you captured yourself, or images stored in an Azure Compute Gallery.

Marketplace images are the quickest start (for example Ubuntu or Windows Server). Compute Gallery is the better choice for production because it gives you image versions, replication across regions and RBAC-based sharing.

In the image reference you can pin a version (repeatable builds) or use latest (always the newest published version). Pinning is safer for controlled rollouts; latest is required for automatic OS image upgrades.

The model is the desired configuration of the scale set: image, VM size, disks, network profile, extensions and so on. The instance view is the current runtime state of each VM: provisioning state, power state and extension status.

The two can differ. If you change the model (say a new image version) and the upgrade policy is manual, existing instances keep running the old configuration until you update them. In Uniform mode each instance reports whether it has the latest model applied.

az vmss show -g rg-demo -n web-vmss
az vmss get-instance-view -g rg-demo -n web-vmss

Think of the model as the blueprint and the instance view as a health report on what was actually built.

Autoscaling automatically changes the number of instances in a scale set to match load. It is provided by Azure Monitor autoscale, not by the scale set itself.

An autoscale setting contains one or more profiles. Each profile defines a minimum, maximum and default instance count, plus rules that say when to scale out or in. Autoscale never goes below the minimum or above the maximum.

This keeps performance steady at peak and cuts cost when demand drops. It works best with stateless instances that can be added or removed at any time.

Scale sets support three approaches to automatic scaling:

You can combine them. A recurring profile can raise the minimum during working hours while metric rules still handle surprise spikes. Predictive autoscale needs a few days of history and can be run in forecast-only mode first to check its accuracy.

Use az vmss create. Create a resource group first, then give the command an image, a size, an instance count and credentials.

az group create -n rg-demo -l eastus

az vmss create \
  -g rg-demo -n web-vmss \
  --image Ubuntu2204 \
  --vm-sku Standard_D2s_v5 \
  --instance-count 2 \
  --orchestration-mode Flexible \
  --admin-username azureuser \
  --generate-ssh-keys \
  --zones 1 2 3

The command also creates a virtual network and a load balancer if you do not point it at existing ones. Use --lb or --vnet-name and --subnet to reuse your own. Check the result with az vmss list-instances.

Set a new capacity with az vmss scale, PowerShell's Update-AzVmss -SkuCapacity, or the Instances blade in the portal.

az vmss scale -g rg-demo -n web-vmss --new-capacity 5

Azure adds or deletes instances until the count matches. When scaling in, the scale-in policy decides which VMs go.

Be careful if autoscale is enabled. Autoscale enforces its own minimum and maximum, so a manual value outside that range will be corrected on the next evaluation. For a lasting manual change, adjust the autoscale limits or disable autoscale.

A placement group is an internal grouping of VMs, similar to an availability set, with its own fault domains and update domains. It mostly matters in Uniform mode.

By default a scale set uses a single placement group (singlePlacementGroup=true), which caps it at 100 instances. Setting it to false lets the scale set use multiple placement groups and grow to 1,000 instances.

Large multi-group scale sets need a Standard load balancer and Standard public IPs. Flexible mode handles spreading on its own through its fault domain count and zones, so you rarely tune placement groups there.

There is no extra charge for the scale set resource itself. You pay for the underlying resources it creates and runs.

• VM compute hours for each running instance (including OS licensing for Windows or paid Marketplace images)
• Managed disks, both OS and data disks
• Networking: load balancer, public IPs and outbound data transfer
• Optional services such as Azure Monitor logs and backup

Instances that are stopped (deallocated) stop billing for compute, but their disks still cost money. Reserved Instances, Savings Plans, Azure Hybrid Benefit and Spot pricing all apply to scale set VMs, and autoscale itself is free.

A load balancer gives clients a single address and distributes inbound traffic across healthy instances. Without it, you would need to track every instance IP yourself.

• Load-balancing rules send traffic from a frontend port to the backend pool (the scale set).
• Health probes check each instance and remove failing ones from rotation.
• Inbound NAT rules can forward ports to individual instances for admin access.
• Outbound rules control SNAT for instances without public IPs.

Use the Standard SKU. Basic Load Balancer has been retired, and Standard supports zone redundancy and large scale sets. For HTTP routing or WAF, use Application Gateway instead.

The Custom Script Extension downloads and runs a script on each instance after it is provisioned. It is the quickest way to install packages or configure an app when the base image is generic.

az vmss extension set -g rg-demo --vmss-name web-vmss \
  --name CustomScript --publisher Microsoft.Azure.Extensions --version 2.1 \
  --settings '{"commandToExecute":"apt-get update && apt-get install -y nginx"}'

The script runs once per instance at provisioning. To run it again, change the settings (for example with forceUpdateTag). Keep scripts idempotent, and put credentials in protectedSettings, which is encrypted, rather than in public settings.

For fast scale-out, baking the app into a custom image is better than running long scripts on every new VM.

Horizontal scaling changes the number of instances (scale out and scale in). Vertical scaling changes the size of each instance (scale up and scale down).

Scale sets are designed for horizontal scaling. Vertical scaling means editing the SKU in the model and rolling the change through the instances, which is slower and disruptive.

Spot VMs use Azure's spare compute capacity at a deep discount (up to around 90 percent off), with the catch that Azure can evict them when it needs the capacity back or when your maximum price is exceeded.

You choose an eviction policy: Deallocate keeps the disks (and their cost) while Delete removes everything. Setting max price to -1 means you pay up to the on-demand price and are only evicted for capacity. Evictions give about 30 seconds of notice through Scheduled Events.

Spot suits stateless, interruptible work such as batch jobs, CI agents and render farms. In Flexible mode, Spot Priority Mix lets you keep a base of regular VMs and fill the rest with Spot.

Uniform manages identical instances through scale-set APIs, while Flexible exposes every instance as a normal Azure VM resource and gives you more control over how the group is composed.

Neither mode can be switched in place. If you want to move from Uniform to Flexible, plan on building a new scale set and shifting traffic to it.

Autoscale evaluates each rule about once a minute. A rule has a metric, a time aggregation (such as average), a threshold and a look-back window (for example CPU above 70 percent for 10 minutes), plus an action and a cooldown.

• If any scale-out rule is true, autoscale scales out.
• Autoscale scales in only when all scale-in rules are true.
• Before scaling in, it estimates the result. If the smaller fleet would immediately trigger a scale-out, it skips the scale-in to avoid flapping.
• Counts always stay between the profile's minimum and maximum.

az monitor autoscale create -g rg-demo --resource web-vmss \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name web-autoscale --min-count 2 --max-count 10 --count 2

az monitor autoscale rule create -g rg-demo --autoscale-name web-autoscale \
  --condition "Percentage CPU > 70 avg 10m" --scale out 2
az monitor autoscale rule create -g rg-demo --autoscale-name web-autoscale \
  --condition &quot;Percentage CPU < 30 avg 10m&quot; --scale in 1

The cooldown is the time autoscale waits after a scale action before it is allowed to act again. The portal default is 5 minutes.

It exists because a new instance needs time to boot, run extensions, pass health probes and start taking traffic. Until then, metrics still look the same as before, and autoscale could add more instances than needed.

• Too short: over-scaling and flapping between out and in.
• Too long: slow reaction to sudden spikes.

A good starting point is your measured time from instance creation to healthy-in-load-balancer, plus a small buffer. Set cooldown per rule, and use a longer one for scale-in than for scale-out.

Add a profile to the autoscale setting that is tied to a time window. In the portal: scale set, Scaling, Custom autoscale, Add a scale condition.

1. Pick the instance count or rules the profile should use (for example min 6, max 12).
2. Choose Repeat specific days and select the days.
3. Set start and end times and the time zone.
4. Keep a default profile for all other times, for example min 2, max 6.

If profiles overlap, a fixed-date profile beats a recurring one, which beats the default. A wrong time zone is the usual reason a schedule fires at the wrong hour, so always set it explicitly.

An availability set only spreads VMs you create manually across fault and update domains. A scale set also creates, configures and scales those VMs for you from a single model.

For new designs, zone-spread scale sets give stronger resilience than availability sets.

The upgrade policy decides how a model change reaches existing instances. There are three modes.

Rolling upgrades need health signals from either a load balancer probe or the Application Health extension. If health checks are missing, Azure cannot tell whether a batch recovered, so rolling is not suitable without them.

Under a Manual policy, change the model first, then push it to instances with az vmss update-instances.

# 1. change the model
az vmss update -g rg-demo -n web-vmss --set virtualMachineProfile.storageProfile.imageReference.version=1.0.2

# 2. roll it out to every instance (or give specific IDs)
az vmss update-instances -g rg-demo -n web-vmss --instance-ids "*"

Changes like extensions or tags apply in place. Changes to the image replace the instance's OS disk, so anything stored there is lost. Data disks are kept.

To find instances that are behind, list them and check latestModelApplied (Uniform mode). Upgrade a few first, verify them, then continue with the rest.

A fault domain (FD) is a group of hardware that shares a power source and network switch, such as a rack. An update domain (UD) is a group of VMs that can be rebooted together during planned platform maintenance.

Azure spreads instances across FDs so a single rack failure takes out only part of the scale set. UDs ensure maintenance affects only one group at a time, which keeps the rest serving traffic.

In Uniform mode both concepts apply through placement groups. In Flexible mode you set the platformFaultDomainCount to control spreading, and zones give wider isolation than FDs. Using zones is generally preferred where the region supports them.

When you set zones on a scale set (for example 1, 2, 3), Azure places instances in those physically separate datacenters within the region, so a single-zone outage does not take down the whole application.

• Instances are spread across the zones; zone balance keeps counts within one VM of each other (best-effort or strict).
• Pair with a zone-redundant Standard Load Balancer or Application Gateway v2.
• VMs placed in two or more zones qualify for the 99.99 percent VM availability SLA.

Plan capacity for failure: if one of three zones is lost, the remaining two must absorb the load, so autoscale maximums and quota should allow it. Zonal disks stay in the zone of their VM, so replicate data at the application layer or use zone-redundant storage.

Build a gallery, define the image, publish versions, and point the scale set at the image definition or a specific version.

1. Create an Azure Compute Gallery.
2. Add an image definition describing OS type, generalized state, publisher, offer and SKU.
3. Publish image versions (for example 1.0.0, 1.0.1) from a VM or Packer build, and choose target regions and replica count.
4. Reference the image ID in the scale set. Using the definition ID selects the latest version.

az vmss create -g rg-demo -n web-vmss --image &quot;/subscriptions/<sub>/resourceGroups/rg-img/providers/Microsoft.Compute/galleries/myGallery/images/webImage&quot; \
  --admin-username azureuser --generate-ssh-keys

Increase the replica count for large scale-outs, otherwise many instances pulling one replica can be throttled and provisioning slows down.

Azure learns instance health from either a load balancer probe or the Application Health extension. The extension runs inside the VM and probes a local port or path, then reports Healthy, Unhealthy or Unknown to the platform.

{
  "protocol": "http",
  "port": 80,
  "requestPath": "/health"
}

That signal feeds rolling upgrades, automatic instance repairs and automatic OS image upgrades. Without it, those features cannot tell a broken instance from a working one.

Make the health endpoint cheap and honest: return success only when the app can really serve requests (dependencies reachable, warm-up done), and avoid heavy checks that make healthy instances look sick under load.

With automatic instance repairs enabled, the scale set watches the health signal and replaces instances that stay unhealthy, so you do not have to find and fix them manually.

1. An instance reports Unhealthy.
2. Azure waits for the grace period (minimum 10 minutes) so new or updated instances can finish starting.
3. If it is still unhealthy, Azure performs the repair action: Replace (default, delete and recreate), Restart or Reimage.
4. Repairs happen in batches so the whole fleet is not touched at once.

az vmss update -g rg-demo -n web-vmss \
  --enable-automatic-repairs true --automatic-repairs-grace-period 10

Repairs require health monitoring (Application Health extension or load balancer probes). Pick a grace period longer than your slowest startup, or healthy-but-slow instances will be replaced in a loop.

The scale-in policy ranks instances for deletion when capacity drops. There are three options.

With NewestVM or OldestVM, zone balancing still applies first on zonal scale sets. Protected instances are skipped.

OldestVM is handy after a model update because scale-in naturally removes stale instances. NewestVM suits canary tests where the freshest VM is the one you want to discard.

Instance protection stops the scale set from touching a specific instance. There are two switches.

• Protect from scale-in: the instance cannot be deleted by a scale-in operation or autoscale.
• Protect from scale set actions: the instance is also excluded from model updates, reimage and other scale set operations.

A protected instance can still be deleted by an explicit delete on that VM or by deleting the scale set, and protection can be changed through the portal, PowerShell (Update-AzVmssVM) or REST.

A typical use is a worker that is halfway through a long job. Protect it when the job starts, then clear protection when the job ends so normal scaling resumes. Too many protected instances can leave a zonal scale set unbalanced.

Define data disks in the model. Each instance then gets its own new, empty disk of the size you specify.

az vmss create -g rg-demo -n web-vmss --image Ubuntu2204 \
  --data-disk-sizes-gb 128 256

# add a disk to an existing scale set
az vmss disk attach -g rg-demo --vmss-name web-vmss --size-gb 128 --lun 2

The disk is raw. You still need to partition, format and mount it, usually through cloud-init or an extension, and mount by UUID so the path survives reboots.

Maximum disk count depends on the VM size. For data that must be shared or outlive instances, use Azure Files, a database or blob storage rather than per-instance disks.

Choose Application Gateway when you need HTTP-aware routing or a web application firewall in front of the scale set. Choose Load Balancer when you need fast, simple layer 4 distribution.

Both accept a scale set as backend pool. Many designs use Application Gateway for the web tier and an internal Load Balancer for the next tier, or put Azure Front Door in front for global routing.

cloud-init configures Linux instances at first boot using the custom data you place in the scale set model. Every new instance runs it once as it starts.

#cloud-config
package_upgrade: true
packages:
  - nginx
runcmd:
  - echo "Hello from $(hostname)" > /var/www/html/index.html
  - systemctl enable --now nginx

az vmss create -g rg-demo -n web-vmss --image Ubuntu2204 --custom-data cloud-init.txt

Custom data is limited to 64 KB and is not encrypted, so do not put secrets in it. On Windows, use the Custom Script Extension instead. For heavy installs, a prebuilt image starts faster than running cloud-init on every scale-out.

A reimage replaces the instance's OS disk with a fresh copy of the image defined in the current model, then boots it again. The instance keeps its identity and network settings.

• Anything stored on the OS disk is lost (local files, logs, temp changes).
• Attached data disks are kept.
• Extensions and custom data run again after the reboot.
• The instance picks up the latest model, so it also acts as an update.

az vmss reimage -g rg-demo -n web-vmss --instance-id 3

Reimage is a quick way to reset a corrupted instance. It is faster than a delete and recreate, and with ephemeral OS disks it is especially quick since the disk is local.

A managed identity gives instances a Microsoft Entra identity so code can call Azure services without storing passwords or keys. You assign RBAC roles to the identity, and the app asks for a token at runtime.

There are two types. A system-assigned identity is tied to the scale set's lifecycle. A user-assigned identity is a separate resource you can attach to several scale sets, and it can be granted access before the scale set exists. User-assigned is usually the better fit for scale sets.

az vmss identity assign -g rg-demo -n web-vmss --identities <identity-resource-id>

# from inside an instance
curl -H &quot;Metadata: true&quot; \
  &quot;http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net&quot;

Typical uses: reading secrets from Key Vault, writing to Storage, or pulling images from Azure Container Registry.

Each AKS node pool is backed by a virtual machine scale set. When AKS adds or removes nodes, it is changing the capacity of that scale set.

The scale sets live in the cluster's node resource group (usually named MC_...) and are owned by AKS. Editing them directly, for example changing the image or SKU, is unsupported and can be reverted or break upgrades. Make changes through the AKS API, CLI or Terraform.

Node scaling is handled by the AKS cluster autoscaler, which reacts to unschedulable pods and node usage within the pool's min and max. Do not attach Azure Monitor autoscale rules to those scale sets, because the two would fight each other.

Node image upgrades use surge nodes in the same scale set, so quota for the extra nodes must be available.

An ephemeral OS disk keeps the OS on the VM's local storage (cache, temp or NVMe disk) instead of a remote managed disk. It exists only as long as the VM does.

• Lower latency for OS reads and writes, because the disk is local.
• Faster reimage and provisioning during scale-out.
• No OS disk storage cost.

The catch is that OS state is lost on reimage, redeploy or deallocation, and the image must fit in the available local space, which depends on the VM size. They are a great match for stateless web and worker tiers.

az vmss create -g rg-demo -n web-vmss --image Ubuntu2204 \
  --vm-sku Standard_D4s_v5 --ephemeral-os-disk true --os-disk-caching ReadOnly

With overprovisioning, Azure creates more VMs than you requested, keeps the first ones that deploy successfully, and deletes the extras. This raises the success rate of deployments and makes them finish sooner.

The extra VMs are not billed and do not count against your vCPU quota. It is on by default in Uniform mode and does not apply to Flexible.

Turn it off (--disable-overprovision) when the extra short-lived VMs would cause harm. For example, if your startup script registers each VM with an external system, the VMs that get deleted can leave stale registrations behind.

In Uniform mode this is why you may briefly see more instances than your requested capacity right after a create or scale-out.

Combine host metrics, guest metrics and logs in Azure Monitor.

Create alerts for high CPU, unhealthy instances and failed scale operations. VM insights adds a ready-made dashboard and dependency map, and Application Insights covers request-level data.

It depends on the workload. A scale set is better for many identical, stateless instances. Standalone VMs are better for unique servers that each need their own configuration.

The cost is the same for equivalent VMs. If you are unsure, Flexible orchestration blurs the line since it lets you manage instances as normal VMs while still giving you a scaling group.

Flexible is where Microsoft is investing, and it fits most modern designs better than Uniform because instances are normal Azure VMs that happen to be grouped.

• Standard VM tooling: the same APIs, extensions and features you use on single VMs.
• Better spreading: instances are spread across zones and fault domains without placement-group tuning.
• Mixed capacity: Spot Priority Mix lets you combine regular and Spot VMs.
• More flexibility: you can add existing VMs and treat instances individually when needed.

Plan for explicit outbound connectivity (NAT Gateway, load balancer outbound rules or public IPs) rather than relying on default outbound access, and note that Uniform-only behaviors such as overprovisioning do not apply.

Uniform is still supported and fine for existing large stateless fleets, but a greenfield design should start with Flexible.

Automatic OS image upgrade lets the scale set replace each instance's OS disk with the newest published image version, in rolling batches and without you doing anything.

1. A new version of the image is published (Marketplace or Compute Gallery).
2. Azure checks the scale set is healthy, then upgrades a batch (20 percent by default).
3. It waits for the batch to report healthy through the Application Health extension or load balancer probes.
4. It continues with the next batch, or stops if too many instances are unhealthy.

az vmss update -g rg-demo -n web-vmss --set upgradePolicy.automaticOSUpgradePolicy.enableAutomaticOSUpgrade=true

The image reference must use latest, and health monitoring is required. Data disks are preserved but OS disk contents are replaced, so keep instances stateless.

In a rolling upgrade, Azure applies the new model to a small slice of the scale set at a time, checks that slice is healthy, and only then moves on.

flowchart TD
  A["New model applied"] --> B["Pre-check: unhealthy % within limit?"]
  B -->|No| X["Upgrade does not start"]
  B -->|Yes| C["Split instances into batches"]
  C --> D["Upgrade next batch"]
  D --> E{Batch healthy?}
  E -->|Yes| F["Wait pause time"]
  F --> G{More batches?}
  G -->|Yes| D
  G -->|No| H["Upgrade complete"]
  E -->|No, limit exceeded| I["Upgrade stops"]

If a threshold is breached the upgrade stops and the rest stay on the old model. Fix the cause, then check progress with az vmss rolling-upgrade get-latest and restart or cancel with start or cancel. On zonal scale sets, zones are upgraded one after another.

A scale-out event moves from metric to decision to new VM to live traffic.

sequenceDiagram
  participant VM as Instances
  participant AM as Azure Monitor
  participant AS as Autoscale engine
  participant CP as Compute platform
  participant LB as Load balancer
  VM->>AM: Emit metrics (every minute)
  AS->>AM: Read metric over look-back window
  AS->>AS: Rule true, cooldown over, below max?
  AS->>CP: Increase capacity by N
  CP->>VM: Create instances from model
  VM->>VM: Boot, run extensions or cloud-init
  LB->>VM: Health probe
  LB-->>VM: Add to rotation when healthy
  AS->>AS: Start cooldown, log action

1. Metrics are aggregated across instances over the rule's window.
2. If the condition is true, the cooldown has passed and the max count is not reached, autoscale raises capacity.
3. Compute creates the VMs from the model, subject to quota and capacity.
4. Each VM boots and runs its setup, and the health probe or extension marks it healthy.
5. The load balancer starts sending it traffic and the cooldown timer protects against another action too soon.

Delays add up: metric lag, the look-back window, VM boot and warm-up. That is why a custom image and a sensible cooldown matter for spiky traffic.

Work through the usual causes in order, starting with the settings and moving to the data.

1. Setting state: confirm autoscale is enabled and the right profile is active (a schedule or fixed-date profile may override the default).
2. Bounds: check whether the scale set is already at its maximum, or at its minimum for scale-in.
3. Metric source: confirm the rule points at this scale set and the metric is actually flowing. Guest metrics such as memory need an agent.
4. Aggregation: the metric is averaged across instances over the look-back window, so one hot VM may not cross the threshold.
5. Cooldown: a recent action may still be blocking another.
6. Flapping protection: autoscale skips a scale-in if the smaller fleet would immediately breach the scale-out rule.
7. Failures: quota or capacity errors stop the action even when the rule fires.

az monitor autoscale show -g rg-demo -n web-autoscale
az monitor metrics list --resource <vmss-id> --metric &quot;Percentage CPU&quot; --interval PT1M

Then read the Activity Log and the autoscale diagnostic logs (evaluation and scale-action logs), which state why each rule did or did not act.

The scale-out fails. Azure returns a quota error (for example QuotaExceeded or a message about exceeding the approved regional cores), the scale set stays at its current size, and autoscale retries on a later evaluation.

Quotas apply at two levels: total regional vCPUs and per VM family vCPUs, and Spot has its own quota. Hitting either one blocks new instances.

az vm list-usage -l eastus -o table

Prevent surprises by alerting at around 80 percent of quota and by keeping quota above your autoscale maximum, including the extra headroom a zone failure would need. Overprovisioned extras in Uniform mode do not count toward quota.

Use the scale set's terminate notification. It sends a Terminate Scheduled Event to the instance before deletion, so your app can drain connections, finish work and deregister.

"scheduledEventsProfile": {
  "terminateNotificationProfile": {
    "notBeforeTimeout": "PT10M",
    "enable": true
  }
}

The delay can be between 5 and 15 minutes. Inside the VM, poll the metadata service and react when a Terminate event appears:

curl -s -H "Metadata:true" \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

1. Fail the health endpoint so the load balancer stops sending new requests.
2. Finish in-flight requests or jobs and flush buffers.
3. Optionally approve the event early so Azure proceeds right away.

For long jobs that cannot be interrupted, combine this with instance protection. Spot evictions use a similar Preempt event, but with only about 30 seconds of notice.

Zero downtime comes from never taking all healthy capacity out at once and from being able to switch back quickly. There are three common patterns.

Whichever you pick, a few basics must be in place:

• At least two instances, ideally across zones, plus spare capacity during the rollout.
• Reliable health signals (Application Health extension or probes).
• Immutable images from a Compute Gallery so every version is reproducible.
• Graceful drain on shutdown using terminate notifications.
• Backward-compatible database changes so old and new versions can run together.

Rolling is the simplest default. Use blue-green when rollback speed matters more than the extra cost.

Match capacity to demand first, then lower the price of the capacity you do keep.

Also clean up unattached disks and unused scale sets, remember that deallocated VMs still pay for disks, and review outbound data transfer. Use Cost Management with tags to see what each scale set really costs.

Apply security at the network, identity, host and operations layers.

• Network: no public IP per instance, NSGs on the subnet, and a load balancer or Application Gateway with WAF as the only entry point.
• Admin access: Azure Bastion or just-in-time access instead of open RDP or SSH NAT rules; SSH keys instead of passwords.
• Identity: managed identities with least-privilege RBAC; secrets from Key Vault, not custom data or scripts.
• Host: Trusted Launch (secure boot and vTPM), encryption at host or disk encryption.
• Patching: automatic OS image upgrades or guest patching so instances stay current.
• Governance: Azure Policy to enforce settings and Microsoft Defender for Cloud for posture and threat detection.

Because instances are disposable, the best fix for a compromised or drifted VM is to delete it and let the scale set replace it from a clean, signed image.

Declare a Microsoft.Compute/virtualMachineScaleSets resource and set orchestrationMode to 'Flexible'. This minimal example creates three Linux instances in an existing subnet.

param location string = resourceGroup().location
param subnetId string
@secure()
param adminSshKey string

resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2024-07-01' = {
  name: 'web-vmss'
  location: location
  sku: {
    name: 'Standard_D2s_v5'
    capacity: 3
  }
  properties: {
    orchestrationMode: 'Flexible'
    platformFaultDomainCount: 1
    virtualMachineProfile: {
      osProfile: {
        computerNamePrefix: 'web'
        adminUsername: 'azureuser'
        linuxConfiguration: {
          disablePasswordAuthentication: true
          ssh: {
            publicKeys: [
              {
                path: '/home/azureuser/.ssh/authorized_keys'
                keyData: adminSshKey
              }
            ]
          }
        }
      }
      storageProfile: {
        imageReference: {
          publisher: 'Canonical'
          offer: '0001-com-ubuntu-server-jammy'
          sku: '22_04-lts-gen2'
          version: 'latest'
        }
        osDisk: {
          createOption: 'FromImage'
          managedDisk: { storageAccountType: 'Premium_LRS' }
        }
      }
      networkProfile: {
        networkApiVersion: '2020-11-01'
        networkInterfaceConfigurations: [
          {
            name: 'nic'
            properties: {
              primary: true
              ipConfigurations: [
                {
                  name: 'ipconfig'
                  properties: { subnet: { id: subnetId } }
                }
              ]
            }
          }
        ]
      }
    }
  }
}

Flexible mode needs networkApiVersion: '2020-11-01' in the network profile. Add zones: ['1','2','3'] at the resource level to spread across zones, and a load balancer backend pool reference in the IP configuration to receive traffic.

az deployment group what-if -g rg-demo -f vmss.bicep --parameters subnetId=<id> adminSshKey=&quot;$(cat ~/.ssh/id_rsa.pub)&quot;
az deployment group create -g rg-demo -f vmss.bicep --parameters subnetId=<id> adminSshKey=&quot;$(cat ~/.ssh/id_rsa.pub)&quot;

Run what-if first to preview changes without deploying, then create. Keep the file in source control so scale set changes are reviewed like application code.