A scale set is a manager for a group of identical virtual machines. Once you understand that one sentence, everything else in this guide becomes easy.

Start with a virtual machine

A virtual machine, or VM, is a computer that exists as software. Microsoft owns enormous buildings full of real servers, called data centers. Azure cuts one real server into several virtual slices, and each slice behaves like a normal computer. It has its own operating system, its own memory, its own disk, and its own network address.

You rent a slice for as long as you need it. When you are done, you give it back and stop paying for the compute. That is the basic idea behind renting computers in the cloud instead of buying them.

Now add the words “scale set”

A Virtual Machine Scale Set is an Azure resource that creates and manages a whole group of virtual machines for you. You give it one description, and it builds the group from that description. Every machine in the group is called an instance. All instances start from the same disk image, use the same machine size, and run the same software.

Because the instances are identical, the group can be resized easily. Need five instances? Azure creates five. Traffic doubles? Ask for ten, or let Azure decide automatically. Traffic drops at midnight? Go back to three. You manage the group as one thing instead of logging in to each machine by hand.

What a scale set gives you

• Many identical VMs from one recipe. No more building servers by hand.
• Manual or automatic resizing. You can change the count yourself or write rules that do it for you.
• Spreading across failure boundaries. Instances can sit in different zones and fault domains so one problem does not take everything down.
• Safe updates. You can roll a new software version across the group in small batches.
• Self-healing. A broken instance can be detected and replaced automatically.
• Friendly with load balancers. Traffic can be shared across all healthy instances.

What a scale set does not do

A scale set does not write your application. It does not magically turn a program that stores important data on its own disk into a program that is safe to copy. It is also not a container orchestrator like Kubernetes. It manages virtual machines, not containers, although Azure Kubernetes Service itself uses scale sets underneath to run its worker machines.

Before cloud scaling tools, running a busy application meant guessing, waiting, and hoping. Understanding the old pain makes the new tool easier to appreciate.

The guessing game of fixed servers

In the old world, a company bought servers months before it needed them. Someone had to guess next year’s traffic. If the guess was too low, the website crashed on its busiest day. If the guess was too high, expensive machines sat idle for years. Nobody could guess perfectly, so everybody wasted money or lost customers.

The cloud fixed part of this because you can rent machines in minutes. But renting machines one by one still leaves a big problem. Somebody has to notice the traffic spike, click the buttons, install the software, and add the new machine to the load balancer. By then the spike may already be over.

The “snowflake server” problem

When people build servers by hand, each one ends up slightly different. One has a newer library. Another has a forgotten setting. A third has a secret fix that only one engineer remembers. These one-of-a-kind machines are called snowflake servers because no two are alike. They are hard to repair and scary to replace.

Scale sets push you the other way. Every instance is built from the same image and the same settings, so any instance can be thrown away and rebuilt in minutes. That habit is the foundation of reliable cloud systems.

The single point of failure problem

One server means one thing that can break. Hardware fails, software crashes, and data centers occasionally lose power or cooling. If your whole application lives on one machine, any of those events means downtime. A group of instances spread across separate failure boundaries keeps the lights on even when one part goes dark.

Where the pressure shows up

Every technology has its own words. Learn these twelve and the Azure documentation will stop feeling like a foreign language.

Each term below is explained the same way: what it is, why it exists, and a simple picture to help you remember it.

Model versus instance

Azure keeps two ideas apart. The model is what the group is supposed to look like. Each instance is what actually exists. After you change the model, older instances may no longer match it. Azure can tell you which instances are on the latest model and which are behind. You then decide how and when to bring them up to date.

A scale set never works alone. It sits in the middle of a small city of Azure services that bring traffic in, store data, hold secrets, and watch everything.

flowchart TD
    U["Users on the Internet"] --> LB["Load Balancer or Application Gateway"]
    LB --> I1["Instance 1 in Zone 1"]
    LB --> I2["Instance 2 in Zone 2"]
    LB --> I3["Instance 3 in Zone 3"]
    subgraph VMSS["Virtual Machine Scale Set"]
        I1
        I2
        I3
    end
    GAL["Azure Compute Gallery image version"] -->|"image source"| VMSS
    MON["Azure Monitor metrics"] -->|"CPU and traffic numbers"| AS["Autoscale rules"]
    AS -->|"add or remove instances"| VMSS
    VMSS -->|"logs and metrics"| MON
    VMSS --> DB["Database and storage"]
    KV["Key Vault"] -.->|"secrets through managed identity"| VMSS
    

