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,600 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://dori-uw-1.kuma-moon.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.
Jilakara Hemalatha 11,600 Reputation points Microsoft External Staff Moderator

2026-04-08T05:30:12.2733333+00:00

Thank you for the clarification—this helps us better understand the constraints you’re operating under.

Given your requirement to function strictly at the infrastructure level, without the ability to execute scripts or enforce configurations within the guest OS, I’d like to highlight an important platform boundary.

From an Azure Virtual Machines standpoint, application lifecycle management inside the VM is not exposed to the Azure platform. Azure manages the VM’s infrastructure lifecycle (start, stop, deallocate, resize), but it does not have visibility into or control over applications running within the guest operating system.

As a result, there is currently no native Azure capability that can guarantee applications will be gracefully stopped prior to deallocation or automatically restarted after a resize purely from outside the VM, without some level of in-guest configuration or cooperation.

In such scenarios, one practical approach is to distribute workloads across multiple VMs behind a load-balancing layer so that traffic can be redirected while individual VMs are being resized, helping maintain overall availability.

You can refer to the documentation here: https://dori-uw-1.kuma-moon.com/en-us/azure/load-balancer/load-balancer-overview

Another approach is to consider using Azure Virtual Machine Scale Sets, which provide built-in support for rolling updates and instance-level fault tolerance. This helps reduce the impact of infrastructure operations like resizing by handling instances in a controlled manner.

You can refer to the documentation here: https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machine-scale-sets/overview

Additionally, this aligns with Azure reliability best practices from Microsoft, where workloads are expected to handle infrastructure-level events such as restarts or re-deployments with minimal impact. In this context, it is the responsibility of the workload or application owners to ensure that their applications are designed to tolerate restarts or recover automatically.

You may refer to the following guidance for more details:

https://dori-uw-1.kuma-moon.com/en-us/azure/well-architected/reliability/principles

https://dori-uw-1.kuma-moon.com/en-us/azure/reliability/reliability-virtual-machines

https://dori-uw-1.kuma-moon.com/en-us/azure/well-architected/service-guides/virtual-machines

1 answer

Your answer

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.

Answer 1

Sree Aravind M hi & thx for using Q&A platform )

so back to urs question... this is not Azure problem, this is guest OS problem. Azure just stops the VM like pulling power. it has zero idea whats running inside, so if apps dont auto start they stay dead after resize. expected

there is no universal “graceful stop all apps” button bc every VM is different. What people usually do either enforce app-level restart logic like

systemd services for linux

windows services / scheduled tasks

docker with restart=always

so after boot everything comes back automatically, or u handle it yourself before resize :) Run or Custom Script to execute inside VM

stop apps gracefully (docker stop, systemctl stop, etc)

then deallocate

after start run another script to bring everything back

basically u orchestrate it. If u wanna do it properly at scale use something like

Azure Automation / Runbooks

or your own agent inside VM

so flow becomes

call script inside VM graceful shutdown

deallocate + resize

start VM

call script start apps

but yeah key point

Azure wont manage app lifecycle inside VM for u, ever

rgds,

Alex

Share via

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

1 answer

Your answer