Availability set - Azure Glossary

Understand the concept

In plain English

Availability set is a placement group for Azure virtual machines that spreads instances across separate fault and update domains inside one datacenter. In Azure, teams encounter it when architects deploy two or more classic VM instances for an application tier that still needs datacenter-level hardware separation. The useful question is what behavior it proves, who owns it, and what should happen when the signal changes. Good operators tie availability set to service limits, monitoring, access controls, and rollback steps so decisions stay visible during reviews, incidents, and planning.

Why it matters

Availability set matters because a multi-VM application can still fail if every instance sits on the same underlying rack, power path, or maintenance batch. It gives teams a shared reference for deciding whether the service is healthy, correctly configured, and ready for production scale. When it is misunderstood, engineers often chase the wrong symptom: adding more VMs but forgetting to place them across fault and update domains before production. When it is governed well, owners can explain the control, measure business impact, and act before customers notice. That clarity helps reviewers connect cloud settings to uptime, compliance, release quality, and support cost.

Official wording and source

Availability set is a placement group for Azure virtual machines that spreads instances across separate fault and update domains inside one datacenter. Microsoft Learn places it in Availability sets overview - Azure Virtual Machines; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Availability set depends on Azure VM placement, managed disks, fault domains, update domains, region capabilities, and choices made before VM creation. Azure exposes it through availability set resources, VM properties, deployment templates, Azure CLI inventory, and planned maintenance guidance. The important settings or fields are platform fault domain count, platform update domain count, managed disk alignment, VM membership, and load balancer backend membership. Architects should verify whether the workload needs availability sets, zones, scale sets, or another pattern for the required SLA, because wrong assumptions can hide failures, inflate cost, or leave a production change unsupported.

Exam context

AZ-900 Microsoft Azure Fundamentals

Compare with

Availability zone Proximity placement group

Where it is used

Where you see it

You see availability sets on VM resource properties, where each member belongs to one logical set with assigned fault and update domain placement. during reviews.
They appear in deployment templates and CLI output when architects create multiple VMs for the same application tier before attaching load balancing. during reviews. during operational reviews.
They show up during migration reviews when teams decide whether legacy VM pairs should remain in sets or move to zones. during reviews. during operational reviews.

Common situations

Spread VM pairs for legacy application tiers inside one datacenter.
Reduce planned maintenance impact by separating update domains.
Inventory older VM designs before migration to zones or scale sets.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Availability set protects payment VMs Scenario, objectives, solution, measured impact, and takeaway.

Scenario

UnionSquare Credit, a commercial lending bank, needed to solve legacy loan-processing VMs sharing the same maintenance exposure while protecting customer experience and audit commitments. The platform team had a narrow change window and no tolerance for vague ownership.

Goals

Separate paired VMs across update and fault domains.
Keep loan submissions available during planned maintenance.
Document why zones were not available for the legacy tier.
Maintain load-balanced health probes for both instances.

Approach using Availability set

The architecture team used Availability set as the practical control point. Architects created an availability set before rebuilding the two application servers, then attached both VMs to the same load balancer backend pool. The runbook recorded immutable domain counts, managed disk alignment, and a migration note explaining why a full zone redesign would wait for the next application upgrade. They integrated the configuration with Azure Monitor dashboards, deployment notes, and role-based access review so support engineers could see the same evidence as architects. CLI checks were added to the release runbook to confirm the resource scope, current settings, and recent health signals before any production change. The design also included rollback criteria, escalation contacts, and a weekly review of exceptions so the term stayed connected to measurable operations instead of becoming tribal knowledge.

Potential outcomes

Planned maintenance no longer took both VMs offline together.
Loan submission availability improved from 99.71 percent to 99.94 percent.
The migration review identified the future zone-ready target architecture.
Health probes caught one failed instance before users reported errors.

What to learn

Availability sets remain useful for legacy VM tiers when placement is intentional and documented.

