Windows ACI in VNet: 30-min DeploymentTimeout on provisioning + does the private IP persist across restarts?

Hello Pavan Adapala (SONATA SOFTWARE NORTH AMERICA),

Thank you for posting your query at Microsoft Q&A Platform.

In accordance with Alex's observations and continuing the discussion, I would like to provide the following clarification:

For Issue 1, the available information suggests that the deployment timeout was likely encountered during the ACI provisioning stage rather than during container execution. Since an identical deployment succeeded shortly afterward without any configuration changes, this may indicate a transient provisioning condition, such as temporary resource allocation delays or regional capacity constraints. While large Windows-based container images can contribute to longer provisioning times, the successful redeployment without modification suggests that image size alone may not fully explain the observed behavior. Microsoft recommends optimizing container images through techniques such as multi-stage builds and using runtime images instead of SDK images where applicable.

For Issue 2, current Microsoft guidance does not provide a documented guarantee that an Azure Container Instance will retain the same private IP address across lifecycle events. Microsoft explicitly advises against relying on hard-coded ACI IP addresses because a container group's IP may change following restart or recreation events. Therefore, customers should not architect solutions that depend on private IP persistence for ACI workloads.

Based on this guidance, while a private IP may appear unchanged in some scenarios, there is no documented assurance that it will remain stable across container group restarts, stop/start operations, redeployments, or platform-initiated maintenance activities. For workloads requiring a stable backend endpoint, it is recommended to use an abstraction layer such as DNS-based service discovery or consider container hosting platforms that provide more stable ingress patterns.

At this time, we have not identified any Microsoft documentation that guarantees private IP retention for ACI container groups deployed into a VNet subnet.

References:

• Best practices and considerations - Azure Container Instances | Microsoft Learn
• Troubleshoot common issues - Azure Container Instances | Microsoft Learn
• Reliability in Azure Container Instances | Microsoft Learn

If you have any further queries, please do let us know.

If the answer is helpful, please click "Accept Answer" and "Upvote it"

hi Pavan Adapala (SONATA SOFTWARE NORTH AMERICA) & thx for sharing urs issue here at Q&A portal,

the two issues are probably unrelated. For Issue 1, a DeploymentTimeout after exactly 30 minutes usually means the ACI service couldn't complete provisioning, not that your container crashed. Since the same image deployed successfully a few minutes later with no changes, I'd lean toward a transient platform/capacity issue rather than an application problem. Large Windows images can definitely increase provisioning time, so reducing the image size (multi-stage build, runtime instead of SDK, removing unnecessary layers) is still good practice. But if an identical retry succeeds immediately, image size alone probably isn't the root cause. A retry strategy is a good mitigation, and if this becomes frequent in a specific region, it's worth opening a support case so Microsoft can check backend capacity.

For Issue 2, I wouldn't rely on an ACI private IP remaining stable. A container restart inside the existing container group may keep the IP, but there is no documented guarantee that the private IP will survive a stop/start, failed deployment, or platform recreation. If the container group is recreated, you should assume the private IP can change, because of that, using an Application Gateway backend that points directly to an ACI private IP isn't a great long-term design.

If you need a stable backend, I'd consider Azure Container Apps (stable ingress), AKS with a Service, A private DNS-based indirection if it fits your architecture. https://learn.microsoft.com/azure/container-instances/container-instances-vnet

If Microsoft can confirm an official IP persistence guarantee (or lack of one), that would be helpful. Based on the current documentation, though, I wouldn't architect around the private IP remaining unchanged after lifecycle events.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/