Availability Sets in Azure

An Availability Set in Azure is a logical grouping of two or more Virtual Machines (VMs) that ensures your application remains available during planned or unplanned maintenance events. It improves fault tolerance and high availability by distributing VMs across multiple Fault Domains and Update Domains.

🔑 Key Concepts

• Fault Domain (FD): A group of physical hardware (servers, power supply, network switches) that can fail together. VMs are distributed across different FDs.
• Update Domain (UD): A logical group used for applying updates and patches. Updates are applied to one UD at a time to minimize downtime.

⚙️ Example Diagram

The following diagram shows 2 Fault Domains and 2 Update Domains with 4 VMs spread across them:

📊 Benefits

• High availability with 99.95% SLA (when 2+ VMs are in a set).
• Protection against hardware failures (via Fault Domains).
• Minimal downtime during maintenance (via Update Domains).
• Best for critical workloads (e.g., web servers, DB servers).

📊 Key Benefits

Feature	Benefit
Fault Isolation	Protects against rack-level failures
Update Resilience	Minimizes downtime during maintenance
SLA Guarantee	99.95% uptime when 2+ VMs are used
Cost Neutral	No extra charge for using Availability Sets

🛠️ Best Use Cases

• Web servers in a load-balanced pool
• Database replicas for high availability
• Middleware services that must stay online during updates

Availability Sets vs Affinity Groups in Azure

🧩 Availability Sets: High Availability Strategy

Purpose: Ensures VMs are distributed across multiple fault and update domains, minimizing downtime during hardware failures or planned maintenance.

How it works:

• Azure assigns each VM in the set to a different Fault Domain (FD) and Update Domain (UD).
• Fault Domains: Separate physical racks.
• Update Domains: Logical groups for rolling updates.

Use Case Example:

You deploy two web servers in an availability set. If one rack fails or gets updated, the other stays online. This setup qualifies for Azure’s 99.95% SLA for VM uptime.

Best for:

• Redundant app tiers (e.g., multiple IIS servers, SQL nodes).
• Mission-critical workloads needing high availability.

🧲 Affinity Groups: Resource Co-location Strategy

Purpose: Groups resources physically close together in the same Azure datacenter region for lower latency and better performance.

How it works:

• When you create an affinity group, Azure places all associated resources (VMs, storage, etc.) in the same physical cluster.
• This reduces network hops and improves throughput.

Use Case Example:

You deploy a VM and a storage account in the same affinity group to reduce latency for disk I/O.

Best for:

• Performance-sensitive workloads.
• Legacy deployments (note: largely deprecated in favor of regional VNet placement).

⚖️ Comparison Table

Feature	Availability Set	Affinity Group
Goal	High availability	Low latency via co-location
Fault tolerance	✅ Yes (FD/UD separation)	❌ No fault isolation
SLA eligibility	✅ 99.95% for VMs	❌ Not tied to SLA
Resource placement	Spread across racks	Grouped in same cluster
Modern usage	✅ Recommended	⚠️ Deprecated (use regional VNets)
Configuration timing	Can be added post-deployment	Must be set at resource creation