Azure Virtual Machine Scale Sets - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Opening Y one virtual machine isn't enough. Imagine your website suddenly gets ten times more visitors, but only one virtual machine handles every request page is slow down. People wait and some may leave before your app even responds. Think of an office building with one reception desk. When a crowd arrives, you don't ask one receptionist to work ten times faster. You open more identical desks and share the queue. By the end of this episode, you'll understand how Azure Virtual Machines scale sets do exactly that with virtual machines, traffic routing, and automatic growth. The problem? A single VM has a fixed limit. Welcome to another episode of Microsoft Knowledge Nuggets here on M365 FM.

0:44 I'm Mirko Peters. Before we talk about skillsets, let's picture a normal Azure Virtual Machine. A VM is simply a computer you rent in Microsoft's Cloud. You pick its size, install an operating system, put your app on it, and let people connect for a small internal tool that works fine. But here's the thing that single VM has a hard limit. It only has so much processor power, memory, disk speed, and network capacity. Your app might run perfectly at nine in the morning with twenty people, then struggle at noon when thousands arrive after an email campaign or a product launch. The VM doesn't grow when traffic grows. When demand exceeds what one computer can handle. Requests start waiting in line. Web pages load slowly. API's return errors and checkout pages. Time out. Just when customers want to pay.

1:25 The application hasn't broken, but it can't keep up. You could choose a larger VM from the start that gives one machine more CPU and memory that's vertical scaling or scaling up. It's like replacing a small reception desk with a much larger one and giving the receptionist a faster computer. It helps, but it comes with limits. A VM can only be as large as Azure offers, and changing the size requires a restart that interrupts your app. More importantly, you still depend on one computer. If that computer fails, your app has nowhere to go. Then there's the money problem. If you buy enough power for your busiest hour, that larger VM keeps running during quiet hours too. At two in the morning, it sits almost idle, but you still pay for the reserved capacity. So instead of making one computer bigger, you add more computers running the same app that's horizontal scaling or scaling out one VM becomes two, then four, then more.

2:09 As demand rises, each VM takes a share of the work while the copies already running keep doing their jobs. The best setup is a stateless application. Don't let that term scare you. It just means any copy of your app can handle any visitor's request without needing to remember things locally. A visitor's next web request can reach any VM without breaking their experience. For example, your web servers can store files in shared storage and customer data in a database outside the VM. Then each server can answer the same request. If one copy disappears, the others continue. Managing a few separate VMs by hand soon gets tiring. You need a way to create the same machine repeatedly. Keep the setup consistent and change the number of machines without treating each VM as a separate project.

2:50 What a virtual machine scale set actually is. So today's Knowledge nugget is about virtual machine scale sets often shortened to VMs. What exactly does that mean? It gives us our one shared set of instructions for a group of virtual machines. Instead of building each machine individually, you choose the starting setup just once, and Azure creates the VM instances from that setup as needed. Here's a simple way to think about it. Kind of like a bakery. A bakery has one recipe for its bread, one list of ingredients, and multiple workstations. Each workstation follows the same recipe so customers get the same loaf, no matter which Baker prepares it. A scale set works the same way. The recipe is your VM setup, and each workstation is an instance, meaning one virtual machine inside that group. That shared setup covers quite a few things.

3:31 You pick the operating system image and the size of each VM, including how much CPU and memory it gets. You define networking disks and any software your app needs. Then Azure uses those settings whenever it adds another instance, whether you trigger it manually or an Autoscale rule kicks in. This keeps the group consistent. Without a scale set, you might create three separate VMs and hope they all match. One could have a different disk setting, another might be missing an app update. Someone could change a network rule on only one machine without realizing it until users hit problems with a scale set. You manage the whole group through one shared rulebook. Now, that doesn't mean everything stays frozen forever. You can update the scale set model, change the image or configuration, and control how those changes reach the VM instances, but the starting point stays clear.

