How Do You Identify and Clean Up Orphaned Azure Availability Sets Before They Become a Governance Problem?

Availability sets were the original mechanism for distributing VMs across fault domains and update domains in Azure. As workloads have evolved -- and Microsoft now recommends VMSS Flexible orchestration for new deployments -- many organizations have migrated VMs out of availability sets without deleting the empty containers left behind.

These orphaned resources are not billed directly, but they impose real operational costs: polluted inventories, confused engineers, compliance findings, and infrastructure-as-code drift that compounds over time.

What Problem This Solves

Orphaned availability sets cause five distinct problems that compound as your Azure estate grows:

How It Works: Detecting and Remediating Orphaned Availability Sets

Detection Logic

The detection and remediation process follows a simple set of if/then rules:

Validation Evidence

Before deleting any availability set, validate that it is genuinely orphaned by checking:

Detection via Azure CLI

The following command lists all availability sets with zero VMs across the current subscription:

az vm availability-set list \
  --query "[?length(virtualMachines)==`0`].{Name:name, ResourceGroup:resourceGroup, Location:location}" \
  --output table

Detection via Azure Resource Graph (KQL)

For cross-subscription detection at scale, use Azure Resource Graph:

resources
| where type == "microsoft.compute/availabilitysets"
| where array_length(properties.virtualMachines) == 0
| project name, resourceGroup, subscriptionId, location, tags
| order by subscriptionId, resourceGroup

Deletion via Azure CLI

Once an availability set has been validated as genuinely orphaned and safe to remove:

az vm availability-set delete \
  --name <AvSetName> \
  --resource-group <ResourceGroupName>

Automated Detection via Azure Automation

Deploy the following PowerShell runbook in Azure Automation to scan for orphaned availability sets on a recurring schedule and send notifications:

# Azure Automation Runbook: Detect Orphaned Availability Sets
# Schedule: Weekly (recommended)

Connect-AzAccount -Identity

$subscriptions = Get-AzSubscription
$orphaned = @()

foreach ($sub in $subscriptions) {
    Set-AzContext -SubscriptionId $sub.Id | Out-Null
    $availSets = Get-AzAvailabilitySet

    foreach ($avSet in $availSets) {
        if ($avSet.VirtualMachinesReferences.Count -eq 0) {
            $orphaned += [PSCustomObject]@{
                Subscription  = $sub.Name
                ResourceGroup = $avSet.ResourceGroupName
                Name          = $avSet.Name
                Location      = $avSet.Location
                FaultDomains  = $avSet.PlatformFaultDomainCount
                UpdateDomains = $avSet.PlatformUpdateDomainCount
            }
        }
    }
}

if ($orphaned.Count -gt 0) {
    Write-Output "Found $($orphaned.Count) orphaned availability sets:"
    $orphaned | Format-Table -AutoSize
    # Optional: Send email or webhook notification
} else {
    Write-Output "No orphaned availability sets found."
}

Validating IaC References Before Deletion

Before deleting an availability set, verify that no active IaC deployment references it. Use the what-if operation to detect references:

# Check if any ARM/Bicep deployment references the availability set
az deployment group what-if \
  --resource-group <ResourceGroupName> \
  --template-file main.bicep \
  --query "changes[?contains(resourceId, 'availabilitySets')]" \
  --output table

If the availability set appears in the deployment output, update or remove the IaC reference before deleting the Azure resource.

Availability Set vs. VMSS Flex Quick Reference

Understanding the differences between availability sets and VMSS Flexible orchestration helps determine whether orphaned sets should be replaced or simply deleted:

Decision Flowchart for Orphaned Availability Set Remediation

Orphaned Availability Set Remediation Flowchart
================================================

