Reliability in Azure Virtual Machines

Azure Virtual Machines provides on-demand, scalable compute resources. As a foundational infrastructure service, it's designed to deliver enterprise-grade reliability and availability for mission-critical workloads.

When you use Azure, reliability is a shared responsibility. Microsoft provides a range of capabilities to support resiliency and recovery. You're responsible for understanding how those capabilities work within all of the services you use, and selecting the capabilities you need to meet your business objectives and uptime goals.

This article describes how to make Virtual Machines resilient to a variety of potential outages and problems, including transient faults, availability zone outages, region outages, and service maintenance. It also describes how you can use backups to recover from other types of problems, and highlights some key information about the Virtual Machines service level agreement (SLA).

Important

When you consider the reliability of a virtual machine (VM), you also need to consider the reliability of your disks, network infrastructure, and applications that run on your VMs. Improving the resiliency of the VM alone might have limited impact if the other components aren't equally resilient. Depending on your resiliency requirements, you might need to make configuration changes across multiple areas.

Production deployment recommendations

For more information about how to deploy VMs to support your solution's reliability requirements and how reliability affects other aspects of your architecture, see Architecture best practices for Virtual Machines and scale sets in the Azure Well-Architected Framework.

Reliability architecture overview

VMs are the fundamental compute unit in Azure, whether you provision the VMs yourself or use other Azure compute services that transparently provision and manage them for you.

An individual VM is also known as a single instance VM. It runs on a specific host, which is a physical server. Most VMs share their host with other VMs.

When you create your VMs, you can influence where they run within the underlying infrastructure. Typically, you make placement decisions based on your requirements for reliability, latency, and isolation. Azure provides several configuration options that affect how your VMs are placed.

• Region: You can select which Azure region that your VM should run in. A region is a geographic area that might contain multiple datacenters, each with a large number of hosts.

• Availability zone: Availability zones are physically separate groups of datacenters within each Azure region. In regions that support availability zones, you can select which zone the VM runs in. For more information, see Resilience to availability zone failures.

• Availability sets: An availability set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability.

  When you use availability sets, Azure distributes a group of VMs across different fault domains. This distribution minimizes the risk of localized hardware failures by grouping VMs that share a common power source and network switch.

  Availability sets can also place different VMs in different update domains, which controls how the Azure platform rolls out platform updates. By using update domains, you can ensure that only a subset of your VMs is restarted for updates at one time.

• Proximity placement groups: For workloads that need to achieve the lowest possible latency between VMs, you can use a proximity placement group to ensure that Azure places the VMs physically close to each other. However, proximity placement means that an outage of the datacenter can affect all of the VMs in the group. To achieve high reliability, you might need to provision multiple proximity placement groups in different availability zones.

• Dedicated hosts: You can use Azure Dedicated Host to provision your own physical server that runs one or more VMs, such as for strict compliance requirements. However, when you provision a dedicated host, an outage in its datacenter can affect all of the VMs on that host. To achieve high reliability, you might need to provision multiple dedicated hosts in different availability zones.

If you create a set of VMs that perform similar functions, consider using Azure Virtual Machine Scale Sets to create and manage the VMs as a group. Scale sets also provide more reliability options, such as spreading the VMs across multiple availability zones.

For more information about availability for VMs, see Availability options for Virtual Machines.

Resilience to transient faults

Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications can handle transient faults, usually by retrying affected requests.

All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see Recommendations for handling transient faults.

Applications that run on your VMs should implement appropriate fault-handling strategies to ensure that any temporary interruptions in service don't affect your workload.

Resilience to availability zone failures

Availability zones are physically separate groups of datacenters within an Azure region. When one zone fails, services can fail over to one of the remaining zones.

You can deploy an individual VM in a zonal configuration, which pins it to a single availability zone that you select. The VM doesn't run in multiple zones simultaneously and isn't zone-redundant. By itself, a zonal VM isn't resilient to zone outages.

If a zone outage happens, zone resilience for Azure VMs (preview) lets you recover an eligible standalone zonal VM in another availability zone in the same region. You must configure the VM for zone resilience in advance. You initiate recovery, and Azure changes the zone placement of the existing VM rather than creating a replacement. The VM retains its resource ID and VM ID and reuses its supported zone-redundant storage (ZRS) disks. The VM stops and restarts during recovery.

