Will CSES staging deployments using InstanceInputEndpoint continue to work after the 15 November 2026 Inbound NAT Pool creation cutoff?

Question

We use Azure Cloud Services (Extended Support) with an unchanged InstanceInputEndpoint in our .csdef.

Cloud Services automatically creates and manages the associated Azure Load Balancer and Inbound NAT Pool. We do not provision or manage the Load Balancer ourselves.

Our release process is:

1. Production CSES deployment is running.
2. When releasing, we create a new staging CSES deployment using the same .csdef, including the unchanged InstanceInputEndpoint.
3. We test staging.
4. We perform a VIP swap.
5. We delete the old staging deployment so that we do not pay continuously for two Cloud Services deployments.

Azure advisory MVY2-NQ0 states that creation of new Inbound NAT Pools will no longer be permitted starting 15 November 2026.

Cloud Services (Extended Support), however, remains supported until 31 March 2027.

Could the Cloud Services (Extended Support) and Azure Load Balancer product teams please confirm:

Will creating a new CSES staging deployment containing an existing/unchanged InstanceInputEndpoint remain supported between 15 November 2026 and 31 March 2027?

Specifically:

• Does the 15 November 2026 prohibition on creating new Inbound NAT Pools apply to NAT Pools created internally by Microsoft.Compute/cloudServices?
• Is CSES exempt from that creation restriction through its retirement date?
• Will a new staging CSES resource using InstanceInputEndpoint continue to provision successfully after 15 November 2026?
• Can customers continue the documented create-staging → VIP-swap → delete-old-staging workflow through 31 March 2027?

Keeping both production and staging CSES deployments permanently provisioned before 15 November would approximately double our compute cost for the remaining lifetime of the service, so we need confirmation whether that workaround is actually required.

This question concerns only Microsoft-managed Load Balancer/NAT Pool resources created by Cloud Services (Extended Support), not customer-created Azure Load Balancers.

Advisory tracking ID: MVY2-NQ0

Could this please be confirmed with the relevant CSES / Azure Load Balancer product group rather than answered solely from the generic NAT Pool migration documentation?We use Azure Cloud Services (Extended Support) with an unchanged InstanceInputEndpoint in our .csdef.

Cloud Services automatically creates and manages the associated Azure Load Balancer and Inbound NAT Pool. We do not provision or manage the Load Balancer ourselves.

Our release process is:

1. Production CSES deployment is running.
2. When releasing, we create a new staging CSES deployment using the same .csdef, including the unchanged InstanceInputEndpoint.
3. We test staging.
4. We perform a VIP swap.
5. We delete the old staging deployment so that we do not pay continuously for two Cloud Services deployments.

Azure advisory MVY2-NQ0 states that creation of new Inbound NAT Pools will no longer be permitted starting 15 November 2026.

Cloud Services (Extended Support), however, remains supported until 31 March 2027.

Could the Cloud Services (Extended Support) and Azure Load Balancer product teams please confirm:

Will creating a new CSES staging deployment containing an existing/unchanged InstanceInputEndpoint remain supported between 15 November 2026 and 31 March 2027?

Specifically:

• Does the 15 November 2026 prohibition on creating new Inbound NAT Pools apply to NAT Pools created internally by Microsoft.Compute/cloudServices?
• Is CSES exempt from that creation restriction through its retirement date?
• Will a new staging CSES resource using InstanceInputEndpoint continue to provision successfully after 15 November 2026?
• Can customers continue the documented create-staging → VIP-swap → delete-old-staging workflow through 31 March 2027?

Keeping both production and staging CSES deployments permanently provisioned before 15 November would approximately double our compute cost for the remaining lifetime of the service, so we need confirmation whether that workaround is actually required.

This question concerns only Microsoft-managed Load Balancer/NAT Pool resources created by Cloud Services (Extended Support), not customer-created Azure Load Balancers.

Advisory tracking ID: MVY2-NQ0

Could this please be confirmed with the relevant CSES / Azure Load Balancer product group rather than answered solely from the generic NAT Pool migration documentation?

Answer 1

Hi @Nariman-4775

Honest answer up front: nobody on this forum can give you the binding confirmation you're asking for, and you're right that this needs the product group. But here's what the public record actually says, because it sharpens your escalation.

The retirement docs never mention CSES. The official wording frames the whole thing as retiring "the Virtual Machine Scale Sets-specific feature of Inbound NAT rules V1", with creation blocked from November 15, 2026, and all guidance is about upgrading VMSS to NAT rules V2. Whether the creation block applies to pools created internally by Microsoft.Compute/cloudServices is simply not documented anywhere.

What makes your question fair: there's precedent for a CSES carve-out. For the Basic Load Balancer retirement, Microsoft published an explicit FAQ saying CSES existing and new deployments were not impacted and could keep creating Basic LBs. The default outbound access retirement got a similar CSES exemption. No such statement exists for the NAT pool cutoff, and an undocumented exemption is not something to bet your release pipeline on.

So, how to get it confirmed in writing:

1. Open a support ticket under Cloud Services (Extended Support), reference advisory tracking ID MVY2-NQ0, paste your four questions as written, and explicitly ask for product group confirmation recorded in the case. Do it now, you have about 8 weeks.
2. Open the ticket from the advisory itself in Service Health, so the tracking ID context rides along.
3. Keep this thread alive too. It's well written for moderator escalation to the PG, and the tracking ID is visible.

One extra risk worth flagging: since CSES was deprecated in March 2025, creation of new CSES resources is already blocked in some scenarios (people get "BadRequest: Cloud Services (extended support) will be retired on 31 March 2027" on new creates). Your flow works today, but it rests on new-resource creation staying open for your subscription too, so ask support to confirm that alongside the NAT pool question.

And the pragmatic bottom line: if written confirmation hasn't arrived by mid-October, assume the conservative case. Either provision the staging deployment before November 15 and eat the cost, or pull your migration forward, since CSES ends March 31, 2027 regardless and this cutoff only moves your real deadline by four months.

References: https://learn.microsoft.com/en-us/azure/load-balancer/inbound-nat-rules https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-basic-upgrade-guidance