AKS agent pool never provisions nodes — cluster stuck in "Creating", node resource group (MC_*) stays empty with no error, across all regions and SKUs

Question

AKS agent pool never provisions nodes — cluster stuck in "Creating", node resource group (MC_*) stays empty with no error, across all regions and SKUs

Hansen Huang 0

Summary

On a sponsored Azure subscription, every AKS managed cluster I create brings up the control plane (powerState = Running, valid API server FQDN) but the system node-pool VMSS is NEVER created. The managed/node resource group (MC_*) stays completely empty, the VM-family vCPU usage stays at 0, there are no Activity Log events and no error — the cluster just sits in provisioningState = Creating indefinitely (observed 20+ minutes; with a managed product on top of AKS it sat 70+ minutes).

Direct compute on the SAME subscription works perfectly, so this looks specific to the AKS resource-provider node-provisioning path, not quota or capacity.

What works (isolation tests, swedencentral, same subscription):

Standard_D4s_v6 single VM -> Running in ~90 seconds
Standard_D4s_v6 VMSS + Standard Load Balancer + Public IP -> Succeeded in ~96 seconds

So compute, VMSS, Standard LB, Public IP and quota are all healthy.

What fails (minimal "az aks create", DEFAULT system-assigned identity, AKS-managed VNet, 1 node, no add-ons, nothing custom):

swedencentral, Standard_D4s_v6 -> Creating 20+ min, MC_ RG empty, no error
swedencentral, Standard_D4s_v5 -> Creating, MC_ RG empty, no error
eastus, Standard_D4s_v7 -> Creating, MC_ RG empty, no error
(eastus/uksouth + D4s_v6 are rejected at create time by a region SKU allow-list that only permits *_v7 — a separate finding.)

Re-registering Microsoft.ContainerService did NOT help; a fresh cluster created afterwards hung identically.

Ruled out:

Quota: Dsv6 0/100, Total Regional 0/100 — plenty free
SKU availability: D4s_v6 unrestricted in swedencentral (az vm list-skus)
Azure Policy: only Defender/ASC audit policies; no Deny effect, no deny events
Deny assignments: none at node-RG scope and none at subscription scope
Permissions: failing clusters use the default system-assigned identity
Provider: Microsoft.ContainerService = Registered
Region: fails in swedencentral AND eastus
SKU generation: fails on v5, v6 and v7

Question:

What would cause AKS agent-pool (VMSS) provisioning to never start for managed clusters on a subscription, while the control plane succeeds and direct VM/VMSS provisioning works fine? Could a governed / sponsored subscription have a back-end AKS enablement or compute-governance gate that silently blocks agent-pool creation? How can I get this lifted?

I can share the subscription ID and a reproducible cluster privately with a support engineer if this needs to be escalated to a support case.

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-06-30T02:47:45.03+00:00

Hello @Hansen Huang

I just wanted to follow up, As per your request, I shared the DFM case creation link via private message. Could you let me know whether you’re able to create the DFM case?

Thanks.
Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-07-01T00:47:40.9433333+00:00

Hello Hansen Huang,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Regards.

2 answers

Your answer

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-06-30T02:47:45.03+00:00

Hello @Hansen Huang

I just wanted to follow up, As per your request, I shared the DFM case creation link via private message. Could you let me know whether you’re able to create the DFM case?

Thanks.
Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-07-01T00:47:40.9433333+00:00

Hello Hansen Huang,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Regards.

Answer 1

Hansen Huang 0

Hi Sina, thanks for the confirmation — and sorry for the slow reply, I've been travelling for work this week.

I did as you advised: kept a stuck cluster as a live repro, and az aks operation show-latest shows the create LRO frozen at percentComplete=1.0 (InProgress, no error), with the MC_* node RG empty. This is still reproducing — it's not resolved yet.

A Microsoft moderator shared a DFM link, so I'm opening the Microsoft.ContainerService case now. Once the AKS engineering team investigates and comes back with their findings, I'll share the result here for the community.

