A scale set lets you create, manage and scale a group of virtual machines as one unit instead of as many separate servers.

The Simple Definition

A virtual machine is a software-defined computer running in Azure. Running one is simple. Running fifty identical ones is a headache: you must create each, keep their settings the same, spread them across failure boundaries, add more when traffic rises and remove them when it falls. A Virtual Machine Scale Set, often shortened to VMSS, solves this by letting you describe the machine once and then ask Azure for any number of copies. The group can grow and shrink automatically in response to load or a schedule, and Azure helps spread the copies across separate hardware so that a single failure does not take everything down.

It exists because many workloads need the control of full virtual machines, such as custom software, special operating system settings, unusual drivers or licensed products, but still want cloud elasticity. It is used for web tiers behind load balancers, batch and compute grids, game servers, build agents, back-end services and the node pools of container platforms.

What You Manage and What Azure Manages

Azure manages the physical hardware, the hypervisor, the placement of instances and the automation that creates and deletes them. You manage everything inside each virtual machine: the operating system configuration, patching, installed software, security settings, application deployment and monitoring. This is Infrastructure as a Service, so you have maximum control and maximum responsibility. A scale set removes the repetitive work of managing many machines but does not remove the work of managing the machine itself.

Pets and Cattle

A popular saying in operations separates pets from cattle. A pet server has a name, is hand-crafted and is nursed back to health when it is sick. A cattle server is one of many identical machines, numbered not named, and replaced rather than repaired. Scale sets are built for cattle. The healthiest designs treat every instance as disposable and keep important data outside it.

Twelve terms appear in almost every conversation about scale sets. Learn them once and the rest falls into place.

The Model and the Instances Can Drift

The model is the intention, and each instance is the reality. When you change the model, existing instances do not necessarily change at once. Depending on your upgrade approach, they may stay on the old version until you update, refresh or replace them. This gap is called model drift, and it is a common source of confusion: a fleet that looks uniform in the portal can contain machines built from three different versions of the blueprint.

Fault Domains Versus Zones

Both protect against failure but at different scales. A fault domain protects against a rack or equipment failure inside one datacenter. An availability zone protects against the loss of a whole datacenter. A resilient design usually spreads across zones, and Azure then spreads further across fault domains within each zone where the mode and settings allow it.

A scale set is a control layer sitting on top of ordinary virtual machines and ordinary network resources.

The Big Picture

At the top is the Azure Resource Manager, the control plane that accepts your requests. Below it the scale set resource holds the model and the capacity setting. The platform’s compute fabric creates virtual machines on physical hosts according to that model. Each instance receives a network interface in your virtual network subnet and attaches managed disks. In front of the instances there is typically a load balancer or an application gateway that spreads incoming traffic. Beside them sit monitoring services and autoscale, which watch metrics and change the capacity.

flowchart TD
  USER["Operator or Pipeline"] --> ARM["Azure Resource Manager"]
  ARM --> VMSS["Scale Set Model and Capacity"]
  AUTO["Autoscale Engine"] -->|"changes capacity"| VMSS
  MON["Azure Monitor Metrics"] --> AUTO
  VMSS --> FAB["Compute Fabric"]
  FAB --> I1["Instance in Zone 1"]
  FAB --> I2["Instance in Zone 2"]
  FAB --> I3["Instance in Zone 3"]
  I1 --> NIC["Network Interfaces in Subnet"]
  I2 --> NIC
  I3 --> NIC
  LB["Load Balancer or Application Gateway"] --> NIC
  I1 --> DSK["Managed Disks"]
  I2 --> DSK
  I3 --> DSK
  I1 -.-> MON
  I2 -.-> MON
  I3 -.-> MON
        

The Control Plane and the Data Plane

The control plane is how you manage resources: creating the set, changing capacity or updating the model. The data plane is how users reach your application through the load balancer and into the instances. They fail independently. A problem with the management service does not stop traffic already flowing, and a traffic flood does not stop you from changing capacity, although a flood may make you wish you had done so sooner.