Read the diagram from the top. Users reach a front door, which is a load balancer or an application gateway. The front door shares requests across the instances. The instances sit in different zones so that one building problem does not stop everything. Behind the instances sit the databases and storage that keep long-lived data. Around the group, Azure Monitor watches numbers, autoscale rules react to those numbers, an image gallery supplies the starting disk, and Key Vault hands out secrets safely.

The compute layer

This is the scale set and its instances. Each instance has an operating system disk, a virtual network card, and the extensions you configured. The compute layer is where your code actually runs.

The network layer

Instances live inside a virtual network, often shortened to VNet, which is your private neighborhood in Azure. Inside it, subnets split the neighborhood into streets. Network security groups act like guards at the street entrances, allowing or blocking traffic by rule. A load balancer or application gateway spreads incoming requests over healthy instances.

The storage layer

Every instance needs an OS disk. You can use a normal managed disk that lives in Azure Storage, or an ephemeral OS disk that lives on the host machine’s local storage. Ephemeral disks are faster and free of separate disk charges, but their contents vanish when the instance is deleted or moved. They suit stateless instances well. If an instance needs to keep data, you attach data disks or, better, store the data in a database or storage account outside the scale set.

The image source

Instances start from either a ready-made platform image, like Ubuntu or Windows Server from Azure’s marketplace, or your own custom image kept in an Azure Compute Gallery. The gallery stores numbered image versions and can copy them to many regions, which makes consistent rollouts possible.

Identity and secrets

Instances can be given a managed identity, which is a name tag Azure itself maintains. With it, your code can prove who it is to services like Key Vault or Storage without any password stored on the machine.

The watching layer

Azure Monitor collects numbers such as CPU use and network traffic. Log Analytics stores logs for searching. Alerts tell people or systems when something looks wrong. Autoscale reads these numbers to decide whether to add or remove instances.

When you create a scale set, Azure asks you to pick a mode. This choice shapes almost everything you can do later, so it deserves its own chapter.

Uniform orchestration

Uniform mode is the original design. Every instance is built from the same scale set model. The scale set owns the instances tightly, and you mostly manage the group as a whole rather than touching individual machines. It is simple and predictable, and it works well for large groups of truly identical, stateless workers.

Flexible orchestration

Flexible mode is the newer design, and Microsoft recommends it for new deployments. Instances in Flexible mode look and behave much more like ordinary Azure VMs. You can add and remove individual machines, mix different VM sizes, spread them across zones and fault domains with more control, and blend regular and Spot machines in one group. It brings the best of both worlds: scale set automation with VM-level freedom.

How to choose

For a new project, start with Flexible unless a feature you need is only available in Uniform. Check the current Azure documentation for the latest feature comparison, because Microsoft keeps closing the gaps. If you have an existing Uniform scale set that works well, there is no emergency to move it, but plan the move when you next redesign the system.

Behind the friendly portal sits a steady loop that compares what you asked for with what exists, and fixes any difference.

Desired state: the thermostat idea

A home thermostat does not heat the room once and walk away. It keeps checking the temperature. If the room is colder than the number you set, it turns the heater on. If it is warmer, it turns it off. A scale set works the same way. You declare a desired state, for example “six healthy instances built from image version 4”. Azure keeps comparing the real world to that wish and takes action whenever they differ.

What happens when you create or grow a scale set

Why this loop matters

Because the platform keeps comparing wish and reality, a deleted or crashed instance can be noticed and rebuilt when automatic repair is turned on. You are no longer the one watching the machines. The platform is.

Autoscaling is the feature most people come to scale sets for. It turns “I hope we have enough servers” into a set of clear rules.

Autoscale belongs to Azure Monitor

The scale set itself only knows how to hold a number of instances. The brain that changes the number is Azure Monitor autoscale. You attach an autoscale setting to the scale set, and it keeps reading numbers and adjusting capacity within limits you choose.

Three styles of scaling

The parts of a rule

A metric rule is a plain sentence: “If the average of this number, over this much time, is above or below this value, then change the count by this amount, and then wait this long before acting again.” Each part has a job.