4:14 Every new machine should arrive ready to do the same job as the others. You can use Windows or Linux. Azure provides marketplace images which are ready made starting images such as Windows Server or common Linux versions. If your company needs its own approved setup, you can also use a custom image stored in Azure Compute Gallery that lets you prepare an image with your app settings and approved tools already included, then use it as the source for the entire scale set. This matters when a new VM needs to appear quickly. You don't want an empty computer arriving during a busy period while someone manually installs software and customers wait. The new instance needs the right operating system, the right app, and the right connection settings from the Azure creates it. A scale set itself doesn't add a separate service charge. You still pay for what runs underneath it, including the VM, compute, time, storage and network use.

4:58 If the set grows from two VMs to ten, you pay for more VM capacity because more machines are running. When it shrinks again, those running costs drop with the removed instances. The size limit depends on the image type. Scale sets can support up to one thousand VM instances with a standard marketplace image or a custom image from Azure Compute Gallery. If you build the set from a managed image, the limit is six hundred instances. Most beginner setups won't come close to either number, but the scale set can handle far more than a few web servers. So a VM scale set gives Azure the recipe and lets it create the matching workers. But identical workers don't help if incoming requests land on the wrong one or keep landing on one that has stopped working. How requests reach healthy instances. So a scale set creates the workers, but something still needs to direct visitors to them.

5:40 Think of a receptionist at a busy office. Visitors arrive at one front desk, and the receptionist sends each person to a free member of staff. Instead of sending everyone to the same room in Azure, that front desk is usually a load balancer. A load balancer receives incoming traffic and sends each new connection to one of the VM instances in the scale set for basic network traffic, Azure Load Balancer handles this job at the network level, processing traffic like TCP or UDP without looking deeply into the website request itself. For many apps, that's exactly what you need. A request arrives, Azure chooses a healthy VM, and the request continues. Web apps sometimes need more control. Maybe you want traffic for one website address to reach one app while another address reaches a different app.

6:21 Or you might need Azure to handle the secure HTTPs connection before traffic reaches your VMs. Azure Application Gateway fits that type of job because it understands web traffic, including HTTP and HTTPs. So Azure Load Balancer acts more like a traffic director for network connections, while Application Gateway can read the web request and apply website rules. Neither tool should send visitors to a VM that can't answer. That brings us to health probes. A health probe regularly checks whether an instance responds in the expected way. It might test a port or call a simple health page in your application. When an instance fails that check, the load balancer stops sending new traffic to it. Imagine one server has a problem with its app. The VM might still be switched on, but its website could return an error or stop responding without health checks.

7:04 Incoming requests might keep reaching that broken machine with a health probe. Azure identifies the failed response and directs new visitors toward the healthy instances instead. The unhealthy VM doesn't disappear just because traffic stops reaching it. You can still investigate or repair it, but customers avoid it while it can't do its job. That separation matters. A machine can exist without receiving live traffic until it passes its health check again. There's another question what if the problem affects more than one VM at once? Azure runs physical hardware inside regions, and not every VM should sit on the same hardware group or in the same physical location. A fault domain separates instances, so a hardware failure or planned maintenance event is less likely to affect every copy together.

7:45 Availability zones. Take that idea further. An availability zone is a separate physical location inside an Azure region with its own power, cooling and network. When you spread scale, set instances across zones, one zone can have trouble, while instances in another zone continue handling traffic. A scale set alone doesn't protect an app from every data center. Failure. The protection comes from how you place the instances. If every copy sits in one location, they share that location's risk when Azure spreads them across availability zones. The application has copies in separate places. Flexible orchestration mode can also spread VMs across fault domains in a region or within an availability zone. You don't need to memorize every management detail yet. Just remember the goal don't place all your working copies in one basket and hope nothing happens to that basket.