The Resources Around the Set

Following one scale-out from trigger to first customer request shows why scaling takes minutes, not seconds.

sequenceDiagram
  participant M as Metrics
  participant A as Autoscale
  participant R as Resource Manager
  participant F as Compute Fabric
  participant V as New Instance
  participant H as Health Probe
  participant L as Load Balancer
  M->>A: CPU stays above threshold
  A->>A: Evaluate rules and cooldown
  A->>R: Raise capacity by one
  R->>F: Create instance from model
  F->>V: Allocate host and boot image
  V->>V: Run extensions and start app
  H->>V: Probe application
  V-->>H: Healthy
  H->>L: Add instance to rotation
  L->>V: First customer request
        

Why Scale-Out Is Slow Compared With Platforms Like Functions

Adding a whole virtual machine means allocating hardware, copying or attaching a disk, booting an operating system, running configuration and starting your application. Even when each step is fast, the total commonly takes minutes. That is perfectly fine for gradual growth, but it cannot rescue you from a spike that arrives in ten seconds. The answer is to scale early, keep headroom, schedule capacity ahead of known events and absorb bursts with queues and caches.

Boot Time Is a Design Choice

You control most of the boot time. An instance that boots from a fully prepared custom image, with the application already installed, can be ready in a short time. An instance that boots from a plain image and then downloads packages, compiles code and configures itself at startup can take far longer, and is more likely to fail if a download site is slow or unavailable. This is why mature teams build images in advance rather than installing at boot.

The single most important choice you make when creating a scale set is its orchestration mode, because it cannot be changed afterward.

Two Styles of Management

Uniform orchestration is the original style. The scale set owns identical instances created from one model, and you manage them through scale set operations. Flexible orchestration is the newer style. It gives you the benefits of scale sets, scale and spread, while letting you work with each instance much like an ordinary virtual machine, and even mix different kinds of machines. Microsoft describes Flexible orchestration as the recommended mode for new scale sets, and has also moved the default mode of command-line and scripting creation tools from Uniform to Flexible.

Migration Is a Rebuild, Not a Switch

Because the mode is fixed at creation, there is no automatic upgrade from Uniform to Flexible and no automated tool to move machines from an availability set. Microsoft recommends a blue-green approach: create a new Flexible scale set beside the old one, send traffic to it gradually, and then shrink or remove the old one. Several template details change too, such as removing NAT pools and overprovisioning settings, and making the fault domain count explicit. Treat the move as a project with testing and a rollback plan.

flowchart LR
  OLD["Existing Uniform Scale Set"] --> LB["Shared Load Balancer or Gateway"]
  NEW["New Flexible Scale Set"] --> LB
  LB --> USERS["Users"]
  TEST["Validate new set"] --> NEW
  SHIFT["Shift traffic in steps"] --> LB
  OLD -.-> RET["Scale down and retire after stable period"]
        

A Simple Decision Guide

What an instance looks like when it first wakes up decides how fast, how reliably and how consistently your fleet scales.

Three Ways to Prepare an Instance

Azure Compute Gallery and Image Versions

An Azure Compute Gallery stores your custom images as numbered versions. A scale set can point at a specific version or at the latest one. You can replicate versions to several regions so that scale-out in each region is fast and local, and share them across subscriptions and teams. Pinning a specific version makes deployments predictable, while using the latest version keeps fleets current but can surprise you with an untested change. Most teams pin versions in production and promote them through test environments first.

Extensions and Configuration at Boot

Extensions run inside the instance to perform tasks like installing monitoring agents, running configuration scripts or reporting health. Keep them few and fast. Each extension adds boot time, and a failing extension can leave an instance half-ready. Order matters when extensions depend on each other. Store secrets in a vault and fetch them with a managed identity instead of embedding them in scripts or settings that anyone with read access can see.

Disks: Persistent, Data and Ephemeral

