Choose Dedicated Host failure replacement before relying on automatic recovery

Source facts

Azure Dedicated Host normally service-heals an unhealthy host by moving its VMs to healthy hardware and restarting them, with downtime during that process. Disabling automatic replacement can instead leave the host pending deallocation after failure, requiring manual creation of a replacement host and VM movement. Microsoft describes auto-replacement as a creation-time setting that cannot later be changed. Manually stopped or deallocated VMs are not moved by automatic service healing. Microsoft Learn.

Applicability

Use this decision when a host-affinity requirement is being weighed against automated recovery. Include deliberately stopped VMs in the recovery inventory instead of assuming every associated machine participates in service healing.

DSE recommendation

Document the manual recovery owner before opting out of automatic host replacement. Have the workload and platform owners agree how failure will be detected, who will provision replacement capacity, and how each VM will be recovered under the chosen setting. Record the reason for any opt-out and the intended recovery procedure before host creation. Do not equate a dedicated physical boundary with uninterrupted service.

Verification

Inspect the created host’s actual auto-replacement property and reconcile the VM inventory with the recovery plan. Rehearse the decision and authorized recovery steps in a controlled environment without manufacturing a production host failure. After a real or approved recovery event, verify each workload separately and account for machines that were stopped beforehand. Keep missing recovery evidence open rather than reporting host availability as complete application restoration.

Official references

Microsoft Learn: Azure Dedicated Hosts. Source reviewed September 9, 2026.