Azure Virtual Machine Scale Sets let you manage a group of load-balanced VMs as a single service boundary. The important design questions are when to scale, how to health-check instances, how updates are rolled out, and what dependencies could become the real bottleneck.
2026 context: the high-level concepts still hold, but for new builds I would compare VM Scale Sets against Azure App Service, Azure Container Apps, AKS, and Azure Functions before choosing IaaS. If you do choose IaaS, use flexible orchestration mode, health probes, autoscale rules, availability zones where supported, and image/deployment automation rather than hand-maintained pets.
The design fork
The main question is whether you need virtual machines at all:
- Choose PaaS/serverless if the platform can run the workload and you mostly care about the application.
- Choose containers if you need packaging consistency and horizontal scale without managing individual VM lifecycles.
- Choose VM Scale Sets when you really need VM-level control, custom agents, legacy software, or special networking/host assumptions.
Scaling a VM up and scaling a service out are different moves. Resizing a VM can help a single overloaded machine, but it usually creates downtime and does not improve fault tolerance. Adding instances behind a load balancer improves capacity and resilience, but only if the application is stateless or handles shared state properly.
Availability Sets
- If we place two or more instances into the same ‘availability set’ Microsoft provide a 99.95 availability SLA. (The single instance SLA is 99.9).
- An ‘availability set’ is a logical container that ensures your VM instances reside on different hardware hosts, on separate racks in the same Azure data center.
- This arrangement would cover you for maintenance & local failures.
- This arrangement on its own won’t help with regional/data center failures (since your set of machines are in the same data center).
Availability Zones
- This is when we have different data centers in the same region.
- The data centers are connected by high speed redundant links.
- They are not available in every region.
Azure Traffic manager
- We could connect two regions via traffic manager and load balance between regions.
- Azure Traffic Manager operates at the DNS layer
- Directs incoming DNS requests based on the routing method of choice. (Choices are: Priority, performance, geographic, weighted round-robin, subnet, and multi-value and you can combine them)
- Example: sending requests to the closest endpoints, improving the responsiveness of an application
Managed Disks Storage
- Slight side track, but when designing IaaS remember this is the way to go, don’t use the classic storage account for this.
Resize VM’s for scale?
- You can resize Azure VM’s on the fly, either in the console or via PowerShell.
- They will go down while you do though, in the lab this was only about a minute but its hard to say if machines doing real things might take longer.
Scale Sets
- Keep in mind, IaaS isn’t the best for horizontal scale. PaaS is designed to solve the scale issues for you and is the way to go if possible/practical for the use case.
- But, “Scale sets” are what you want if you need to handle scale.
- You’ll want a “Virtual Machine Scale Set template”
- Configure the scale options, configure a load balancer and off you go.
- The Azure marketing pitches it like “Virtual Machine Scale Sets are elastic and designed to support your scale-out workloads, including stateless web front ends, container orchestration, and microservices clusters. Azure Kubernetes Service and Azure Service Fabric run on Virtual Machine Scale Sets”
For a respectable production design, also decide how new instances get configured. The usual options are a custom image, cloud-init/custom script extensions, Desired State Configuration, Ansible, or another configuration-management pipeline. Autoscale is only safe if a newly created instance can become healthy without someone logging in to nurse it.
Deployment Automation
- It is all about ARM (Azure Resource Manager) templates.
- I’ll do a separate post to summarize ARM templates because there is too much content but important to know a few things here…
- When you deploy a template, Resource Manager converts the template into the individual REST API operations needed to achieve the thing you’ve declared in your template.
- Visual Studio makes this easy. It has “validate” and “deploy” options built right in and produces a skeleton template for the most useful scenarios. Today, I would also consider Bicep or Terraform for readability and reviewability. Start with the current Azure Resource Manager template documentation, Bicep documentation, or Azure quickstart templates.
- Small tip: Be careful of PowerShell windows that have popped up behind visual studio when testing deployments. (Your deployment might be waiting for input from you).
- Also, for what it is worth, to test the declarative nature of ARM templates I deleted the NIC from a machine configured via an ARM template, then reran the template. The NIC was put back in place, and it was still the same machine (it didn’t burn the old and make a new one) because I left a ping running inside it to confirm. I did find the machine couldn’t reach the Internet anymore though, even after getting its NIC back. I used “redeploy” to move it to another host and it had Internet access again.
Quickstart Templates
- Cool as. There are a lot of these and they’ll get you up and running in minutes.
- Quickstart templates link
Policy Restrictions
- If you’re worried that all this scale, redundancy and automation might land you in hot water with machines deployed in a prohibited region consider an Azure policy that describes the regions your are allowed in, attach it to the subscription and you’ll be protected from accidents of this nature.
Custom VHD Templates
- Last thing, sort of related to scale. You can work on your own VHD images. Just build them in Hyper-V locally, generalize them and use AzCopy/Storage Manager to get them into your account. You can store them on blob storage in a storage account.