• Metric: the number being watched, such as average CPU, memory pressure, network traffic, or a queue length.
• Time window: how many minutes of data to average. A longer window ignores short spikes.
• Threshold: the line that triggers the rule.
• Action: add or remove a fixed number or a percentage of instances.
• Cooldown: a rest period after a scaling action, so new instances have time to start and affect the numbers before the next decision.
• Limits: a minimum, a maximum, and a default count. The minimum protects availability, and the maximum protects your wallet.

Scaling on what really matters

CPU is an easy number, but it is not always the right one. A worker that reads jobs from a queue should scale on how many jobs are waiting. A web server may care more about requests per second or response time. Autoscale can use custom numbers from tools like Application Insights, or queue lengths from services like Azure Storage queues and Service Bus. Pick the number that best predicts user pain.

The flapping trap

Imagine rules that add an instance at 70 percent CPU and remove one at 60 percent. Add one instance, and CPU drops to 58 percent. The rule removes it, CPU jumps to 72, and the cycle repeats forever. This back-and-forth is called flapping. Azure tries to predict the result of a scale-in action and skips it if it would immediately trigger a scale-out, but you should still leave a wide gap between your two thresholds.

Choosing who goes first when shrinking

When the count must go down, Azure has to choose which instances to delete. The scale-in policy controls this. The default policy balances instances across zones and fault domains first, then removes the instance with the highest ID. Other policies remove the newest or the oldest instance first. You can also protect specific instances from being chosen, which is useful when one machine is busy finishing a long task.

Two journeys matter here: the journey of one user request through the system, and the journey of one instance from birth to deletion.

The journey of a scale-out

Let us follow a busy afternoon. Traffic rises, CPU climbs, and the scale set grows from four instances to six. The picture below shows who talks to whom.

sequenceDiagram
    participant M as Azure Monitor
    participant A as Autoscale Engine
    participant C as Compute Control Plane
    participant H as Host Servers
    participant L as Load Balancer
    M->>A: Average CPU is 82 percent
    A->>A: Check the rule and the cooldown timer
    A->>C: Raise capacity from 4 to 6
    C->>H: Create two instances from the model
    H-->>C: Instances are running
    C->>L: Add new instances to the backend pool
    L->>L: Health probe passes on both
    L-->>M: Traffic now shared by six instances
    

Notice that the load balancer waits for the health probe before sending real users to a new instance. This small pause is why a half-started machine does not serve errors to customers. It is also why a slow-starting application can make scale-out feel late: the new instance exists, but it is not ready to help yet.

The journey of one user request

A user types your address into a browser. A name system turns the name into the address of your front door. The load balancer or application gateway receives the request and picks one healthy instance, using a simple rule such as spreading requests evenly. The instance runs your code, perhaps asks a database or cache for data, builds an answer, and sends it back along the same path. The user never knows which instance answered, and that is exactly the point: any instance can answer any request, so instances can come and go freely.

The life of one instance

flowchart LR
    P["Capacity requested"] --> CR["Creating"] --> ST["Starting and running extensions"] --> RU["Running and healthy"]
    RU --> UP["Updating or reimaging"] --> RU
    RU --> UH["Unhealthy"] --> RE["Repair by restart or replace"] --> RU
    RU --> SI["Chosen for scale in"] --> DE["Deleting"] --> GO["Gone"]
    RU --> EV["Spot eviction notice"] --> DE
    

An instance is born when capacity is requested. It spends a short time creating and starting, and then it works for as long as it stays healthy. During its working life it may be updated, repaired, or even replaced. Eventually it is chosen for removal during a scale-in, or evicted because it was a Spot machine and Azure needed the space back, and then it is deleted. Good designs treat this whole story as normal weather rather than an emergency.

Getting a warning before the end

Azure can send an instance a short warning that something is about to happen. The warning is delivered through the Instance Metadata Service, a tiny web address that only the instance itself can reach. For scale-in, you can turn on a terminate notification, which delays the actual deletion by a few minutes so your application can finish current work, say goodbye to the load balancer, and save any last details. Spot instances receive a similar warning, but it is much shorter, around thirty seconds.

The goal of a scale set is not only to handle more traffic. It is also to keep serving users when parts of the system fail.

Failure comes in layers

Things break at different sizes. A single program can crash. A single physical server can fail. A rack of servers can lose its power connection. A whole data center building can lose cooling. An entire region can have a rare, large outage. Good design asks, “What is the biggest failure I want to survive?” and then spreads instances so that failure cannot take them all at once.