The operating system disk can be a regular managed disk, which survives deallocation, or an ephemeral disk placed on local storage of the host. Ephemeral disks are fast, cost nothing extra for storage and are quick to reset, which suits stateless instances, but their contents vanish if the instance is moved or reimaged. Data disks attached to instances give persistent storage, but a scale set is not designed for individually precious disks. Anything truly important belongs in a database, a storage account or a file service outside the instances.

Configuration Management Without Hand Work

Every instance should configure itself the same way without human help. Two common tools do this at boot: a cloud initialization script on Linux images and a custom script extension on both operating systems. Keep these scripts short, repeatable and safe to run twice. A script that fails halfway can leave an instance partly configured, so write it to check each step and exit with a clear error that the platform reports. Store the scripts in a controlled location with version history, and treat changes to them with the same review as application code.

Configuration that differs between environments, such as which database to talk to or which feature flags are on, should come from a central source at boot, such as an app configuration service or a vault, rather than being baked into images. This keeps one image usable in test and production, and changes the environment by changing settings rather than rebuilding.

Autoscale is the engine of elasticity. It is simple to switch on and surprisingly easy to misconfigure.

How Autoscale Decides

Autoscale is a service of Azure Monitor. It attaches to a scale set and holds a profile with a minimum, a maximum and a default number of instances, plus rules. Metric-based rules look at measurements such as average CPU, memory, network, disk activity, queue length or custom application metrics. Schedule-based rules change capacity at set times, for example more instances during business hours. Predictive autoscale can also study the history of a CPU-based pattern and add capacity slightly ahead of the expected rise, which helps with the slow boot time of virtual machines.

Anatomy of a Good Rule Pair

Every scale-out rule needs a matching scale-in rule, with enough distance between the two thresholds. Imagine scale-out at seventy percent CPU and scale-in at thirty percent. In between, nothing happens, which is exactly what you want. If both thresholds sit too close together, the set oscillates: it adds an instance, load per instance drops, the scale-in rule fires, load rises again and the cycle repeats. This is called flapping. Autoscale has built-in protection that estimates what the metric would be after a scale-in and skips the action if it would immediately trigger a scale-out, but good thresholds are still your first defense.

Windows of Time and Cooldown

A rule looks at a metric over a time window, such as the average across ten minutes. A short window reacts faster but is jumpy. A long window is steady but slow. After a scale action, a cooldown period pauses further changes so the new instance has time to boot and take load. Set the cooldown to at least as long as your typical time from creation to useful traffic. Otherwise autoscale keeps adding instances while earlier ones are still starting, and you overshoot.

Choosing What to Measure

Scale-in Policy: Who Leaves First

When the set shrinks, a scale-in policy chooses which instances to remove. The default behavior balances instances across zones and fault domains first, so that shrinking does not leave one zone empty, and then removes within the chosen group. Other policies remove the newest or the oldest instances first. Removing the oldest can help retire stale instances that drifted from the model, while removing the newest can protect warmed-up caches. Combine your choice with graceful shutdown so in-flight work finishes, and use termination notifications so instances can drain connections before they disappear.

A Worked Autoscale Example

Imagine a web fleet where one instance comfortably serves about a thousand requests per minute at sixty percent CPU, and a new instance takes six minutes to become healthy. A sensible design might set a minimum of three instances across three zones, a maximum of thirty, scale out by two instances when average CPU exceeds sixty-five percent over ten minutes, and scale in by one instance when average CPU stays below thirty-five percent over twenty minutes, with a cooldown of ten minutes after each action. Add a schedule that raises the minimum to six instances shortly before the weekday morning peak and lowers it in the evening. Predictive scaling, if the load pattern is regular, can add capacity slightly before the schedule would.

The logic behind the numbers matters more than the numbers. Scale out faster than you scale in, because being short of capacity hurts users while having extra capacity only costs a little. Make the cooldown longer than the boot time. Keep a gap between the thresholds. Cap the maximum at what the database and the subnet can support. Then test the whole design with a load test, because rules that look wise on paper often behave differently against a real application.

Resilience comes from where instances sit, not just how many there are.

Spreading Choices

