VM Resizing and Scale Set Management

Implement VM Resizing and Scale Set Management

Change the Size of a Virtual Machine (VM)

When a workload needs more CPU, memory, or storage, you can resize an Azure virtual machine to a different size. This process scales the VM up to a larger, more powerful size or down to a smaller, less expensive one. The key tradeoff is disruption: if the new size is not available on the same physical hardware cluster that hosts the VM, the VM must be deallocated (stopped and released from its host) before the change. Deallocation causes a restart and a brief outage, so it matters for stateful applications that cannot easily stop. When you deallocate a VM, the operating system and data disks are preserved, but any dynamic public or private IP address assigned to the VM is released, which could break connections that rely on a fixed address.

Resizing Methods

You can resize a VM through several tools, each following the same basic lifecycle. In the Azure Portal, you navigate to the virtual machine, select a new size, and apply the change; the portal handles the deallocation automatically if needed. With PowerShell, you first run Get-AzVMSize to list the sizes available on the VM's current hardware, then use Update-AzVM to apply the new size. If the desired size is not listed, you must deallocate the VM with Stop-AzVM before resizing. Using the Azure CLI, you check available sizes with az vm list-vm-resize-options, deallocate with az vm deallocate, resize, and then restart the VM. Across all methods, the critical decision point is whether the new size requires a different hardware cluster: if yes, the VM goes through the stopped (deallocated) state and loses its dynamic IP, but keeps its disks and any static IP you assigned.

VM Scale Sets

VM scale sets are groups of identical VMs that work together to handle changes in demand. They keep the application available and cost-efficient by automatically adding or removing instances. Three components make this work:

• Autoscale rules define the conditions that trigger a scale-out (add instances) or scale-in (remove instances), such as average CPU crossing a threshold.
• Load balancing spreads incoming traffic across all healthy instances so that no single VM gets overwhelmed.
• Health probes regularly check each instance; if a VM stops responding, the load balancer stops sending traffic to it, and autoscale rules can replace it.

A scale set depends on the load balancer to distribute requests and on the health probe to detect failure. When demand rises, autoscale adds a new VM. The VM starts in a provisioning state while it is created, then moves to a running state. The load balancer only directs traffic to the VM after the health probe confirms it is healthy. When demand falls, autoscale removes the running instances that have the fewest active connections, following an orderly scale-in policy.

Practical Example: Resizing VMs in an Availability Set

When multiple VMs are grouped in an availability set to protect against hardware failure, you must coordinate the resize operation. First, check if the new size is available on the current hardware using Get-AzVMSize. If it is not available, you must deallocate all VMs in the set at the same time using Stop-AzVM because the entire availability set lives on the same hardware cluster. After they are deallocated, apply the new size to every VM with Update-AzVM, then restart them all with Start-AzVM. This approach prevents a situation where one VM has been resized to a new hardware cluster while another is still on the old cluster, breaking the availability guarantees of the set.