Thanks again for the guidance.

Best,

Hansen

Manasa Akula 770 Reputation points Microsoft External Staff Moderator

2026-07-07T01:02:46.6933333+00:00

Hello Hansen Huang,

Thanks for the information.

Could you let me know whether the DFM case has been created? If yes, please share the caseid through Private message, so I can track it internally.

Regards,
Manasa.

Answer 2

Hello Hansen Huang,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your AKS cluster control plane is created, but the system node pool never provisions and the MC_* node resource group remains empty.

With the available information, the root-cause direction is an AKS resource-provider or subscription-governance provisioning block before AKS submits the child VMSS deployment. Because direct VM and VMSS creation works in the same subscription, this is not proven to be raw Compute quota or general VMSS capacity. AKS also has its own quotas, SKU restrictions, and regional availability rules separate from basic Compute tests.

The reliable resolution is to keep one reproducible stuck cluster, collect the AKS long-running operation details, prove that the node resource group is empty, confirm no visible Azure Policy/provider/quota block exists, and open an Azure support case via your Portal or contact Priority Customer Support - (PCS) for Microsoft.ContainerService backend investigation. Microsoft documents az aks operation show-latest for inspecting AKS long-running operations, and AKS support escalation is the correct path when documented troubleshooting does not expose the cause.

AKS node resource group and managed infrastructure:
https://learn.microsoft.com/azure/aks/node-resource-group-lockdown
AKS managed identities and permissions:
https://learn.microsoft.com/azure/aks/managed-identity-overview
https://learn.microsoft.com/azure/aks/aks-service-permissions
AKS quotas, SKU restrictions, and region availability:
https://learn.microsoft.com/azure/aks/quotas-skus-regions
AKS operation status and long-running operation handling:
https://learn.microsoft.com/cli/azure/aks/operation
https://learn.microsoft.com/azure/aks/manage-abort-operations
AKS troubleshooting and support:
https://learn.microsoft.com/troubleshoot/azure/azure-kubernetes/welcome-azure-kubernetes
https://learn.microsoft.com/azure/aks/aks-support-help

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

Hansen Huang 0 Reputation points

2026-06-29T01:28:21.9533333+00:00

Thanks Sina.

az aks operation show-latest on a reproducible stuck cluster: percentComplete=1.0, status=InProgress, error=null, endTime=null — the LRO sits at 1% indefinitely, no error, no timeout. Node RG stays empty (VMSS=0). Reproduced on 6+ minimal clusters; direct VM/VMSS work. Owner role, no policy/deny/locks. Opening a Microsoft.ContainerService case for back-end investigation. Subscription ID via private channel.
Sina Salam 30,566 Reputation points Volunteer Moderator

2026-06-30T14:30:50.6966667+00:00

Hi @Hasen

Based on the evidence provided, this is unlikely to be a quota, capacity, VM SKU, networking, RBAC, or Azure Policy issue because standalone VM and VMSS deployments succeed in the same subscription, regions, and SKUs. As your az aks operation show-latest output shown.

The empty MC_* resource group indicates that the AKS Resource Provider is not progressing to the managed node pool VMSS deployment stage. This points to a Microsoft.ContainerService backend provisioning issue or a subscription-specific AKS entitlement/governance restriction requiring AKS engineering investigation.

What I can recommend is to keep one affected cluster in the stuck state, collect the latest AKS operation details, subscription ID, cluster Resource ID, creation timestamps, and evidence that the node resource group remains empty, then open a Microsoft.ContainerService support case for backend analysis. At this stage, only the AKS service team can review the internal Resource Provider telemetry and determine why node provisioning is not being initiated. https://learn.microsoft.com/azure/aks/aks-support-help

I hope this helps. Please let us know the outcome from the AKS support investigation, as it will help confirm whether the issue is caused by a subscription-level AKS backend restriction or a Resource Provider provisioning failure.

Cheers