Start with the outage you must survive
An availability set reduces correlated failure for two or more VMs placed inside one datacenter. Azure distributes those VMs across fault domains and update domains. It is useful when the region does not support availability zones or when a workload needs close VM-to-VM proximity and accepts datacenter-level risk.
An availability zone is a physically separated group of datacenters inside an Azure region. A single zonal VM is pinned to one zone and is not resilient if that zone fails. Zone resiliency comes from deploying multiple application instances across two or more zones and designing traffic, data and dependencies to continue in a healthy zone.
A Virtual Machine Scale Set is an orchestration resource for a group of VM instances. It can maintain consistent configuration, distribute instances across fault domains or zones, integrate with load balancing, apply upgrade policies and scale capacity. VMSS answers “how should I manage many VMs?”; zones and fault domains answer “where should those instances be isolated?”
Protect from rack or maintenance-domain failure → availability set or fault-domain spreading. Protect from datacenter failure → multiple availability zones. Add repeatable group management, autoscale and coordinated updates → Virtual Machine Scale Sets. Protect from regional failure → add a separate regional recovery or multi-region strategy.
Availability sets vs zones vs VM Scale Sets
These options do not make a single-instance application highly available. Every design needs at least two usable application instances, a way to direct traffic only to healthy instances, and a data tier that can meet the same failure objective.
Availability sets: fault domains and update domains
A fault domain represents a group of hardware that shares failure-prone infrastructure such as power, cooling and networking. Azure places set members across available fault domains so one hardware failure is less likely to affect every VM.
An update domain identifies VMs that can restart together during planned platform maintenance. Azure processes one update domain at a time and allows recovery before moving to another. Update domains are about coordinated platform maintenance; fault domains are about shared physical failure.
The fault-domain and update-domain counts are selected when the availability set is created and cannot be changed later. VMs also need to be created in the set; moving an existing VM into an availability set is not a simple property edit. Plan placement before deployment.
Microsoft currently recommends Virtual Machine Scale Sets with Flexible orchestration for the broadest high-availability feature set. Availability sets remain relevant for supported legacy patterns, regions without zones, and latency-sensitive workloads that accept the smaller failure boundary.
Availability zones: datacenter-level isolation
Zones have independent power, cooling and networking. Deploying application instances across zones can protect from a failure that takes one datacenter location offline. But a zonal deployment must be complete: healthy-zone compute is not useful if every database, disk, public IP or network dependency remains tied to the failed zone.
Application instance A
Receives traffic through a zone-resilient load-balancing design and uses a data tier that supports the required resilience.
Application instance B
Runs independently from Zone 1 and has capacity to serve traffic when the other instance is unhealthy.
Azure does not automatically make every application zone resilient because two VMs use different zone numbers. Configure health probes and traffic routing, confirm the VM size is available in each selected zone, select compatible zonal or zone-redundant dependencies, and test the application when one instance is unavailable.
A nonzonal or regional VM can be placed anywhere in the region by the platform, but that does not guarantee protection from a zone failure. A single zonal VM provides placement control, not high availability. The exam clue is usually “two or more instances across separate availability zones.”
Virtual Machine Scale Sets: placement plus orchestration
Scale sets create and manage groups of VMs. Their capacity can change manually, on a schedule or through autoscale rules. Integration with Azure Load Balancer or Application Gateway helps send requests to healthy instances as the group changes.
Flexible orchestration supports individual VM lifecycle control, mixed VM sizes and more flexible instance configurations. It can spread instances across fault domains in one region or across selected zones. Microsoft recommends Flexible mode for many new high-availability workloads.
Uniform orchestration uses a shared VM profile and treats instances as a uniform group. It works well for large sets of identical, stateless workers or web instances. Some lifecycle and configuration operations behave differently between modes, so select the mode from workload requirements. The orchestration mode cannot be changed after creation.
Upgrade policy matters. A model change does not necessarily update every running instance immediately. Manual, Automatic and Rolling policies control how changes reach instances. For production, consider health probes, batch size, pause time, rollback behavior and capacity before rolling an image or extension update.
Autoscale also needs safety boundaries: minimum, maximum and default capacity; scale-out and scale-in conditions; cooldown; and a scale-in policy. A stateless application should drain or tolerate removed instances. A stateful workload needs explicit data and quorum handling before automatic scale-in is safe.
Scenario 1: two legacy VMs in a region without zones
A line-of-business application requires two VMs in the same region. Availability zones are unavailable, and the application needs low VM-to-VM latency. Create an availability set first, place both VMs in it, and distribute client traffic through an appropriate load balancer with a meaningful health probe.
It separates the VMs across available fault and update domains. It improves hardware and maintenance isolation but must not be described as protection from a datacenter or region outage.
Scenario 2: stateless web tier with unpredictable demand
The web tier uses one image, can start and stop instances safely, and must survive a datacenter failure. Use a zone-spanning VM Scale Set, configure autoscale, integrate health-based load balancing and choose an upgrade policy that preserves enough healthy capacity during deployment.
Zones provide the required datacenter isolation. VMSS provides repeatable instances, group updates and capacity management. Neither control alone expresses the whole solution.
Scenario 3: one critical VM in Zone 1
The VM is pinned to Zone 1, so its placement is known but it remains a single point of failure. Create another application instance in another zone, configure traffic failover and make the data and network dependencies resilient. If the workload cannot run active-active, evaluate a tested recovery design with acceptable RTO and RPO.
These are original learning scenarios, not customer incidents or recalled Microsoft exam questions.
Production-style failure: scale set capacity increased but users still see errors
- Check instance provisioning state. Requested capacity is not the same as healthy application capacity.
- Inspect instance health. Review load-balancer probes or the application health extension and confirm the new instances become ready.
- Verify the image and extensions. A startup script, package repository, secret or extension can fail consistently on every new VM.
- Check backend registration. Confirm new NICs enter the correct backend pool and traffic reaches the expected port.
- Review autoscale timing. Evaluation windows, aggregation, cooldown and application startup time can delay useful capacity.
- Check quotas and zone capacity. Subscription vCPU quota or SKU availability can prevent the requested placement.
- Inspect downstream bottlenecks. Scaling the web tier cannot fix an exhausted database connection pool or zonal dependency.
Production-style failure: VMs are in separate zones but the app is unavailable
- Verify the load balancer or gateway health probe reflects application readiness rather than only an open TCP port.
- Confirm traffic can reach healthy-zone instances and that NSGs, routes and backend-pool membership are correct.
- Check whether shared disks, databases, private endpoints or DNS dependencies remain tied to one failed zone.
- Verify healthy zones have enough capacity for the surviving workload.
- Test application state, session handling and data replication; infrastructure placement alone cannot repair application coupling.
Common AZ-104 exam mistakes
- Claiming one zonal VM is highly available.
- Choosing an availability set when the requirement explicitly includes datacenter failure.
- Assuming a scale set automatically spans zones without checking its placement configuration.
- Treating VMSS and availability zones as mutually exclusive alternatives.
- Confusing fault domains with update domains.
- Assuming different fault domains protect from every datacenter-wide outage.
- Forgetting health probes and load balancing in a multi-instance design.
- Ignoring the data tier and other zonal dependencies.
- Expecting a scale-set model update to reach existing instances regardless of upgrade policy.
- Changing orchestration mode after deployment.
- Using autoscale for stateful instances without safe scale-in behavior.
- Presenting availability sets or zones as multi-region disaster recovery.
Frequently asked questions
What is the main difference between an availability set and an availability zone?
An availability set spreads VMs across fault and update domains within a datacenter. Availability zones are physically separate groups of datacenters within an Azure region and protect a multi-instance design against a datacenter-level failure.
Does a Virtual Machine Scale Set replace availability zones?
No. A scale set manages and scales a group of VM instances. You can deploy its instances regionally, within one zone or across multiple zones. The scale set provides orchestration; the selected placement model determines the failure boundary.
Can one VM be in an availability set and an availability zone?
No. Availability sets and availability zones are different placement choices for individual Azure VMs. For new high-availability designs in supported regions, Microsoft generally recommends zone-resilient placement or Flexible Virtual Machine Scale Sets according to workload requirements.
What is the difference between a fault domain and an update domain?
A fault domain groups hardware that shares power, cooling and network infrastructure. An update domain groups VMs that Azure can restart together during planned platform maintenance. Availability sets distribute VMs across both domain types.
Which VM Scale Set orchestration mode should I learn for AZ-104?
Understand both. Flexible orchestration supports heterogeneous VM configurations and individual VM management with fault-domain or zonal placement. Uniform orchestration uses a shared scale-set model for identical instances. The mode is selected when the scale set is created and cannot be changed later.
Official Microsoft references
Confirm current implementation details in Microsoft Learn: the AZ-104 study guide, availability sets overview, VM reliability guidance, Virtual Machine Scale Sets overview and scale-set reliability guidance.