Scenario 02 Availability set steadies factory control apps Scenario, objectives, solution, measured impact, and takeaway.

Scenario

BlueForge Components, a industrial manufacturing company, needed to solve plant-floor reporting servers failing together during host maintenance while protecting customer experience and audit commitments. The platform team had a narrow change window and no tolerance for vague ownership.

Goals

Reduce downtime for production reporting below 30 minutes per month.
Separate redundant VMs before the next maintenance event.
Keep operator dashboards behind one stable endpoint.
Create clear replacement steps for failed instances.

Approach using Availability set

The architecture team used Availability set as the practical control point. The infrastructure team deployed replacement VMs into an availability set and moved dashboard traffic through a Standard Load Balancer. Maintenance calendars, VM patch steps, and backend probe behavior were documented so plant operators knew whether a single failed server required escalation or normal repair. They integrated the configuration with Azure Monitor dashboards, deployment notes, and role-based access review so support engineers could see the same evidence as architects. CLI checks were added to the release runbook to confirm the resource scope, current settings, and recent health signals before any production change. The design also included rollback criteria, escalation contacts, and a weekly review of exceptions so the term stayed connected to measurable operations instead of becoming tribal knowledge.

Potential outcomes

Monthly reporting downtime fell from 96 minutes to 18 minutes.
No shift lost access during the next planned host event.
Backend probe failures created actionable tickets automatically.
Replacement instructions reduced VM rebuild time by 45 percent.

What to learn

Availability sets help VM-based applications survive routine platform events when load balancing is included.

Scenario 03 Availability set supports public records portal Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicBridge County, a local government services office, needed to solve a public records portal running on two older virtual machines while protecting customer experience and audit commitments. The platform team had a narrow change window and no tolerance for vague ownership.

Goals

Avoid simultaneous VM restarts during maintenance.
Improve citizen portal availability for tax season.
Verify both servers remain in the intended set.
Prepare evidence for modernization funding.

Approach using Availability set

The architecture team used Availability set as the practical control point. Cloud administrators created the availability set, redeployed the portal servers into it, and added CLI inventory checks to monthly governance reviews. The architecture note compared availability sets, scale sets, and zones, giving budget owners a clear reason for a phased modernization plan. They integrated the configuration with Azure Monitor dashboards, deployment notes, and role-based access review so support engineers could see the same evidence as architects. CLI checks were added to the release runbook to confirm the resource scope, current settings, and recent health signals before any production change. The design also included rollback criteria, escalation contacts, and a weekly review of exceptions so the term stayed connected to measurable operations instead of becoming tribal knowledge.

Potential outcomes

Portal availability rose from 99.6 percent to 99.91 percent during tax season.
Monthly checks caught one incorrectly deployed replacement VM.
The modernization proposal received funding with placement evidence attached.
Citizen support calls about downtime dropped by 27 percent.

What to learn

For older VM estates, availability sets create a practical bridge toward stronger resiliency patterns.

Azure CLI

CLI checks show exactly which VMs belong to each availability set and whether placement values match the approved resilience design.

Useful for

List availability sets in a resource group before a migration review.
Show fault domain and update domain settings for production evidence.
Create an availability set before deploying a paired VM tier.
Find VMs that are or are not assigned to an availability set.

Before you run a command

Confirm the application needs VMs rather than platform services or scale sets.
Choose fault and update domain counts before creating the set.
Plan load balancer probes and backend pools for the VM tier.
Check region and managed disk support for the intended configuration.

What the output tells you

Set output shows platform fault domain and update domain counts.
VM output confirms whether each instance is attached to the intended set.
Creation output records immutable placement choices for release evidence.
Missing availabilitySet values reveal unprotected or incorrectly deployed VMs.

Mapped commands

Operational CLI checks

direct

az vm availability-set list --resource-group <resource-group> --output table

az vm availability-setdiscoverCompute

az vm availability-set show --name <availability-set-name> --resource-group <resource-group>