8:29 Traffic routing keeps the door open even when one instance can't serve visitors. The next question is how Azure decides when the building needs more open doors and when it can close a few again. Autoscale adding and removing VM instances so traffic can reach a healthy VM. But how does Azure know when you need more VMs in the first place? That's where Autoscale comes in. It watches the demand on your scale set and changes the number of running instances within boundaries you set, you decide a minimum count. That's the fewest VMs. Azure keeps running even when traffic is low. You also set a maximum a hard ceiling Azure can't go past no matter how high demand climbs. These two numbers protect you in opposite directions. The minimum makes sure your app always has some running capacity. When a request comes in, the maximum stops a bad rule or unexpected traffic spike from spinning up more VMs than your budget allows.

9:14 Between those limits, Azure follows rules. A typical rule looks at average CPU usage across the scale set. You might decide that if CPU stays above a certain level for a set amount of time, as your. Adds more VMs picture for VMs handling a busy website. If they all run near full capacity for several minutes, adding a fifth or sixth gives the workload breathing room. Each machine handles a smaller share of incoming traffic. When the busy period ends, the reverse rule can remove instances. For example, if average CPU stays low for long enough, Azure scales in. It removes unneeded VMs, leaving enough capacity for current traffic without paying for machines that mostly sit idle. CPUs. Only one signal, Azure auto scale can use host based metrics like network traffic, disk reads and writes, and CPU credits for supported VM types.

9:58 You can also pull more detailed data from inside the VM or from the application itself. That means you can scale based on the real pressure your users feel. A web app could react to slow response times. A system that processes messages could react to how many items are waiting in a queue. If work piles up faster than your current VMs can handle it. Adding more workers clears the queue before it becomes a long delay. Not every busy period comes out of nowhere. Many companies know their patterns. Staff signing in at the start of the workday. A monthly report creating a rush, an online shop expecting more visitors before a planned sale. Schedule based auto scale prepares for those moments. Instead of waiting until existing VMs struggle, you tell Azure to raise the instance count ahead of the rush.

10:39 Later, when the busy period ends, another schedule can reduce it again. This matters because new VMs aren't instant. Azure needs time to create the VM, boot the operating system, and start your application. If your app needs a few minutes before it can accept requests, a rule that reacts only after CPU hits its limit might arrive too late. Give your scaling rules enough breathing room for known patterns. Use schedules for changing demand. Use metrics that give early warning, then test because a rule that looks good on paper may react too slowly or add more VMs than the workload actually needs. Azure can also use predictive autoscale. It studies past usage patterns and prepares capacity ahead of expected demand. It doesn't replace your own limits or monitoring, but it helps when traffic follows repeatable patterns. Azure can recognize the language around scaling can get confusing, so keep these two terms straight.

11:23 Scale out means adding VM instances. Scaling means removing VM instances. Neither one changes the size of an existing VM, only the count. New instances start from the same setup you defined. Keeping everything predictable. You can also change the instance. Count yourself. Maybe a planned event starts in an hour and you want extra capacity. Now you can manually increase the scale set count for testing or maintenance. You can lower it as well as long as you understand what that means for your application. Autoscale doesn't turn on automatically just because you created a scale set. your team chooses whether to use manual scaling, scheduled rules, metric rules, or predictive auto scale. Then you monitor the results. Azure gives you the tools. Your settings define what good performance and sensible cost look like.

12:03 A scale set can have up to twenty auto scale rules. That sounds like a lot and it can get messy fast. Start with simple rules that match a real problem, you understand. Watch CPU response time errors and the instance count only add more rules when the data shows you need them. The goal isn't a maze of automation. You want enough VM's to handle, demand no more than you need, and rules that someone else can still read six months from now. Uniform and flexible. Choosing the management model auto scale handles adding and removing machines, but Azure still needs to know how you want to manage the members of the scale set. That choice is called the orchestration mode. You pick it when you create the scale set and you can't change it later. So this isn't a small checkbox to breeze past. It shapes how Azure treats every VM in the group.

