9.2 Compute High Availability: Load Balancing & VM Scale Set Design

Why This Topic Matters

Availability Sets and Zones (9.1) protect individual VM instances from physical failure, but they don't route traffic or add capacity on their own. AZ-305's compute-HA subgroup also tests whether you can design the layer that sits on top: Load Balancer to distribute traffic across healthy instances, and Virtual Machine Scale Sets (VMSS) to manage the fleet of instances as a single elastic unit. Microsoft has been steering all new designs toward Flexible orchestration for scale sets, and AZ-305 questions increasingly assume that as the default unless a scenario detail (Service Fabric, AKS, Automatic OS Upgrade) forces Uniform instead.

Core Terms and Rules

Azure Load Balancer operates at Layer 4 and distributes inbound TCP/UDP traffic across a backend pool of VM instances based on health probes. It comes in two SKUs:

• Standard SKU — zone-redundant or zonal, integrates with Availability Zones, secure by default (closed unless an NSG allows traffic), and is what Microsoft recommends for all new deployments.
• Basic SKU — regional only, no Availability Zone integration, being retired; do not select it in a design question unless the scenario explicitly forbids Standard-tier cost.

A Virtual Machine Scale Set is a group of load-balanced, identically (or flexibly) configured VMs that Azure can scale in or out automatically based on metrics, a schedule, or manual triggers. There is no extra charge for the scale set construct itself — you pay only for the underlying VM instances.

Flexible vs. Uniform Orchestration

The practical exam rule: default to Flexible for any new, generic "highly available, auto-scaling web/app tier" scenario. Switch to Uniform only when the scenario names a dependency that requires it — Service Fabric, Azure Kubernetes Service (AKS) node pools, or a hard requirement for Automatic OS Image Upgrade that Flexible doesn't offer.

Combining the Pieces

A typical AZ-305-tested compute-HA design layers three things:

1. A VMSS in Flexible mode, configured to spread instances across 2 or 3 Availability Zones (or, in a non-AZ region, across fault domains), with autoscale rules on CPU or queue depth.
2. A Standard Load Balancer in front, health-probing each instance and routing only to healthy backends.
3. An Application Health Extension installed on the instances (required for Flexible orchestration to detect unhealthy VMs and trigger automatic instance repair — Uniform can alternatively use the Load Balancer's own health probe for this).

Autoscale rules for either orchestration mode can trigger on a metric (CPU percentage, queue length, custom Application Insights metric), a schedule (scale up before a known traffic peak), or manual capacity changes. Because scale sets bill only for the underlying VM instances, a well-designed autoscale profile is also a cost lever — scaling in aggressively overnight lowers spend without touching the HA guarantees, since the remaining instances still satisfy the fault-domain or zone-spread requirement as long as the minimum instance count stays at 2 or more.

Exam Scenarios

Scenario 1: An e-commerce front end needs to auto-scale between 3 and 50 identical web servers, mixing Spot instances for cost savings with on-demand instances for baseline capacity, and must tolerate the loss of an entire datacenter. Design decision: VMSS in Flexible orchestration (only Flexible mixes Spot and on-demand in the same set) spread across 3 Availability Zones, fronted by a Standard Load Balancer — reaching the 99.99% SLA.

Scenario 2: A team is migrating an on-premises Service Fabric cluster to Azure VMs and needs the scale set to back the cluster directly. Design decision: Uniform orchestration — Flexible does not support Service Fabric.

Scenario 3: A design calls for the lowest-cost load-balancing tier and does not need Availability Zone awareness. Trap: candidates sometimes pick Basic Load Balancer for cost, but Microsoft is retiring Basic and AZ-305 (current blueprint) expects Standard to be the default recommendation regardless, since Basic cannot be zone-redundant and lacks the security-by-default posture Microsoft now requires in reference architectures.

Takeaways

• Load Balancer is Layer 4/regional; reserve Layer 7/global routing decisions (Front Door, Application Gateway, Traffic Manager) for the networking chapter — but know that Load Balancer is what actually sits in front of a VMSS backend pool.
• Flexible orchestration is the default answer on the current exam; Uniform is the answer only when Service Fabric, AKS, or Automatic OS Image Upgrade is explicitly in play.
• The SLA math for a scale set mirrors plain VMs: instance count and zone spread — not the orchestration mode — determine whether you hit 99.95% or 99.99%.
• Application Health Extension (Flexible) vs. Load Balancer health probe (Uniform, optional) is a subtle distinction the exam can test directly.