In a regional deployment without zones, instances can be spread across fault domains inside one datacenter. In a zonal deployment, instances are spread across availability zones, typically one, two or three of them. With maximum spreading, Azure places each instance in a separate fault domain as far as it can. Flexible orchestration lets you also pin an instance to a particular zone or fault domain when you need a specific layout, such as keeping a primary and a standby apart.

flowchart TD
  LB["Zone-redundant Load Balancer"] --> Z1["Zone 1"]
  LB --> Z2["Zone 2"]
  LB --> Z3["Zone 3"]
  Z1 --> A1["Instance A"]
  Z1 --> A2["Instance B"]
  Z2 --> B1["Instance C"]
  Z2 --> B2["Instance D"]
  Z3 --> C1["Instance E"]
  Z3 --> C2["Instance F"]
  A1 -.-> LOSS["If Zone 1 fails, four of six instances keep serving"]
        

What the Service Level Targets Mean

Azure states availability targets for scale sets depending on spread: about 99.95 percent when instances are spread across fault domains, and 99.99 percent when they are spread across multiple zones, under the documented conditions. These numbers describe the platform’s part of the story. Your real availability also depends on your application, your database, your load balancer configuration and your operational mistakes. A perfectly spread fleet running a buggy release is still down.

Capacity and Allocation Failures

Scale-out can fail when Azure does not have enough free machines of the requested size in the requested zone at that moment. This is called an allocation failure. It is rare for common sizes but more likely for scarce families, such as large GPU or high-memory machines, during regional shortages. You can reduce the risk by keeping your size choice flexible, using several sizes in one Flexible set with max spreading, spreading across zones, reserving capacity ahead of time with a capacity reservation for critical workloads, and by scaling earlier instead of at the last moment.

A fleet is only as good as its ability to notice sick machines and update healthy ones without hurting users.

Application Health Signals

Knowing that a virtual machine is powered on is not the same as knowing that your application works. The Application Health Extension runs inside each instance and reports whether the application answers a health check you define. In Flexible orchestration you install and configure it on each instance. Uniform instances can alternatively rely on a load balancer health probe. A good health endpoint checks the things that truly matter, such as the ability to reach the database and process a request, without becoming so deep that a small dependency hiccup marks the entire fleet unhealthy.

Automatic Instance Repairs

With repairs enabled, the platform watches the health signal. If an instance stays unhealthy beyond a grace period you configure, the platform replaces or restarts it according to your repair action. The grace period matters: it must be longer than normal boot and startup time, or healthy instances still starting up will be repaired in a loop. Repairs are not a substitute for fixing the cause. If instances keep failing, find out why instead of letting the fleet churn quietly.

Updating the Fleet

There are two things to update: the model, meaning the image and settings, and the operating system inside running instances. Uniform orchestration offers upgrade policies. Manual leaves instances alone until you apply the change. Automatic updates all at once, which is risky. Rolling updates in batches, checking health between batches, and pausing if too many instances become unhealthy. Uniform also supports automatic operating system image upgrades that follow new marketplace image releases. Flexible orchestration does not support automatic operating system image upgrades and relies on in-guest patching and on replacing instances or whole scale sets with a newer image. Documentation on upgrade features for Flexible is evolving, so check the current pages for the exact options you plan to use.

Instance Protection During Scale-in

Sometimes a particular instance is doing important work, such as finishing a long job, when autoscale decides to remove it. Uniform scale sets can mark instances as protected from scale-in. Flexible scale sets use other tools, such as resource locks, to prevent deletion. The best long-term answer is to design jobs so any instance can disappear, by checkpointing work and using queues that put unfinished jobs back.

Batching and Pausing During a Rolling Update

A rolling update replaces instances in batches. You choose how many instances, or what percentage of the fleet, may be updated at once, and how many may be unhealthy before the roll pauses. A small batch is safer but slower, and a large batch is faster but risks reducing capacity below what traffic needs. A common approach is to start with about twenty percent per batch and a strict limit on unhealthy instances, then adjust based on how long your application takes to warm up. Add a pause between batches so health signals have time to appear. If a bad image causes failures, the roll stops after the first batch, leaving most of the fleet on the working version.

