Recommend a High Availability Solution for Compute — Lesson

A retail bank pushes a routine OS patch to its payment-processing fleet on a Wednesday afternoon. Twenty minutes later the platform team gets paged: half the gateway VMs are offline, transactions are queueing, and the SRE on duty cannot find the postmortem template fast enough. The cause is not the patch — the cause is that the fleet was deployed into a single fault domain on a single host. A platform that the architect had described as "highly available" turned out to be just "redundantly deployed". This lesson is about closing that gap, deliberately, before an incident exposes it.

We will work through Azure's high availability story for compute the way the AZ-305 exam expects you to: distinguishing intra-datacentre fault isolation from cross-datacentre zonal isolation, choosing between Availability Zones, Availability Sets, and Virtual Machine Scale Sets, and reading composite SLAs so that a design with three nines on paper does not melt to two nines in production. Reference: the AZ-305 exam study guide, particularly the modules on regions and zones, VM availability options, and Standard Load Balancer traffic distribution.

Why This Matters

Compute is where the application lives, and the application is what the customer touches. When VMs become unreachable — host failure, planned maintenance, networking blip in a rack — every second the workload is down is a second the business is offline. Microsoft's SLAs make the cost vivid: a single-instance VM with Premium SSDs sits at 99.9%, a multi-VM Availability Set reaches 99.95%, and zone-redundant deployments climb to 99.99%. The gap between 99.9% and 99.99% is the difference between $8.76 hours and 52 minutes of allowable annual downtime — money, reputation, and, in regulated industries, fines.

HA design is also dense exam territory because it forces you to integrate three loose ends at once: physical placement (zones, fault domains), traffic distribution (Standard Load Balancer, Application Gateway), and scaling primitives (VMSS Uniform vs Flexible). If you can confidently choose between an Availability Set and an Availability Zone deployment, recommend VMSS Flexible for a mixed fleet, and explain why a single-zone Standard Load Balancer fails open the whole region, you will pass this slice of the exam and design compute HA like a senior architect. The career payoff is concrete: every greenfield landing zone, every lift-and-shift migration, and every "make this resilient" workshop touches this LO.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• Azure regions and region pairs. Can you name your local region's paired region and describe why pairs exist? — Self-check: what does it mean for an Azure service to "honor region pairs"?
• The IaaS resource stack. Do you know what a VM, NIC, disk, and resource group are, and how they relate? — Self-check: which of these are zonal resources and which are regional?
• Load balancing fundamentals. Are you comfortable with the difference between layer-4 (Standard Load Balancer) and layer-7 (Application Gateway) load balancing? — Self-check: which one terminates TLS?
• SLA arithmetic. Can you multiply two SLAs to compute a composite? — Self-check: a service with two dependencies at 99.95% has a composite SLA of what?
• Managed disks and storage redundancy. Do you know LRS, ZRS, GRS at a sentence-each level? — Self-check: which of these tolerates an entire datacentre failing?

If you cannot answer one or two of these confidently, pause and read the relevant module from Unit 1 and Unit 3 of the AZ-305 guide before continuing.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse a workload's availability requirements (SLA target, fault domain isolation needs, latency budget) and translate them into a compute HA pattern.
2. Evaluate the trade-offs between Availability Sets, Availability Zones, and Virtual Machine Scale Sets (Uniform vs Flexible) for a given workload.
3. Design a zone-redundant fleet behind a Standard Load Balancer that meets a 99.99% SLA without unnecessary cost.
4. Recommend an orchestration mode for VMSS based on instance heterogeneity, fault-domain count, and platform features required.
5. Recognise composite SLA traps — single-zone load balancers, single-region dependencies, unmanaged disks in Availability Sets — that silently downgrade a design.
6. Design an autoscale rule set that keeps an HA fleet appropriately sized without thrashing or cost runaway.

Building Blocks