Fault domains and availability zones

A fault domain groups machines that share the same power source and network switch inside a data center. An availability zone is a whole separate building with independent power, cooling, and network. Zones are farther apart than fault domains, so they protect against bigger problems. In regions that offer zones, spreading a scale set across all three is the strongest protection inside one region.

Spreading choices in Flexible mode

In Flexible mode you choose how strictly Azure spreads instances. Max spreading puts instances across as many fault domains as possible, giving the best protection. Static fixed spreading uses a fixed number of fault domains, which can suit workloads that need predictable grouping. For most web workloads, the zone spread with max spreading is a sensible starting point.

Automatic instance repairs

If you provide health information, Azure can watch each instance and fix the unhealthy ones without waking anyone up. Health can come from the load balancer’s probe or from the Application Health extension, a small helper that checks a web address or port inside the instance. When an instance stays unhealthy for longer than a grace period, Azure takes a repair action, such as restarting it, rebuilding it from the image, or replacing it entirely.

The grace period matters. A new instance needs time to boot and warm up. If the grace period is too short, Azure may keep killing instances that were simply still starting, causing a loop of endless replacement. Choose a period longer than your slowest normal startup.

What availability promise does Azure make?

Microsoft publishes a service level agreement for virtual machines. In general, running two or more instances spread across two or more availability zones gives the highest promised availability figure, higher than running in a single zone. The exact numbers can change, so always read the current Azure service level agreement page before quoting a number in a contract or design document.

Beyond one region

A scale set cannot span regions, so a regional failure plan uses separate scale sets with a global entry point such as Azure Front Door or Azure Traffic Manager. These services check which regions are healthy and send users only to those. Data is the hard part: the database must also be copied across regions, using the replication features of the database service you choose.

Releasing a new version of your software to fifty machines without breaking the site is its own craft. Scale sets give you built-in tools for it.

Two kinds of change

Some changes affect the model, such as a new image version, a new VM size, or a new extension setting. Other changes are inside the instance, such as an operating system patch. For model changes, existing instances do not update by themselves unless your upgrade policy says so. The upgrade policy is the rule that controls this.

How a rolling upgrade works

Extra safety with surge

Some rolling upgrade settings let Azure create new instances first and remove old ones afterward. This is called surging. Capacity never drops below the target during the upgrade, which is helpful when every instance is already working hard.

Automatic operating system image upgrades

When you use a supported platform image, Azure can automatically move your instances to a newer version of that image when Microsoft publishes security fixes. It uses the same rolling method and relies on health signals to stay safe. This takes a lot of patching work off your plate, but you should test new image versions in a staging group first when your application is sensitive.

Your own images and the Azure Compute Gallery

Many teams bake their software into a custom image so instances start ready to work. Building the image once and starting many instances from it is called the immutable image approach: you never fix a running instance, you build a new image and replace the old ones. The Azure Compute Gallery stores numbered versions, replicates them to the regions where you need them, and lets you share them across teams. You can also keep several versions side by side, which makes going back to a previous version easy.

Protecting special instances

Instance protection lets you mark an instance so it is skipped during scale-in, or during scale set actions like upgrades. Use it sparingly, for example while an instance is finishing a long job. Remember to remove the protection afterward, or the instance will quietly fall behind.

Instances are useless if users cannot reach them, and dangerous if everyone can. Networking decides who gets in, who gets out, and how work is shared.

Choosing a front door

Health probes decide who gets traffic

A load balancer regularly asks each instance a simple question, such as “Does your web page answer on port 80?” Instances that answer correctly stay in rotation. Instances that fail are skipped until they recover. A good probe checks something meaningful, such as a small page that touches the application’s key dependencies, not just whether the machine is switched on.

Reaching individual instances

Sometimes you need to reach one particular instance for troubleshooting. Inbound NAT rules on a load balancer can map a port to a single instance. A better modern habit is to avoid direct logins altogether and use a controlled service such as Azure Bastion, which gives secure access through the browser without exposing the instance to the open internet.

Going out to the internet

Instances often need to reach the outside world to download updates or call other services. Azure has been moving away from giving new networks an invisible default way out to the internet, because hidden paths are hard to control. You should plan outbound access on purpose, using a NAT Gateway, load balancer outbound rules, or a firewall. A NAT Gateway gives all instances in a subnet a stable, shared public address, which is helpful when partners need to allow your address on their own lists.