Remember that capacity dips during updates. If your fleet runs at seventy percent utilization and you take out twenty percent of instances for an update, the remainder runs hot. Schedule updates outside peak times, or add temporary surge instances so users do not feel the update.

Networking is where Flexible and Uniform differ most, and where many first deployments go wrong.

Inbound Traffic

Most scale sets sit behind a load balancer or an application gateway. A Standard load balancer works at the network level, spreading connections by address and port, and can be zone-redundant. An application gateway works at the web level, understanding paths, host names and certificates, and can include a web application firewall. Both use health probes to avoid sending traffic to unhealthy instances. Individual instances normally have no public addresses at all. Administrators reach them through a bastion service, a private connection or a jump host instead of exposing remote login ports to the internet.

Outbound Traffic and the Flexible Difference

Uniform scale sets receive default outbound internet access. Flexible scale sets do not, in line with Azure’s move toward explicit outbound design. If instances need to reach package repositories, partner APIs or Azure public services, you must provide a deliberate path: a NAT gateway attached to the subnet, a route through a firewall or network virtual appliance, outbound rules on a Standard load balancer, or a public address on each interface. A NAT gateway is the cleanest choice for most fleets, because it provides a stable outbound address that partners can allow and scales its connection capacity well.

flowchart TD
  NET["Internet Users"] --> AG["Application Gateway with WAF"]
  AG --> SUB["Scale Set Subnet"]
  SUB --> INST["Instances without public addresses"]
  INST --> NAT["NAT Gateway with fixed outbound address"]
  NAT --> EXT["External APIs and update sources"]
  INST --> PE["Private Endpoints"]
  PE --> DB["Database and Storage with public access off"]
  ADMIN["Administrator"] --> BAS["Bastion Service"]
  BAS --> INST
        

Performance Features

Accelerated networking lets traffic bypass parts of the virtualization layer, lowering latency and CPU use for supported sizes. Proximity placement groups keep instances physically close for very low latency between them, which helps tightly coupled workloads but can reduce flexibility and increase the chance of allocation failure. Check that your chosen machine size and operating system support these features before building on them.

Subnet Sizing and Address Planning

Every instance consumes an address in its subnet, and Azure reserves a few addresses in every subnet. Size the subnet for your maximum instance count, plus room for rolling upgrades that temporarily run extra instances and for any parallel scale sets during migrations. Avoid address ranges that overlap with on-premises networks, because overlaps make future connections painful or impossible.

Health Probes at the Load Balancer

A load balancer sends test requests to each instance and removes any that fail from rotation. The probe is a separate thing from the platform health extension that drives repairs, and they can disagree. A probe that checks only that a port is open may pass while the application behind it is broken. A probe that calls a rich health endpoint may remove every instance at once if a shared dependency slows down. Design the endpoint so that it reflects the instance’s own readiness to serve traffic, with a light check of critical dependencies, and give it a sensible interval and failure threshold so brief hiccups do not remove healthy instances.

Also plan for connection draining. When an instance leaves rotation, existing connections should be allowed to finish for a short period, so users are not cut off mid-request. Combine this with the graceful shutdown behavior of your application for the smoothest scale-in and updates.

Spare capacity can cut compute cost dramatically, if your workload can tolerate being interrupted.

What Spot Instances Are

Azure always keeps some machines unused so it can serve sudden demand. Spot instances rent that spare capacity at a large discount, with one condition: Azure can take the machines back when it needs the room or when the market price exceeds your maximum. Spot instances come with no availability guarantee and are not covered by the usual availability targets. They are an excellent match for work that is flexible, interruptible and restartable, such as batch processing, rendering, build agents, test environments and stateless background workers.

Eviction and What You Can Do About It