Read this section as a glossary you will need before the Deep Dive. Each term follows the same shape: an everyday analogy, a formal definition, then the reason it matters for the exam.

Availability Zone (AZ) — Think of an Azure region as a city block and zones as three physically separated buildings on that block, each with its own power, cooling, and network spine. Formally, an AZ is a physically separate datacentre within an Azure region, with independent power, cooling, and networking, connected to other zones by a low-latency private fibre. It matters because zonal isolation is the only Azure construct that survives an entire datacentre going dark — a 99.99% SLA depends on it.

Fault Domain (FD) — Like a circuit breaker in a server cabinet: anything sharing the breaker goes out together. Formally, an FD is a logical grouping of hardware that shares a single point of failure (rack, top-of-rack switch, power). Availability Sets give you up to 3 FDs; VMSS can give you up to 5. It matters because spreading VMs across FDs is what protects you from a single rack incident.

Update Domain (UD) — Like floors in an office building being painted one at a time so the business never fully shuts down. Formally, a UD is a logical grouping of hardware that the Azure platform reboots together during planned maintenance. Availability Sets provide 5 UDs by default (configurable up to 20). It matters because UDs protect against the planned-maintenance side of downtime, which is far more frequent than unplanned hardware failure.

Availability Set — A pre-zonal pattern: tell Azure "spread these VMs across FDs and UDs in one datacentre". Formally, an Availability Set is a logical grouping that distributes its member VMs across the configured fault and update domains within a single datacentre. SLA: 99.95% for $\ge 2$ VMs. It matters because it is still the right choice in regions without AZ support and for sub-millisecond intra-set latency.

Availability Zone deployment (zonal vs zone-redundant) — Two flavours: pin a VM to one zone (zonal) or let the platform stripe it across zones (zone-redundant). Formally, "zonal" pins the resource to AZ 1, 2, or 3 for predictable failure-domain semantics; "zone-redundant" makes the platform manage zone placement for you. It matters because zone-redundant gives you a 99.99% SLA and the strongest blast-radius protection a single region offers.

Virtual Machine Scale Set (VMSS) — Think of it as a herd-managed fleet of VMs that scales together. Formally, VMSS is a compute resource that provisions and manages a group of identical (Uniform) or heterogeneous (Flexible) VMs as a single object, with built-in autoscale, rolling upgrade, and zone or AS placement. It matters because most modern HA designs target VMSS Flexible over plain Availability Sets.

Standard Load Balancer (SLB) — A regional, zone-aware traffic cop in front of your fleet. Formally, Standard Load Balancer is a layer-4 distribution service that supports zone-redundant and zonal frontends, HA Ports, and per-VM health probes. SLA: 99.99% when configured zone-redundant. It matters because the load balancer is the choke point — if it is single-zone, your fleet's HA collapses to that zone.

Composite SLA — The product of dependent SLAs. Formally, when a system depends serially on services with SLAs $S_1, S_2, \dots, S_n$, its composite SLA is $\prod S_i$. It matters because architects routinely overstate availability by quoting one component's SLA — a 99.99% VM behind a 99.9% load balancer is a 99.89% system.

Deep Dive

1. Availability Set vs Availability Zone — when each one wins

Availability Sets and Availability Zones solve overlapping but distinct problems. An Availability Set protects you from rack and host failures within a single datacentre; an Availability Zone deployment protects you from the entire datacentre failing. Microsoft's published VM SLAs make the difference concrete.

[!TIP] The single-instance SLA only applies if every OS and data disk is Premium SSD or Ultra Disk. A Standard HDD on the same VM downgrades the SLA to 95% — a frequent exam distractor.

Disk eligibility for the published SLAs is a frequent gotcha. The table below pairs each disk SKU with whether it qualifies a VM for the Premium-disks SLA:

Choose Availability Sets when (a) the target region does not yet have AZ support, (b) you need every VM on the same low-latency physical fabric, or (c) you are migrating an existing on-prem cluster pattern that assumes single-datacentre fate-sharing. Choose Availability Zones everywhere else: greenfield workloads, regulated workloads with high SLA commitments, and any design where the customer asks for "four nines".

[!WARNING] You cannot mix Availability Set and Availability Zone placement on the same VM — they are exclusive properties at create time and immutable afterwards. Moving from AS to AZ requires recreating the VM (capture image, redeploy, attach data disks).

2. Zonal vs zone-redundant — the placement decision

Inside an AZ-enabled region you still have a placement decision to make. Zonal pins a VM to a specific zone (1, 2, or 3); zone-redundant lets the platform spread instances. The pattern most teams want is zone-pinned compute fronted by a zone-redundant load balancer.

The reason for zone-pinning the VMs and zone-redundancy at the load balancer is symmetry: each VM has a predictable failure-domain identity (you can drain or patch by zone), while the entry point survives any single zone going dark. If you instead used a zonal Standard Load Balancer pinned to zone 1, losing zone 1 would take the whole system down even though the compute fleet had survivors in zones 2 and 3.

[!IMPORTANT] A Standard Load Balancer frontend IP is either zonal or zone-redundant — you choose at create time. The exam frequently tests the case where a designer used a Basic Load Balancer (zonal-only, 99.9% SLA, deprecated for production) and the workload silently fails its 99.99% commitment.

The next table is the canonical Basic vs Standard load balancer comparison the exam mines repeatedly:

3. VM Scale Sets — Uniform vs Flexible

VMSS has two orchestration modes and the exam tests the difference. Uniform treats the set as a single identical fleet — same SKU, same image, scaled as a unit. Flexible treats the set as a managed grouping of individually addressable VMs that can be heterogeneous, span zones, and even mix sizes.

Microsoft's guidance since 2022 is to default to VMSS Flexible for new deployments because it unifies the orchestration model with regular Microsoft.Compute/virtualMachines resources, supports mixed instance types, and aligns more cleanly with Availability Zone semantics. Uniform remains in place for legacy stateful workloads or scenarios that depend on VMSS Uniform-specific extensions.

[!NOTE] For VMSS Flexible, set platformFaultDomainCount: 1 when deploying across zones — the platform treats each zone as its own fault boundary, so a higher count is redundant and frequently rejected with OperationNotAllowed errors.

4. Composite SLA — doing the arithmetic honestly

Architects routinely quote a single component's SLA as the system SLA. That is wrong. When a request path depends serially on multiple services, the composite SLA is the product. Consider a design with a zone-redundant Standard Load Balancer (99.99%), zone-spread VMs in VMSS Flexible (99.99%), and Azure SQL DB Business Critical zone-redundant (99.995%):

0.9999 * 0.9999 * 0.99995 = 0.99975

Composite SLA $= 99.975\%$. That figure goes on the architecture review document, not the headline number of any single component. The fix when this is too low is to add a redundant path, not to inflate a component's nominal SLA.

[!TIP] Use the AzureActivity table to detect VMs that were recreated without their original Availability Set membership — a silent regression that downgrades a workload's SLA from 99.95% to 99.9%.

5. Beyond IaaS — App Service and AKS in the same conversation

The LO is framed around compute generically, and the exam often slips PaaS into a "what is the right service" question. App Service Premium v3 supports zone redundancy with a minimum of 3 instances and inherits the 99.99% SLA when configured zone-redundant. Azure Kubernetes Service (AKS) supports zone-spread system and user node pools and, since the Uptime SLA add-on, offers a control-plane SLA of 99.95% (99.99% with AZ-spread node pools for data-plane availability). Read the workload's container vs VM disposition first; if it is container-native, default to AKS with zone-spread node pools rather than building zone-redundant VMSS from scratch.

Worked Examples

Easy — pick the SLA-meeting pattern