Zone resilience for Azure VMs (preview) recovers the VM itself, but it doesn't recover other resources, provide application-level recovery orchestration, or reroute traffic. It doesn't replace a multi-VM deployment for high availability.

Important

Zone resilience for Azure VMs is in preview. Use it only for evaluation and testing with nonproduction VMs. Don't use it for production VMs. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

To maintain application availability during a zone failure, you can deploy multiple VMs in different zones and configure your application to use them. For more information, see Custom multi-zone solutions for resiliency.

If you don't configure a VM to be zonal, it's considered nonzonal or regional. Nonzonal VMs might be placed in any availability zone within the region. If any availability zone in the region experiences an outage, nonzonal VMs might be in the affected zone and can experience downtime.

Requirements

Region support: Zonal VMs can be deployed into any region that supports availability zones.

However, some VM types and sizes are only available in specific regions, or specific zones within a region. To check which regions and zones support the VM types that you need, use the following resources:

• To check the VM types available in each region, see Products available by region.

• To check the supported VM types and sizes within each zone of a specific region, see Check VM SKU availability.

Zone resilience for Azure VMs (preview)

To use zone resilience for Azure VMs (preview), your VM must also meet the following requirements:

• Region support: Zone resilience is supported in regions where the required ZRS managed disks are available. For disk availability, see Requirements for zone resilience.

• VM configuration: Use a standalone zonal VM. Virtual Machine Scale Sets, availability set VMs, and Spot VMs aren't supported.

• Disks: The OS disk and every attached data disk must use Premium SSD ZRS or Standard SSD ZRS.

• Advance enablement: Enable zone movement while the source zone is healthy. Enabling it on an existing VM requires that you first deallocate the VM, which stops it and releases its compute allocation.

For the complete prerequisites, including compatible dependent resources, see Requirements for zone resilience.

Considerations

Zone resilience doesn't protect against region-wide failures. For those scenarios, see Resilience to region-wide failures.

Azure Site Recovery, on-demand capacity reservations, dedicated hosts, and proximity placement groups aren't supported for VMs with zone resilience enabled. For the complete restrictions, see Zone resilience limitations.

Zone resilience for Azure VMs (preview) is intended for disaster recovery.

Cost

There's no cost difference between a zonal and nonzonal VM.

For more information about the cost of zone resilience for Azure VMs (preview), see Zone resilience cost.

Configure availability zone support

This section explains how to configure availability zone support for your VM instance.

Note

When you select which availability zones to use, you're actually selecting the logical availability zone. If you deploy other workload components in a different Azure subscription, they might use a different logical availability zone number to access the same physical availability zone. For more information, see Physical and logical availability zones.

• Create a zonal VM. You can create a zonal VM by using the following guides:

  • Create VMs in an availability zone by using the Azure portal
  • Create a VM in an availability zone by using the Azure CLI
  • Create a VM in an availability zone by using Azure PowerShell

• Enable zone resilience for a zonal VM (preview). You can enable zone movement when you create an eligible zonal VM or on an eligible existing zonal VM. Enable it while the source availability zone is healthy, before an outage occurs. Deallocate an existing VM before enabling the feature. Enablement interrupts workloads on that VM. For configuration instructions, see Enable zone movement.

• Move an existing nonzonal VM to a zonal configuration. You can move from a nonzonal VM to a zonal VM. This process creates a new VM in the target availability zone and requires that you stop the VM during the move process. For more information, see Move Azure single instance VMs from regional to zonal target availability zones.

• Migrate an existing nonzonal VM to a zonal configuration. You can migrate from a nonzonal VM to a zonal VM. This process requires shutting down the virtual machine, updating the zone properties, and starting it again. This feature is currently in preview. For more information, see Migrate to availability zones (preview).

• Change the availability zone of an existing zonal VM. If you enabled zone resilience in advance, you can initiate recovery of an eligible existing VM in another zone. For instructions, see Fail over a VM to another zone. Without zone resilience enabled, you need to deploy a new zonal VM in the desired availability zone.