12:43 There are two main choices uniform and flexible. Uniform is the classic scale set model. In uniform. Azure treats the whole group as one identical fleet. Every instance uses the same VM size, same image, same network setup, same shared configuration. You think about the scale set first, not about any single VM inside it. This fits a job where every machine should do exactly the same work. Imagine a public website with several web servers behind it. A visitor can reach any server because each one runs the same version of the website and connects to the same shared data services. When Azure adds a new instance, it joins as another matching worker uniform keeps that setup simple. You define the model once, and Azure creates matching instances from it. Updates and capacity changes apply to the scale set as a group.

13:24 Perfect when you need many copies that stay the same. Flexible works differently. With flexible orchestration, Azure gives you more control over individual VMs while still grouping them inside a scale set for availability and scaling, you manage VMs more like normal Azure Virtual machines, not as strict copies with the same limits. That gives you room for workloads where machines don't all need to look identical. For example, you might need to mix VM sizes, use both regular Azure VMs and spot VMs, or keep closer control over certain machines. Flexible orchestration can spread VMs across fault domains in a region or within an availability zone, helping you avoid putting all copies on the same underlying hardware. So which one should you choose for a beginner? Ask yourself a simple question. Are you building a repeatable pool of machines that all perform the same job?

14:06 If the answer is yes, a scale set often fits very well. Uniform can be a natural choice for a web front end, an API layer, or a group of workers that process the same type of background task. Every instance starts from the same approved image and joins the same pool. If one server needs special software, a custom disk layout, or a one off role, no other machine shares. A standalone VM often makes more sense. You don't need a scale set just because you have virtual machines. A scale set helps when copies need to grow, shrink, and run the same workload. It won't turn every server into a candidate for automatic scaling. Stateless workloads usually fit this model best. A web front end can receive a request on any available VM, and API can run on several matching instances. Batch workers pull work from a queue, process it, and move on to the next item.

14:49 Backend compute jobs, add workers when there's more waiting work, and remove them when the queue clears. Those workloads can handle a VM coming and going. Stateful workloads need more thought. If an application stores important data only on the local disk of a VM, then removing that VM during scaling can remove access to that data. A database, a file server, or an app that depends on one machine. Remembering everything needs a clear plan for data replication and recovery before you put it in a scale set. Flexible orchestration can support workloads that need more individual VM control, including stateful applications, but it doesn't erase the need to plan where the data lives. The scale set handles the computers. Your application still needs to handle the information those computers use. You may already use scale sets without noticing it as your Kubernetes service, often called AKS, uses virtual machine scale sets behind the scenes for its worker nodes.

15:37 Azure Service Fabric does, too. In both cases, the larger platform needs a pool of machines it can manage and grow when more computing power is needed. Same basic idea a scale set gives Azure a managed group of compute workers, while the service on top decides what work each worker should do. Once you've chosen the right management model, another question follows quickly how do you update the app or repair failed instances without taking the whole group out of service? Keeping the fleet healthy during failures and updates. So how do you keep your fleet of virtual machines healthy when things break or need updating? Let's break it down. You have a scale set with multiple VM instances, but those instances still run operating systems, applications and updates and things can fail. That's just reality.

16:17 Here's where Azure helps you configure health checks that tell Azure when an instance stops working properly. If the health signal shows a VM is unhealthy, Azure replaces it with a fresh one based on the scale sets configuration. The idea is simple instead of leaving a broken machine in the group until someone notices, Azure removes the failed copy and spins up a replacement that starts from the approved setup. But here's the catch that only works if your health signal actually means something useful. A VM being switched on doesn't prove the application works. You need a health check that tests whether the service can actually respond the way you expect. For a website, that might mean checking a health page for an API. It might mean checking a simple endpoint that confirms the app can accept requests. Treat health checks as a real test, not just a box to tick off.