Problem. Contoso runs an internal HR portal on three Linux VMs in East US. Leadership has set a target SLA of 99.95%. The portal is not customer-facing and the region has full AZ support. Cost is the dominant factor. Which compute HA pattern is the right recommendation?

Solution. Two patterns can hit 99.95% or better: an Availability Set with three VMs (exact 99.95%) and a multi-zone deployment (higher than required at 99.99%). Because cost is dominant and the target is exactly 99.95%, the Availability Set is the right answer — it avoids the cross-zone bandwidth charges and the requirement to size the fleet across 3 zones. Every VM uses Premium SSD OS and data disks to remain eligible for the SLA.

[!NOTE] If the workload were customer-facing or the leadership target had been 99.99%, the right answer flips to multi-zone VMSS Flexible despite higher cost.

Medium — a deployment-time mistake

Problem. An architect proposes deploying 4 VMs into VMSS Flexible across zones 1, 2, and 3, with platformFaultDomainCount: 5. The deployment fails with OperationNotAllowed. The architect re-tries with platformFaultDomainCount: 3 and it still fails. What is the right configuration?

Solution. When VMSS Flexible is configured with zones: ['1', '2', '3'], the platform treats each zone as its own fault domain — you must set platformFaultDomainCount: 1. The higher counts are valid only for regional (non-zonal) VMSS Flexible deployments. The corrected snippet:

[!NOTE] The exam will sometimes phrase this as "the deployment fails — what should the architect change?" — the answer is the FD count, not the zone list. Memorise the pairing: zones set → platformFaultDomainCount: 1.

Hard — composite SLA against a regulatory floor

Problem. Fabrikam Bank has a regulatory commitment of 99.95% user-visible availability for its retail banking front door. The architecture is Application Gateway (multi-zone, 99.95%) in front of App Service Premium v3 (zone-redundant, 99.99%) talking to Azure SQL DB Business Critical (zone-redundant, 99.995%). Auditors ask: does the design meet the commitment, and what is the single cheapest change to harden it?

Solution. Composite SLA $= 0.9995 \times 0.9999 \times 0.99995 = 0.99935$, i.e., 99.935% — below the 99.95% floor. The dominant term is the Application Gateway at 99.95%. The cheapest hardening that lifts the composite above the floor is to move to Application Gateway v2 with a Web Application Firewall tier deployed zone-redundant, which raises the gateway SLA to 99.99%. Recomputing: $0.$9999 \times 0.9999 \times 0.99995 = 0.99975 = 99.975$%$ — comfortably above 99.95%.

[!NOTE] The exam tests this exact arithmetic shape — three services in a chain, one weak link, asked to identify the cheapest harden. Always identify the lowest-SLA term first; that is the lever.

Visual Explanations

Figure 1 — Decision flow for compute HA placement

The first branching point is whether the SLA target needs zonal isolation; the second is whether AZ support is available locally. When AZ support is missing, the right answer is rarely "use an Availability Set anyway" — it is to move the workload to a region that does have AZ support, because regulator and customer-facing SLAs are almost always above 99.95%.

Figure 2 — Physical topology of a zone-redundant fleet

The diagram shows the canonical pattern: one VM per zone, fronted by a zone-redundant Standard Load Balancer. Losing any single zone removes one VM from rotation but neither the load balancer frontend nor the workload as a whole goes down.

Figure 3 — Availability Set fault and update domains

The exam often pairs this table with a "what does 3 fault domains buy you that 2 does not?" question. The honest answer is "marginal additional rack isolation"; the bigger lever is moving from FD-based protection to zone-based protection.

Common Mistakes

❌ Myth: Two VMs in an Availability Set give me 99.95% regardless of disk type. ✅ Reality: The 99.95% SLA only applies if every OS and data disk on every VM in the set is Premium SSD or Ultra Disk. A single Standard HDD downgrades the set to 99.9% (the single-VM Premium SSD SLA). Why it's tricky: Customers often add a Standard HDD as a "log disk" to save money and unwittingly downgrade the whole set's SLA. The Azure portal does not warn you.

