How to gracefully stop and restart applications running inside a VM during automated rightsizing operations

Question

How to gracefully stop and restart applications running inside a VM during automated rightsizing operations

Sree Aravind M 20

We are building an automated VM rightsizing solution that involves deallocating, resizing, and restarting Azure VMs based on utilization metrics. The challenge is that customer VMs may have various applications running inside them such as Docker containers, Java apps, databases, web servers, etc. When we deallocate the VM for resizing, these applications get stopped. After the VM restarts, there is no guarantee that applications will automatically come back up if the customer has not configured auto-start

Jilakara Hemalatha 11,515 Reputation points Microsoft External Staff Moderator

2026-04-07T09:40:18.3+00:00

Hello Aravind,

Thank you for reaching out Q/A and sharing the detailed scenario.

Thank you for sharing the detailed scenario.

We understand your requirement to gracefully handle applications running inside the VM during automated rightsizing operations (deallocate → resize → start). This is an important consideration, especially for production workloads.

From an Azure platform perspective, VM resize and deallocation are treated as infrastructure-level operations. When a VM is deallocated, all in-guest processes are stopped, and upon restart, Azure guarantees only the operating system boot. The platform does not have visibility into or control over applications running inside the VM and therefore does not provide a native capability to gracefully stop or restart them.

Because of this, the recommended approach is to handle application lifecycle management from within the VM itself. In practice, this means adding a small layer of automation inside the guest OS. For example, before initiating the resize, you can trigger a script (using Azure Run Command or a Custom Script Extension) to gracefully stop your applications.

After the VM starts again, the applications should be configured to come back automatically—this can be done using system services like systemd on Linux or Windows Services, or through container restart policies if you are using Docker. It’s also a good idea to include a simple health check after startup to confirm everything is running as expected.

Since VM resizing is inherently a disruptive operation, the safest design is to assume that interruptions will happen and ensure that your applications are resilient to restarts. This approach aligns with Azure’s responsibility model, where Azure manages the VM lifecycle, and the customer manages what runs inside the VM.

Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/resize-vm?tabs=portal

Run scripts in your Windows VM by using action Run Commands

Hope this helps! Please let me know if you have any queries.
RaajaSree Andar Pillai 0 Reputation points

2026-04-07T11:06:30.68+00:00

Thank you for your detailed response and for explaining the recommended approach.

However, I would like to clarify a concern from our side. Our solution operates externally at the infrastructure level, and we do not have the ability to create, modify, or enforce Run Command scripts or in-guest configurations within customer VMs. Because of this, implementing pre-stop scripts or configuring application auto-start inside the VM is not always feasible for us, especially in environments where we do not have administrative control over the guest OS.

Given this limitation, I am a bit unclear on how this scenario should be handled purely from an Azure platform or automation standpoint. Could you please advise if there are any alternative approaches or best practices that can help ensure application availability post-resize without requiring in-guest configuration changes?

Appreciate your guidance on this.