• Convert a zonal VM to a nonzonal configuration. Zonal VMs can't be converted to a nonzonal configuration. You need to deploy a new nonzonal VM instead.

Capacity planning and management

When you use zone resilience, the target zone must support the VM size and have sufficient capacity when you start the VM. Enabling zone resilience doesn't guarantee that the target zone has capacity. If the VM can't start because capacity is unavailable, you can select another supported zone.

On-demand capacity reservations aren't supported for VMs with zone resilience enabled. For more information, see Zone resilience limitations.

Behavior when all zones are healthy

This section describes what to expect when VM instances are configured with availability zone support and all availability zones are operational.

• Cross-zone operation: Each zonal VM runs in its selected zone. Enabling zone resilience doesn't create another VM instance or distribute application traffic across zones. If you deploy multiple VMs, you're responsible for routing traffic between them, including VMs in different availability zones. Common approaches include Azure Load Balancer and Azure Application Gateway. For more information, see Load balancing options.

• Cross-zone data replication: ZRS synchronously replicates disk data across zones independently of the VM's compute placement. If you deploy multiple VMs, you're responsible for any data replication between them. Databases and other similar stateful applications that run on VMs often provide capabilities to replicate data.

Behavior during a zone failure

This section describes what to expect when VM instances are configured with availability zone support and there's an outage in their availability zones.

• Detection and response: You're responsible for detecting and responding to zone failures that affect your VMs.

  If you enabled zone resilience in advance, you can initiate failover of an eligible VM to a healthy zone. Azure doesn't automatically move the VM. You select a target zone, force-deallocate the VM, change its zone placement, and start it. Force deallocation stops the VM and discards its in-memory state. For instructions, see Fail over a VM to another zone.

• Notification: Microsoft doesn't automatically notify you when a zone is down. However, you can use Azure Resource Health to monitor the health of an individual resource, and you can set up Resource Health alerts to notify you of problems. You can also use Azure Service Health to understand the overall health of the service, including any zone failures, and you can set up Service Health alerts to notify you of problems.

• Active requests: Active requests and other work running on an affected VM are interrupted. Zone resilience doesn't preserve active requests or in-memory state. You're responsible for restarting or retrying application work. For more information, see Resilience to transient faults.

• Expected data loss: Zonal locally redundant storage (LRS) disks might be unavailable during a zone failure.

  With zone resilience for Azure VMs (preview), the documented near-zero recovery point objective (RPO) applies only to data committed to supported ZRS disks. RPO describes how much recent data you might lose during recovery. Active requests, in-memory data, temporary disk data, and application state not written to those disks aren't covered. For more information, see What data does the near-zero RPO cover?.

  If you use ZRS disks without zone resilience and an outage affects your VM, you can force detach your ZRS data disks from the failed VM and attach them to another VM.

  For more information about how to make disks resilient to availability zone failures and other problems, see Reliability in Azure Disk Storage.

• Expected downtime: Without zone resilience, an affected zonal VM remains down until its availability zone recovers. You can restore application availability through other VMs if you configured a custom multi-zone solution.

  With zone resilience, the VM is unavailable while you initiate and complete failover and start it in the target zone. Successful failover lets the VM resume operation before the source zone recovers. Application recovery can take additional time, and you're responsible for verifying application health before restoring traffic. Startup depends on target-zone capacity.

  Zone resilience for Azure VMs (preview) doesn't provide a guaranteed recovery time, and failover is best-effort, not guaranteed.

• Redistribution: With zone resilience, Azure changes the existing VM's zone placement. It doesn't create an additional VM or reroute traffic. You're responsible for verifying the VM and workload before restoring traffic.

  If you deploy multiple VMs across zones, you're responsible for rerouting traffic to VMs in healthy zones.

  If you configure a zone-resilient load balancer and it performs health checks, the load balancer typically detects failed VMs and can route traffic to other VM instances in healthy zones.

Zone recovery

For VMs that remain in the affected zone:

When the zone is healthy, VMs in the zone restart. You're responsible for any zone recovery procedures and data synchronization that your workloads require.