When Azure needs the capacity back, it evicts an instance. You choose what happens: the instance can be deallocated, keeping its disks so it may be restarted later when capacity returns, or deleted completely. Instances receive a short advance warning, around thirty seconds, through a scheduled events service available from inside the machine. Your software can listen for it and use those seconds to save state, finish a task or hand work back to a queue. Design interruptible workers around this: small units of work, results saved often and unfinished work returned automatically.

Mixing Spot and On-demand

Flexible orchestration can mix Spot and regular instances in one scale set, using a priority mix. For example, you can keep a base of on-demand instances that always run, and scale additional capacity as Spot for cost savings. This gives a stable minimum with cheap elasticity on top. Uniform orchestration cannot mix them in one set, which is one practical reason to choose Flexible for cost-sensitive fleets.

Because you own everything inside the virtual machine, security is largely your responsibility. Layers protect you when one fails.

Layer 1: Network Exposure

Give instances no public addresses unless there is a clear reason. Put a load balancer or gateway in front, use network security groups to allow only required traffic and keep remote login ports closed to the internet. Use a bastion service, a private link or just-in-time access for administration. Use private endpoints for databases and storage so traffic never crosses the public internet.

Layer 2: Identity Without Passwords

Use managed identities so instances can call Azure services without stored credentials. In Flexible orchestration, user-assigned identities are the supported choice. Grant the narrowest role at the narrowest scope: an instance that only reads one storage container should not hold rights over the whole subscription. Retrieve secrets at runtime from a key vault using that identity, never from scripts, image files or plain settings.

Layer 3: The Machine Itself

Harden the image: remove unneeded software, disable unused services, apply security baselines and keep everything patched. Use trusted launch features where available to protect against boot-level tampering. Encrypt disks, and consider confidential options for highly sensitive data. Because you rebuild images regularly, new security fixes reach the fleet through new image versions, which is far more reliable than patching machines one by one.

Layer 4: Patching and Vulnerability Management

Patching is a continuing duty, not a one-time task. Flexible scale sets rely on in-guest patching tools and on regularly replacing instances with a fresh image, since automatic operating system image upgrades are not available there. Track the age of the oldest running image, scan for vulnerabilities and set a rule such as no instance older than thirty days. Combine this with rolling replacement so patching does not mean downtime.

Governance Guardrails

Use Azure Policy to require approved images, block public addresses on interfaces, enforce encryption and require tags. Use role-based access control so only a few people can change models, capacity limits or network settings. Because a scale set can create hundreds of machines, permissions over its capacity are also permissions over your bill.

Disk Encryption and Trusted Launch

Data on disks is encrypted at rest by default with platform-managed keys. For stricter requirements you can bring your own keys held in a key vault, or add encryption at the host level, which also covers temporary disks and caches. Trusted launch adds secure boot and a virtual trusted platform module, helping detect tampering with the boot process, and works best when your images support it. Decide which level you need early, because some of these choices are easier to set when creating the model than to retrofit across a running fleet.

Reliability is the art of staying useful when something breaks, because something always breaks.

Layers of Protection

Multi-Region Designs

For regional outages or global audiences, run scale sets in two or more regions, with images replicated to each region through the compute gallery, and place a global router such as Azure Front Door or Traffic Manager in front. You can run all regions actively or keep one on standby at low capacity, scaling up when needed. Data replication is the hard part. Your database or storage must replicate across regions, or the second region has nothing meaningful to serve.

flowchart TD
  U["Global Users"] --> FD["Front Door or Traffic Manager"]
  FD --> R1["Region A Scale Set"]
  FD --> R2["Region B Scale Set"]
  GAL["Compute Gallery image replicated to both regions"] -.-> R1
  GAL -.-> R2
  R1 --> D1["Primary Database"]
  R2 --> D2["Replica Database"]
  D1 -. replication .-> D2
  R1 --> M["Central Monitoring Workspace"]
  R2 --> M
        

Backup and Site Recovery

Flexible scale sets support Azure Backup and Site Recovery, which Uniform sets do not. If your instances hold state, such as data disks that matter, backup gives you recovery points. Yet the preferred design is a stateless fleet with state in managed services, so a lost instance is simply replaced. Whatever you choose, rehearse recovery. A backup that has never been restored is only a hope.