16:59 Now, updates bring a similar problem. Maybe you need a new application version, a security update, or a fresh image. If you replace every VM at the exact same moment, you remove all your available capacity. That defeats the whole purpose of having multiple instances rolling upgrades. Avoid that. Azure updates one portion of the scale set, while the remaining instances keep handling traffic. Once the updated group looks healthy, Azure moves to the next portion. The exact approach depends on your configuration, but the practical idea stays the same. Change the group in steps. Not all at once. Your image and configuration need to stay consistent too. When Azure creates a replacement VM or adds capacity during a spike, it has to start with the correct application version and settings. If half the instances run one version and half run another, customers may see different results depending on which VM handles their request.

17:43 Keep the VM build repeatable, use a known image and a reliable setup process. Then test that a new instance can start. Join the network, pass its health check, and do its work without someone logging in to fix it by hand. Failures don't only happen inside a VM. An availability zone gives you a separate physical location within an Azure region when you place instances across zones. A problem in one location doesn't take down every app server. Other instances in another zone can keep going as long as the rest of your design supports that path. Placement reduces shared risk, but it doesn't replace monitoring. You still need to watch the CPU level, application response times, error rates, and the number of active instances after a scaling event. Check whether the new VMs became healthy and whether response times improved.

18:24 After an update, check whether errors rose and whether the updated instances behave like the older ones did. A scale set can add capacity, but it can't fix a slow application. If every VM spends time waiting on a bad database query or a blocked external service, adding more copies may just create more pressure on the same problem. Find the bottleneck before treating scale out as the answer. The same warning applies to stored data. Don't place a database or file server in a scale set simply because you want more availability. Those workloads need a deliberate plan for where data lives, how it stays consistent, and what happens when an instance is removed or replaced. Azure can recreate a VM, but it can't guess which local files your application needed to keep. When to use a scale set.

19:06 So when should you actually choose a virtual machine scale set? Let's break it down. Use one when you need several similar virtual machines to handle work that changes over time. The machines need to run the same kind of app, start from a repeatable setup, and safely come and go as demand shifts. A public website is a common example. Visitors arrive at different times and the number can change fast. A scale set lets you run more web servers when demand rises, then scale back when it drops. An API can fit two. Maybe your mobile app sends requests to an API all day, but usage jumps during lunch breaks or after a new feature launches. If any healthy instance can answer the request, a scale set gives you a pool of matching API servers. Cue workers are another good fit. Imagine an app receives orders, files or messages and places them in a queue.

19:48 When the queue grows, more worker VMs can pick up the work. When the queue becomes quiet, you don't need the same number of workers running repeatable batch jobs follow the same pattern. You might need to process a large group of files overnight, run reports at the end of a month, or prepare data for another system. More VM instances can process more work at the same time, as long as each worker can take a separate piece of work safely. But a single VM still has its place. Choose one when the server needs its own special setup, when it runs a small and steady workload, or when you need to manage that machine separately from every other machine. A development server, a small internal app, or a server with a unique role may not need a scale set. Now, before choosing, ask yourself these four questions. Can a request or work item reach any instance in the group?

20:30 Does the amount of work rise and fall enough to justify adding and removing VMs? Can every new instance start from the same standard image and setup, and can the important data live somewhere other than the local disk of one VM? If you can answer yes to those, You probably have a good skill set workload. Your application also needs shared services around the VM instances. Keep business data in a database built for that job. Put shared files in storage that every instance can reach when needed. Store app settings and secrets somewhere the new VM can retrieve them safely. That way, an instance can disappear without taking the only copy of something important with it. Start small and use real data. Set a minimum count that keeps the app available. Set a maximum count that fits your budget and expected load. Watch what happens during normal traffic, busy periods, and planned tests.

21:12 Then adjust the rules based on what your app actually needs. A virtual machine scale set turns separate computers into a managed pool where Azure can add, remove and replace the matching VM instances without asking you to rebuild the group by hand. Conclusion. Next knowledge nugget. So what's the big idea with VM scale sets? Therefore, when you have a bunch of identical app servers and need to handle fluctuating demand without managing each VM individually, that saves you time and headaches. Subscribe on your favorite podcast platform, then check out the Azure Load Balancer episode. You'll see how one public address sends traffic to the right healthy server.