For VMs recovered through zone resilience for Azure VMs (preview), you're responsible for any failback to the original zone after it becomes healthy. You're responsible for deciding whether and when to fail back, initiating the move, and coordinating application recovery and traffic routing. The VM stops and restarts during failback. The feature doesn't provide automatic failback or failback orchestration.

Test for zone failures

You can use Azure Chaos Studio to simulate zone-level failures and test your failover processes. In Chaos Studio Workspaces, the Compute Zone Down Scenario shuts down VMs and virtual machine scale set instances in a target availability zone. To shut down an individual VM, you can use the built-in VM faults in Experiments (classic).

For zone resilience for Azure VMs (preview), use nonproduction VMs to evaluate the feature. You can test the recovery workflow by initiating planned movement between healthy zones. This test lets you verify VM recovery and your application recovery processes, but it doesn't reproduce the conditions of an actual zone outage. For the recovery workflow and validation checks, see Fail over a VM to another zone and Verify failover succeeded.

Custom multi-zone solutions for resiliency

When you deploy multiple VMs into different zones, you're responsible for configuring and managing replication, load balancing, failover, and failback processes.

Some applications provide built-in capabilities that can help when you deploy across multiple VMs. For example, SQL Server on Azure VMs provides a set of capabilities to simplify your configuration and management processes across availability zones.

You can consider using Azure Site Recovery zone-to-zone disaster recovery (DR) when your application runs in a single zone at a time and you don't require near-instant failover between zones. Zone-to-zone DR has some important limitations, so review your requirements thoroughly.

Resilience to region-wide failures

VMs are single-region resources. If the region becomes unavailable, your VM is also unavailable.

Custom multiregion solutions for resiliency

You can deploy multiple VMs into different regions, but you need to implement replication, load balancing, and failover processes.

Site Recovery is a service that enables DR by replicating VMs and their data to a secondary region. You can select almost any Azure region as your secondary region, including nonpaired region combinations. For more information, see Azure to Azure DR architecture.

Some applications create clusters or other constructs to replicate data and distribute work across multiple VMs, including in different regions. These applications can simplify the configuration of a multiregion solution.

For an example architecture that illustrates using VMs across multiple regions, see Multi-region load balancing with Azure Traffic Manager, Azure Firewall, and Application Gateway.

Resilience to service maintenance

Azure performs regular periodic maintenance on VMs to ensure reliability. There are multiple ways that you can ensure your workloads remain operational during maintenance activities:

• When you use availability sets or virtual machine scale sets, you can configure update domains. Update domains help distribute maintenance activities across different VMs at different times, so your VMs don't all restart simultaneously.

• You can customize the timing that maintenance is applied to your VMs by using maintenance control. You can use maintenance configurations to schedule it at a time that suits your workload.

• You can receive notifications of upcoming maintenance activities.

For more information, see Guest updates and host maintenance overview.

Backup and restore

Azure Backup provides native backup support for VMs. Azure Backup creates and manages backups, and provides application-consistent protection for the entire VM, including all attached disks. A VM backup solution with Azure Backup is ideal when you need coordinated backup of multiple disks or application-aware backups. However, for database workloads, consider application-specific backup solutions that provide transaction-consistent protection and faster recovery options.

With Azure Backup for VMs, you can customize the backup frequency, retention duration, and storage configuration to suit your needs. For more information, see Azure Backup for VMs.

Backup also supports disks that are attached to VMs. For more information, see Overview of Azure Disk Backup.

VM backups provide recovery points for accidental deletion or data corruption, but they don't keep an application available during infrastructure failures. Use backups with the availability and disaster recovery approaches described in this guide. For more information about how replication and backup address different risks, see Redundancy, replication, and backup.

Service-level agreement

The service-level agreement (SLA) for Azure services describes the expected availability of each service and the conditions that your solution must meet to achieve that availability expectation. For more information, see SLAs for online services.

For Virtual Machines, the SLA provides a base level of availability. The uptime percentage defined in the SLA increases when you have two or more VMs and you take the following actions:

• Configure those VMs to be deployed across two or more availability zones.
• Configure those VMs to be deployed into an availability set.

Next steps

• VMs in Azure
• Virtual Machine Scale Sets

Related resource

• Reliability in Azure Disk Storage
• Reliability in Azure