❌ Myth: A multi-zone deployment automatically means a 99.99% end-to-end SLA. ✅ Reality: Only the compute layer is zone-protected. A single-zone Standard Load Balancer, a non-zone-redundant Application Gateway, or a Basic Load Balancer in the path collapses the end-to-end SLA back to the weakest link. Why it's tricky: Architects focus on the VMs because that is where the named workload lives; they forget that the request path is the choke point.

❌ Myth: I can convert an Availability Set deployment to an Availability Zone deployment in-place. ✅ Reality: availabilitySet and zones are mutually exclusive immutable properties on a VM. Moving from AS to AZ requires a recreate: capture an image (or use Azure Site Recovery), redeploy the VM with a zone assigned, and reattach data disks. Why it's tricky: The two patterns look swappable in the portal UI, which presents them as alternative dropdowns. The fact that they are immutable post-create is buried in CLI documentation.

❌ Myth: VMSS Uniform is interchangeable with VMSS Flexible — the orchestration mode is just a flag. ✅ Reality: Mode is selected at create time and is not changeable. The two modes also expose different child resource types (virtualMachineScaleSets/virtualMachines for Uniform, virtualMachines for Flexible), so Bicep, Policy assignments, and RBAC scoping all differ. Microsoft recommends Flexible for all new deployments. Why it's tricky: The exam will sometimes use a Bicep snippet with orchestrationMode: 'Uniform' and ask what is wrong — the answer is "this is the legacy mode; new deployments should use Flexible".

Practice Exercises

🟢 Exercise 1. A workload runs on 2 VMs in East US with Premium SSD disks, deployed as standalone VMs (no Availability Set, no zone). What is the workload's SLA?

▶💡 Hint

Each VM is single-instance. There is no Azure-level grouping that grants the 99.95% SLA.

▶✅ Solution

Each VM has a 99.9% SLA. With no Availability Set or zone deployment grouping the two VMs into a single SLA construct, Azure treats each as independent and grants you no aggregate SLA. The honest design SLA is 99.9% per VM — losing either VM is an outage of that VM's share of the workload.

🟡 Exercise 2. Recommend the orchestration mode for a fleet that mixes 20 Spot VMs (for cost) and 4 Standard VMs (for baseline capacity), all running the same OS image and serving the same traffic.

▶💡 Hint

Only one of Uniform and Flexible supports mixed Spot + Standard membership.

▶✅ Solution

VMSS Flexible. Uniform requires every instance to be identical, including priority (Regular vs Spot). Flexible allows mixed priorities and is the supported pattern for an "everyday + spot for headroom" design. Configure 4 Regular instances as the minimum capacity and let autoscale add Spot up to the maximum, with eviction policy set to Deallocate so the OS disk is preserved.

🟡 Exercise 3. You inherit a Bicep file that deploys a Standard Load Balancer with frontendIPConfigurations[0].zones: ['1']. The fleet behind it is multi-zone VMSS Flexible. What is the effective workload SLA, and what is the one-line fix?

▶💡 Hint

A zonal frontend pinned to one zone is a single point of failure regardless of how the backend pool is spread.

▶✅ Solution

The frontend is zonal in zone 1, so any failure of zone 1 takes the entire entry point down. The end-to-end SLA collapses to the load balancer's zonal SLA of 99.9%. Fix: remove the zones property to make the frontend zone-redundant by default, or set it explicitly to ['1', '2', '3']. After the fix the composite SLA climbs to roughly 99.98%.

🔴 Exercise 4. Compute the composite SLA of a path that traverses Front Door Premium (99.99%), Application Gateway v2 ZR (99.99%), VMSS Flexible multi-zone (99.99%), and Azure SQL DB Business Critical ZR (99.995%). The customer asks: "is this enough for a 99.99% user-visible commitment?"