[Start] Is the availability set empty (0 VMs)?
  |
  +-- NO  --> Not orphaned. No action required.
  |
  +-- YES --> Is the availability set referenced in IaC (Terraform, ARM, Bicep)?
        |
        +-- YES --> Remove the IaC reference first.
        |             |
        |             +-- Run terraform state rm or update ARM/Bicep template.
        |             +-- Deploy updated IaC to confirm no drift.
        |             +-- Then proceed to deletion below.
        |
        +-- NO  --> Is the availability set part of a DR/failover plan?
              |
              +-- YES --> Document the retention reason.
              |             |
              |             +-- Tag with: Purpose=DR, RetentionReview=<date>
              |             +-- Schedule review in 90 days.
              |             +-- DO NOT DELETE.
              |
              +-- NO  --> Has the set been empty for > 90 days?
                    |
                    +-- YES --> Delete immediately.
                    |             |
                    |             +-- az vm availability-set delete
                    |             +-- Update resource inventory.
                    |             +-- Log deletion for audit trail.
                    |
                    +-- NO  --> Tag for review.
                                  |
                                  +-- Tag with: Status=Orphaned, DetectedDate=<date>
                                  +-- Notify subscription owner.
                                  +-- Re-evaluate in 30 days.

Decision Tree: Keep vs. Delete

Use this simplified decision tree for each orphaned availability set:

Decision Tree: Migration vs. Cleanup

When an orphaned availability set is found, determine whether the original workload should be migrated to VMSS Flex or simply cleaned up:

Failure Modes

Common Questions

What is an orphaned availability set?

An orphaned availability set is an Azure availability set resource that contains zero virtual machines. This typically happens when VMs are decommissioned, migrated to VMSS Flexible orchestration, or moved to availability zones, but the original availability set container is not deleted afterward. The empty set remains in the subscription indefinitely until manually removed.

Can I just delete all empty availability sets?

Not without validation. While most empty availability sets are genuinely orphaned, some may be intentionally retained for disaster recovery scenarios, where VMs are deployed into pre-configured availability sets during failover. Others may be referenced in IaC configurations that would break if the resource were deleted. Always check for DR dependencies and IaC references before deletion.

What happens if I delete one referenced in Terraform state?

Terraform will detect the drift on the next terraform plan and propose recreating the availability set. If you intended to remove it, you should run terraform state rm for the resource before or after deleting it from Azure, and also remove the resource block from your Terraform configuration files. If you delete the Azure resource without updating Terraform, the state file becomes inconsistent and subsequent deployments may fail or produce unexpected results.

Is there any cost to keeping empty availability sets?

Empty availability sets have no direct Azure billing. However, the indirect cost is significant: they pollute resource inventories, trigger compliance audit findings, create IaC drift, and consume engineering time during governance reviews. For an MSP managing 100 tenants, the cumulative operational cost of investigating orphaned resources can reach 25+ hours per month.

Should I migrate existing availability sets to VMSS Flex?

Microsoft recommends VMSS Flexible orchestration for all new deployments. For existing workloads, migration should be evaluated based on the workload requirements. VMSS Flex provides availability zone support, auto-scaling, and higher instance limits. However, migration requires redeploying VMs -- you cannot move an existing VM from an availability set to a VMSS Flex in-place. This makes it a planned project, not a quick cleanup task.

How do I prevent new orphaned availability sets from accumulating?

Deploy an Azure Policy that audits or denies the creation of new availability sets (since Microsoft recommends VMSS Flex for new workloads). Implement tagging policies that require every availability set to have an owner and purpose tag. Set up automated detection via Azure Automation or Spotto to scan for empty availability sets on a weekly basis and notify the responsible team.

How do MSPs handle orphaned availability sets across multiple tenants?

MSPs typically use Azure Lighthouse to query across all managed tenants with a single Azure Resource Graph query. The KQL query provided above works across all delegated subscriptions when run from the managing tenant. Results can be exported to a central governance dashboard and assigned to per-tenant remediation queues. Spotto automates this entire workflow, scanning all connected tenants and flagging orphaned resources for review.

Are availability sets deprecated?