Recovery Targets

Two numbers guide every recovery plan. The recovery time objective is how long you can be down. The recovery point objective is how much recent data you can afford to lose. Choose the cheapest design that meets those numbers, not the fanciest one. A fleet for an internal tool may accept hours of downtime, while a payment path may accept seconds.

Graceful Termination

Instances disappear for many reasons: scale-in, repairs, upgrades, host maintenance and Spot eviction. Each time, your software should drain gracefully. Stop accepting new connections, finish work in flight, flush buffers and close cleanly. The platform can send scheduled events ahead of some terminations, giving your code a few moments to prepare. Combine this with load balancer connection draining so users are not cut off mid-request.

A Simple Recovery Runbook

Write down, in plain steps, what to do when a zone or region fails. Who decides to fail over? How is traffic shifted? Which scale set in the other region must be scaled up, and how long does that take? Where are the latest image versions? Which database replica becomes primary, and how are applications told? A runbook that has been rehearsed twice is worth more than an elegant diagram nobody has tested. Review it after every significant change to the architecture, because plans rot quickly when networks, images and identities change.

You cannot fix what you cannot see. Fleets multiply every blind spot by the number of instances.

Three Kinds of Signals

Host Metrics and Guest Metrics

The platform reports host-level metrics, such as CPU percentage, without anything installed. Deeper insight, such as memory use, disk space, process details and operating system logs, requires a monitoring agent inside each instance. Include the agent in your image or configuration, point it at a central workspace and make sure every new instance reports from its first minutes. Instances created by autoscale are the ones most likely to be missing an agent if you forgot to automate it.

Watching the Fleet, Not Just the Machine

Alert Design

Diagnosing a Boot That Never Finishes

When a new instance never becomes healthy, work through the layers: did the instance get created, did it boot, did the extensions finish, did the application start and does the health endpoint answer? Boot diagnostics, serial console access and extension status messages usually point to the stuck layer. For Flexible scale sets, use the standard virtual machine tools for these checks, because the scale set specific batch tools do not apply.

Building a Log Pipeline That Survives Scale-in

When an instance is removed, whatever logs it held on its own disk are lost. Ship logs off the machine continuously, so the last minutes before a failure are never trapped on a disk that is about to be deleted. Configure the monitoring agent to send operating system and application logs to a central workspace, tag each record with the scale set name, instance name, zone and image version, and keep retention long enough for incident reviews. With these tags, you can answer questions such as whether errors cluster in one zone or on one image version in seconds rather than hours.

Patterns are proven shapes. Anti-patterns are the shapes that keep causing incidents.

Helpful Patterns

Anti-patterns to Avoid

The cloud bill is an architecture diagram written in money. Reading it well saves real budget.

How a Fleet Is Billed

The scale set feature itself is free. You pay for what it creates: the virtual machines for every second or hour they exist, the disks attached to them, the load balancer or gateway, the NAT gateway, public addresses, data leaving the region, monitoring data and any licenses bundled with the images. A stopped but not deallocated machine still costs compute. A deallocated machine stops compute charges but its disks continue to cost money. Because the bill grows with instance count and time, the main levers are how many instances run, how big they are and how long they stay.

Levers to Spend Less

The Break-even Question: Fleet or Platform Service?

A scale set gives full control but includes all the operating system work. For a standard web application, a platform service may need less labor, and labor is also a cost. Compare the full cost, including patching, image building, monitoring setup and incident time, not just the hourly price of virtual machines. A fleet makes the most economic sense when you truly need machine-level control, special software or licensing, or when scale and utilization are high enough that the control is worth the effort.

Quotas and Governance

Every subscription has core quotas per region and per machine family. A scale set that tries to exceed them fails to scale, usually at the worst moment. Check quotas before launches and request increases early. For governance, use Azure Policy to require tags, approved images and approved sizes, and to block public addresses. Use budgets and cost alerts so a runaway autoscale loop becomes a notification, not a month-end shock.