▶💡 Hint

Multiply, then compare to the floor. The trick is that even four "four-nines" services compound below 99.99%.

▶✅ Solution

$0.9999 \times 0.9999 \times 0.9999 \times 0.99995 = 0.99965$, i.e., 99.965%. That is below the 99.99% commitment despite every component meeting four nines. The fix is to design Front Door and Application Gateway as alternative entry paths (active-active rather than serial), reducing the serial chain to three components and pulling the composite back above 99.99%.

🔴 Exercise 5. A stateful workload pins one VM to Availability Zone 1 with a Premium SSD OS disk and a ZRS-class Azure Files share for app data. The customer asks why the architect did not pick LRS for the disk to save money. Defend the design.

▶💡 Hint

The disk and the VM are colocated; the file share is the part that survives zone loss.

▶✅ Solution

For a zonal VM, LRS is acceptable for the OS disk because the disk's failure domain is already the same as the VM's — if zone 1 goes down, the VM goes down regardless of disk replication. ZRS on the OS disk would not help. ZRS on the Azure Files share is the correct choice because the share's purpose is to survive zone loss and be remountable from a recovery VM in zone 2 or 3. The architect optimised correctly.

🟢 Exercise 6. True or false: a Basic Load Balancer is acceptable as the frontend for a production workload requiring 99.99% availability.

▶💡 Hint

Check the SLA and zone support for Basic Load Balancer.

▶✅ Solution

False. Basic Load Balancer has no published SLA and is being retired (deprecation announced — basic SKU support ends September 2025). Production workloads requiring any SLA commitment should use Standard Load Balancer with a zone-redundant frontend.

🟡 Exercise 7. Design an autoscale rule set for a VMSS Flexible multi-zone fleet that serves bursty web traffic. The constraints: minimum capacity 3 (one per zone), maximum capacity 30, cool-down 5 minutes, target CPU $\sim 60\%$.

▶💡 Hint

Use two rules — scale-out when CPU is high and scale-in when CPU is low — with asymmetric cool-downs.

▶✅ Solution

Two rules: scale-out by 3 instances (one per zone) when average CPU > 75% over a 5-minute window; scale-in by 1 instance when average CPU < 40% over a 10-minute window. Asymmetric cool-down avoids thrashing. Set min capacity 3 and max 30. Scaling out by 3 at a time preserves the zone balance — adding one instance at a time would temporarily skew the fleet toward a single zone before the next rule firing.

Summary & Concept Map

The headline takeaways from this lesson:

• The SLA target sets the pattern. 99.9% is single VM with Premium SSD; 99.95% is an Availability Set of two or more such VMs; 99.99% requires a multi-zone deployment fronted by a zone-redundant Standard Load Balancer.
• Availability Zones are the durable answer in any region that supports them. They are the only Azure construct that survives an entire datacentre going dark and is the only path to a 99.99% compute SLA.
• VMSS Flexible is the default for new compute fleets and pairs naturally with zone deployments via platformFaultDomainCount: 1 and explicit zones.
• Composite SLA is the product of dependent service SLAs. Architects should compute it explicitly and identify the lowest-SLA term as the lever for hardening.
• Load balancer placement is a frequent silent regression — a zonal Standard Load Balancer or a Basic Load Balancer in front of a multi-zone fleet drags the whole system down to the load balancer's SLA.
• Availability Set and Availability Zone are mutually exclusive and immutable on a VM; migration between them requires a recreate.
• Disk type matters for SLA eligibility — every disk on every VM must be Premium SSD or Ultra Disk for the published Availability Set and Availability Zone SLAs to apply.

The concept map links the SLA target to the pattern that hits it, then chains each pattern to the configuration constraints that keep the SLA honest. When in doubt during the exam, walk the path from "what SLA?" through the next decision in the diagram and stop at the configuration constraints to look for the trap.