Speed features

• Accelerated networking lets the network card talk more directly to the physical hardware, lowering delay and lifting throughput. It needs a supported VM size and operating system.
• Proximity placement groups ask Azure to place instances physically close together, which reduces delay between them for chatty workloads, with the trade-off of less spreading.
• Private endpoints let instances reach services such as storage and databases over private addresses instead of the public internet.

Subnets and security rules

Place scale set instances in their own subnet so you can attach clear rules to it. A network security group on that subnet might allow web traffic only from the load balancer, allow management traffic only from the Bastion subnet, and deny everything else. Think of it as writing a short guest list for a private party.

A fleet of identical machines is a big advantage for defenders, because one fix reaches all of them. It is also a risk, because one mistake is copied everywhere.

Build in layers

No single control is perfect, so good security stacks several. If one layer fails, the next one still stands. Think of a castle with a moat, a wall, guards, and a locked inner room.

Patching at fleet scale

Old software is the easiest way in for attackers. With scale sets you have two healthy patching styles. In the immutable style, you build a fresh image with the latest fixes and roll it out, which keeps every instance identical. In the in-place style, a service such as Azure Update Manager applies patches to running instances on a schedule. The immutable style is cleaner and easier to reason about. The in-place style may fit when instances are long-lived by necessity.

Watch for risky configuration

Microsoft Defender for Cloud checks your scale sets and tells you about weak spots, such as open management ports, missing patches, or unencrypted disks. Azure Policy can enforce rules automatically, for example “all scale sets must use zones” or “no public IP addresses on instances”, so mistakes are stopped before they reach production.

Scale sets make it easy to spend exactly what you need. They also make it easy to spend a lot very quickly if nobody is watching.

What you actually pay for

The scale set service itself is free. You pay for the pieces it creates: the virtual machines by the time they run, the disks, the load balancer, public addresses, outbound data transfer, and monitoring data you store. Understanding this list helps you find where savings hide.

Spot instances in a scale set

Azure sometimes has machines nobody is using. It rents those spare machines at a big discount as Spot instances, with one condition: Azure may take them back when it needs the space, or when the market price passes the maximum you set. You choose what happens on eviction, either deleting the instance or stopping it so the disk is kept.

In Flexible mode you can mix regular and Spot instances using a Spot priority mix. For example, you can keep a base number of regular instances for safety and fill the rest with Spot instances for savings. If Spot instances disappear, the regular base keeps serving users, and the scale set tries to refill capacity.

Cost safety rails

Set a maximum instance count so a runaway rule or an attack cannot create a thousand machines. Add budgets and cost alerts in Azure Cost Management. Tag each scale set with the team and project that own it, so the monthly bill can be understood instead of guessed.

You cannot fix what you cannot see. With dozens of short-lived instances, good visibility is not a luxury, it is the only way to know what is happening.

Three kinds of signals

What to collect

Azure collects basic host-level metrics automatically, such as CPU percentage, disk activity, and network traffic, as seen from outside the instance. For deeper numbers from inside the operating system, like memory use and process counts, install the Azure Monitor Agent, which replaced the older monitoring agents. It sends guest metrics and logs to Azure Monitor and Log Analytics according to rules you define.

Four golden signals for a scale set

Site reliability engineers often watch four things: latency (how long answers take), traffic (how many requests arrive), errors (how many requests fail), and saturation (how full the machines are). If you chart only these four across your scale set, you will catch most real problems early.

Logs that survive the instance

Instances disappear, and their local disks disappear with them. If logs stay only on the instance, the evidence is gone exactly when you need it most. Ship logs off the machine continuously, to Log Analytics or another central store, so you can still investigate an instance that was deleted an hour ago. Also enable boot diagnostics, which keeps startup screenshots and serial output for instances that fail to start.

Alerts that help instead of annoy

An alert should tell a person to do something. Alert on symptoms users feel, like high error rates, and on conditions that need action, like the scale set sitting at its maximum for an hour. Too many noisy alerts teach people to ignore them. Send alerts to the right people through action groups, and link each alert to a short runbook explaining what to check first.

Scale sets are powerful, but they are not always the right tool. Knowing the neighbors helps you choose with confidence.

A simple way to decide

Ask what you want to stop worrying about. If the answer is “everything below my code”, look at App Service, Container Apps, or Functions. If you want to avoid the machine but run containers, look at Container Apps or Kubernetes. If you truly need to control the operating system, install special software, use a specific machine size, or lift an existing application with little change, a scale set is the right fit.

