Inbound NAT Pools retirement on Azure Machine Learning compute clusters, where the load balancer and scale set are managed by Azure ML

Hello Fabio,

Thank you for the detailed description and for sharing the results of your non-production testing.

We understand your concern regarding the retirement of Azure Load Balancer Inbound NAT Pools and, in particular, Azure Machine Learning compute clusters where the related infrastructure is created and managed by the Azure Machine Learning/Azure Batch service.

Based on the currently available Microsoft documentation, Inbound NAT Pools used with Virtual Machine Scale Sets are scheduled for retirement on September 30, 2027, and the general Azure Load Balancer guidance is to migrate customer-managed configurations to Inbound NAT Rules V2 before the retirement date.

However, your scenario is different because the Azure Machine Learning compute infrastructure relies on a backend Azure Batch service hosted in a Microsoft subscription, and you do not have access to the underlying scale set required to perform the generic NAT Pool migration yourself.

Regarding your specific questions:

1. Will Azure Machine Learning stop provisioning Inbound NAT Pools before September 30, 2027?

The general Load Balancer documentation confirms the retirement and provides migration guidance for VM Scale Sets. However, the public documentation reviewed does not provide an Azure Machine Learning-specific migration date or confirm the exact transition mechanism for Azure ML-managed compute clusters.

Therefore, we do not want to speculate about the Azure Machine Learning service-side implementation or provide a migration date that has not been officially documented.

2. What will happen to an existing Azure ML compute cluster on September 30, 2027?

The Load Balancer documentation confirms that Inbound NAT Pools for Virtual Machine Scale Sets are retiring on September 30, 2027. It does not, however, document the post-retirement behavior specifically for Azure ML-managed compute clusters.

Because the underlying VM Scale Set is service-managed in your scenario, the exact effect on node provisioning and job execution requires Azure Machine Learning engineering confirmation.

3. What about the November 15, 2026 creation restriction?

We understand this is particularly important in your environment because you observed that the existing cluster creates a new load balancer containing Inbound NAT Pools when scaling from zero nodes.

The generic Load Balancer retirement documentation alone is not sufficient to confirm how this creation restriction will be handled for service-managed Azure ML resources. Therefore, we recommend not making production changes based solely on an assumption that the cluster will or will not continue to scale after that date.

This behavior should be confirmed with the Azure Machine Learning engineering/product team.

4. Is a compute cluster with node public IP disabled an appropriate alternative?

Azure Machine Learning supports compute clusters and compute instances with or without a public IP address.

Microsoft documentation states that the no public IP configuration removes the public IP address and load balancer networking resources and does not require inbound traffic from the internet.

Since your testing also shows that a newly created cluster with node public IP disabled doesn't create the load balancer/NAT Pool in question, this can be considered as an architectural option for a new compute deployment.

Before changing the production environment, however, please validate all required outbound connectivity, dependencies, private networking, and job functionality in a non-production environment, particularly given that approximately 180 scheduled pipelines rely on the current cluster.

We would not recommend deleting or manually modifying the Azure ML-managed NAT Pools or associated load balancer resources.

5. What about the existing compute instance?

Your test showing different behavior after recreating the compute instance is useful. However, the general NAT Pool retirement documentation does not state that recreating an Azure ML compute instance is the official migration procedure for this retirement.

Therefore, we would not recommend treating recreation as a required migration step unless Azure Machine Learning-specific guidance confirms it.

Recommended next steps

Please keep the existing production cluster unchanged for now rather than manually deleting or modifying the NAT Pools.

Since you have already reproduced the behavior in a non-production environment, please retain the following information so that the Azure Machine Learning engineering team can correlate the provisioning behavior if required:

Azure ML workspace and region

Compute cluster name

Date/time in UTC when the cluster scaled from zero

Newly created load balancer resource name

NAT Pool names observed after provisioning

Whether node public IP was enabled or disabled

Azure subscription ID

Previous Microsoft support case number, if available

The key outstanding point is an Azure Machine Learning-specific service confirmation regarding how service-managed clusters will transition away from Inbound NAT Pools and how the November 15, 2026 creation restriction will affect scale-from-zero provisioning.

For reference:

Microsoft documentation: Migrate from Inbound NAT Rules V1 to V2

Microsoft documentation: Secure Azure Machine Learning training environments with virtual networks

Microsoft documentation: Configure inbound and outbound network traffic for Azure Machine Learning

Thank you for documenting the scenario and your test results in detail. They are particularly helpful for distinguishing the Azure ML-managed case from a standard customer-managed Load Balancer/VM Scale Set migration.

Best regards,

Anshika