Availability sets are not formally deprecated, but Microsoft's guidance has shifted clearly toward VMSS Flexible orchestration for new deployments. Availability sets remain supported for existing workloads, and there is no announced retirement date. However, new features and improvements are being added to VMSS Flex rather than availability sets, making them a legacy construct in practice.

What is the difference between an availability set and a VMSS Flexible orchestration?

An availability set distributes VMs across fault domains and update domains within a single datacenter. It does not support availability zones, auto-scaling, or more than 200 instances. VMSS Flexible orchestration provides all of these capabilities plus cross-zone spreading for higher SLA (99.99% vs. 99.95%). VMSS Flex also supports mixing VM sizes within the same scale set and allows individual VM management similar to standalone VMs.

How do I find availability sets that have been orphaned for a long time?

Cross-reference the Azure Resource Graph query results with the Azure Activity Log. Query the Activity Log for each empty availability set to find the last time a VM was added or removed. If no VM-related activity has occurred in 90+ days, the set has been orphaned for at least that long. You can also check the lastModifiedDate in the resource metadata, though this may reflect tag changes or other non-VM modifications.

Use-Case and Scenario Coverage

Implementation Guidance

Preconditions

Required Inputs

Rollout Approach

Terraform Removal

When removing an orphaned availability set from Terraform-managed infrastructure:

# Before: Terraform configuration with availability set
resource "azurerm_availability_set" "legacy_avset" {
  name                = "avset-legacy-web"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  platform_fault_domain_count  = 2
  platform_update_domain_count = 5
}

# Step 1: Remove from Terraform state
terraform state rm azurerm_availability_set.legacy_avset

# Step 2: Remove the resource block from your .tf files
# (Delete the resource block shown above)

# Step 3: Verify clean plan
terraform plan
# Expected output: No changes. Your infrastructure matches the configuration.

# Step 4: Delete from Azure
az vm availability-set delete \
  --name avset-legacy-web \
  --resource-group rg-main

Bicep/ARM Removal

When removing an orphaned availability set from Bicep-managed infrastructure:

// Before: Bicep template with availability set
resource legacyAvSet 'Microsoft.Compute/availabilitySets@2023-09-01' = {
  name: 'avset-legacy-web'
  location: resourceGroup().location
  properties: {
    platformFaultDomainCount: 2
    platformUpdateDomainCount: 5
  }
  sku: {
    name: 'Aligned'
  }
}

// After: Remove the resource block entirely
// (Delete the resource block shown above)

// Step 1: Deploy updated template to remove from deployment state
// az deployment group create --resource-group rg-main --template-file main.bicep

// Step 2: Delete from Azure (if not auto-removed by deployment in complete mode)
// az vm availability-set delete --name avset-legacy-web --resource-group rg-main

Effort Estimate

Failure Modes and Rollback

Rollback Strategy

Availability set deletion is not reversible in the traditional sense. You can recreate an availability set with the same name and configuration, but you cannot add existing VMs to it -- VMs can only be assigned to an availability set at deployment time. This makes prevention (thorough validation before deletion) more important than rollback.

If a deletion was made in error and VMs need to be placed back into an availability set, the rollback path is: (1) recreate the availability set, (2) redeploy affected VMs into the new set during a maintenance window, (3) update all IaC references to point to the new resource ID.

Azure Policy for Prevention

Deploy the following Azure Policy to audit the creation of new availability sets, encouraging teams to use VMSS Flex instead:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "field": "type",
      "equals": "Microsoft.Compute/availabilitySets"
    },
    "then": {
      "effect": "audit"
    }
  },
  "parameters": {},
  "displayName": "Audit creation of availability sets",
  "description": "Audits the creation of new availability sets. Microsoft recommends VMSS Flexible orchestration for new deployments. Existing availability sets should be reviewed for migration to VMSS Flex."
}

Cleanup Action Summary

What to Do Next

Summary