Scale sets are underneath many Azure services

Even if you choose a higher-level service, scale sets often work behind the scenes. Azure Kubernetes Service worker nodes run on scale sets. Azure Service Fabric uses them for its node types. Azure Pipelines can use scale set agents to create build machines on demand. Learning how scale sets behave helps you troubleshoot all of these.

Patterns are proven recipes. Anti-patterns are recipes that look tasty and then make everyone sick.

Patterns worth copying

Anti-patterns to avoid

Most scale set problems come from a small set of repeating mistakes. Learn them once and save yourself many late nights.

Best practices checklist

• Start with Flexible orchestration for new projects unless a specific feature needs Uniform.
• Design for statelessness. Keep sessions, files, and records outside the instance.
• Use zones. Spread across zones wherever the region offers them.
• Automate image builds. Build images in a pipeline, version them in the Azure Compute Gallery, and keep previous versions for rollback.
• Give instances health signals and connect them to the load balancer, repairs, and rolling upgrades.
• Pick scaling metrics that mirror user pain, such as queue length or request rate, not only CPU.
• Set minimum and maximum counts that protect both availability and budget.
• Keep instances private and use managed identities, Key Vault, and a well-guarded front door.
• Ship logs and metrics off the instance from the first day.
• Describe everything as code, using templates or infrastructure-as-code tools, so environments can be rebuilt and reviewed like software.
• Test scaling before the big day. Run a load test that pushes the group through scale-out and scale-in, and watch what breaks.

Mistakes beginners make

Some of the best examples of scale sets are inside Azure itself. Others are patterns you will see in almost every company that runs on the cloud.

Scale sets behind Azure services

Common company scenarios

The following examples describe typical situations rather than specific companies, because the exact designs of real businesses are private. They show how teams usually combine scale sets with other Azure services.

Cloud capacity feels endless, but it has edges. Knowing where the edges are keeps your scale-out from failing at the worst moment.

Quota: your permission slip

Every Azure subscription has quotas, which are limits on how many virtual CPU cores you may use in each region. There are limits for the region as a whole and for each VM family, such as general purpose or memory optimized. Quotas exist to protect you from accidental runaway spending and to help Microsoft plan its hardware.

If your scale set tries to grow beyond your quota, the extra instances are simply not created, and the operation records an error. The fix is to ask for a higher quota before you need it. Many requests are approved quickly, but large ones can take time, so never leave this for the morning of a big launch.

Capacity: the hardware must really exist

Quota gives you permission, but a region must also have free machines of the exact size you ask for. Popular sizes in busy regions can occasionally run short, especially during large events. When this happens you may see an allocation failure. Several habits reduce the risk:

• Allow several VM sizes through Flexible orchestration, so the scale set has more than one way to meet your capacity target.
• Spread across zones, because a shortage in one zone may not exist in another.
• Use capacity reservations for critical workloads. A reservation sets aside machines for you in a zone, and you pay for them whether you use them or not, much like booking a hotel room in advance for a big festival.
• Avoid very rare or very new sizes for core services unless you have confirmed their supply in your regions.
• Keep a second region ready for the most important systems.

Other limits worth knowing

Plan your address space

A surprising number of scale-out failures happen because the subnet ran out of IP addresses. Each instance needs at least one address, and Azure keeps a few addresses in every subnet for its own use. If you expect two hundred instances and plan rolling upgrades with surge, give the subnet room for far more than two hundred. It is cheap to choose a larger subnet at the start and painful to change it later.

Test the edges on purpose

Do not wait for real customers to discover your limits. In a test environment, push the scale set to its planned maximum with a load test. Watch how long scale-out takes, whether any instance fails to start, how the database copes, and how quickly the group shrinks again. A single rehearsal teaches more than a month of reading documentation.

Short, direct answers to the questions beginners ask most.

You started with a pizza shop that could not decide how many ovens to buy. You now know how Azure solves that problem for computers.

A Virtual Machine Scale Set is a free management layer that builds and runs a group of identical virtual machines from one recipe. It lets that group grow, shrink, spread across failure boundaries, update safely, and heal itself. Around it sit load balancers, images, identities, vaults, and monitoring, and together they make an application that is cheaper than a fixed fleet and tougher than a single machine.