Licensing and Special Workloads

Some fleets run licensed software, and licensing can silently become the largest cost. Check whether the license is per machine, per core or per user, and whether it can follow instances that appear and disappear automatically. Azure offers ways to bring existing operating system and database licenses to virtual machines, which can reduce hourly rates, but they require careful tracking so that you stay compliant as the fleet scales. For graphics, machine learning or high-memory workloads, remember that specialized machine families have extra constraints, tighter capacity and sometimes limits on how they can be updated, so test scale-out for those sizes early instead of assuming they behave like general purpose ones.

Patterns become clear when you see how different organizations shape the same service for different goals.

Industry Scenarios

Scale Sets Versus Other Compute Choices

Moving From Availability Sets or Uniform Sets

Many teams arrive with virtual machines in availability sets or with Uniform scale sets. There is no automatic converter. A calm migration follows a pattern. Assess the current estate: images, extensions, networking, identity, outbound needs and state on disks. Build the Flexible target with templates, including explicit outbound connectivity and health extension setup. Test with realistic traffic. Shift users in steps through a shared load balancer or gateway, watch metrics and keep the old fleet ready for an instant return. Retire the old resources only after a full business cycle without problems.

A compact checklist for design reviews.

A Maturity Ladder

Testing Before You Trust

Test the behaviors that only show up under stress. Force a scale-out and measure the time from decision to healthy traffic. Delete an instance and watch repairs. Make the health endpoint fail and watch the grace period. Simulate a zone loss in a test environment. Publish a deliberately broken image to a staging fleet and see whether the rolling update stops itself. These rehearsals turn assumptions about the fleet into known facts.

Short, practical answers to questions that come up again and again.

No. The orchestration mode is fixed when the scale set is created. Migrate by building a new Flexible set and shifting traffic, using a blue-green approach.

No. The scale set itself is free. You pay for the virtual machines, disks, networking, monitoring and other resources it uses.

Flexible scale sets provide no default outbound access. Add explicit outbound connectivity, such as a NAT gateway, a firewall route or load balancer outbound rules.

Each new instance must be allocated, booted, configured and health-checked. Shorten it with prepared images and minimal startup work, and scale earlier or on a schedule.

Up to 1,000 virtual machines with fault domain guarantees. Check the current limits page, because some constraints apply to special machine families, and your regional quota may be lower.

The thresholds are probably too close, the window too short or the cooldown shorter than boot time. Widen the gap, lengthen the window and match cooldown to your real startup time.

Yes in Flexible orchestration, which supports a mix of Spot and on-demand. Uniform orchestration uses one or the other.

No. Use in-guest patching and replace instances or whole scale sets with newer images on a regular schedule.

AKS and Service Fabric are listed as not supported on Flexible orchestration, so those platforms use Uniform sets. Check current documentation before planning.

If an instance stays unhealthy past the grace period, the platform performs your chosen repair action, such as replacing it. It depends on a reliable health signal, so configure the health extension or probe carefully.

Bake slow-changing software into the image for speed and reliability. Keep boot-time configuration small and quick, such as environment names and secret retrieval.

A Flexible set with at least two instances across zones, a pinned golden image, health checks and repairs, schedule and metric autoscale with a maximum, explicit outbound access and alerts on instance count. Add Spot or commitments for the parts that suit them.

Virtual Machine Scale Sets turn one machine blueprint into an elastic, spread-out fleet. Behind that simple idea sit choices that matter: the orchestration mode, which cannot be changed later and where Flexible is now the recommended path; the image strategy that decides boot speed and consistency; autoscale rules that need wide gaps and honest cooldowns; zone and fault domain spreading that creates real resilience; health checks that make repairs and updates safe; and networking that, in Flexible sets, demands explicit outbound design. Security remains yours inside every instance, so hardened images, identities without passwords and rolling replacement are essential. Above all, treat every instance as disposable, keep state elsewhere, observe the whole fleet and choose the lowest level of control that meets your real needs.