az vm availability-setdiscoverCompute

az vm availability-set create --name <availability-set-name> --resource-group <resource-group> --platform-fault-domain-count 2 --platform-update-domain-count 5

az vm availability-setprovisionCompute

az vm list --resource-group <resource-group> --query "[?availabilitySet!=null].[name,availabilitySet.id]" -o table

az vmdiscoverCompute

Architecture context

Technically, Availability set depends on Azure VM placement, managed disks, fault domains, update domains, region capabilities, and choices made before VM creation. Azure exposes it through availability set resources, VM properties, deployment templates, Azure CLI inventory, and planned maintenance guidance. The important settings or fields are platform fault domain count, platform update domain count, managed disk alignment, VM membership, and load balancer backend membership. Architects should verify whether the workload needs availability sets, zones, scale sets, or another pattern for the required SLA, because wrong assumptions can hide failures, inflate cost, or leave a production change unsupported.

Security: Security for Availability set starts with knowing which identities, data paths, and administrators can influence it. The main risk is assuming placement separation protects against compromised identities, patched operating systems, or insecure application configuration. Use least privilege, managed identities where available, private networking when required, logging, and change approval for production settings. Review VM administrator access, disk encryption, patch process, backup scope, load balancer exposure, and just-in-time access settings before granting access or accepting a recommendation. Security teams should also confirm that alerts, audit trails, and exception records explain who changed the configuration, why it changed, and what evidence proves the change stayed inside policy.
Cost: Cost impact for Availability set comes from the resources, telemetry, storage, compute, and engineering time connected to it. The most common waste pattern is keeping legacy VM pairs running without checking whether scale sets, zones, or managed services would be cheaper. Estimate the billable resources before enabling features, and compare the expense with the business risk being reduced. Track VM count, disk cost, load balancer cost, backup cost, and migration options for aging availability-set designs so optimization work does not quietly damage reliability or security. For production, pair cost reviews with ownership, budgets, Advisor signals where relevant, and a policy for retiring unused capacity or stale monitoring data.
Reliability: Reliability depends on whether Availability set is designed for the failure modes the workload actually faces. For this term, the common reliability question is whether instance placement protects the application from local hardware failure and planned maintenance interruption. Set measurable thresholds, test during planned change, and make sure incidents have a clear owner and escalation path. Watch VM membership, update domain restarts, health probe status, disk alignment, and application failover behavior so teams can distinguish platform behavior from application defects. A reliable design also includes rollback, regional assumptions, dependency health, and documented limits instead of hoping the default setting will cover every outage.
Performance: Performance depends on how Availability set affects latency, throughput, concurrency, or decision speed in the surrounding workload. The performance risk is placing all traffic on one VM when load balancing or app health probes are not configured correctly. Measure before and after changes using representative traffic, not only averages from a quiet period. Tune load balancer probes, backend pool membership, VM sizing, disk throughput, and patch sequencing while watching error rates, saturation, and customer-facing response time. Performance work should include capacity limits, regional placement, retry behavior, and clear evidence that the optimized path still meets security and reliability requirements. Document the owner, region, change window, and rollback step before production use.
Operations: Operationally, Availability set should appear in runbooks, dashboards, and release checks rather than living only in a portal page. Operators should review which VMs belong to the set, whether new instances were added correctly, and how maintenance events affect the tier on a scheduled cadence and after major incidents. Use tags, resource inventory, activity logs, Azure Monitor, and CLI queries to keep the setting or signal discoverable. During handoffs, explain the application tier protected by the set, the load balancer dependency, and the recovery plan for one failed VM so the next engineer can make a safe decision quickly. Good operations turn the term into a repeatable checklist item with an owner, evidence, and a known path for remediation.

Common mistakes

Creating VMs first and trying to add them to a set afterward.
Using an availability set when availability zones are the real requirement.
Forgetting that sets do not protect against application or OS failures.
Skipping load balancer health probes and assuming placement alone is enough.