Share via

AKS Fails to provision E4as_v7 but will provision E4as_v6

Alden Haight 0 Reputation points
2026-04-02T15:16:38.59+00:00

"REDACTED cluster information"

NodePool: Custom NodePool requesting Standard_E4as_v7 (4c/32GB), on-demand, capacity-type on-demand, zones 1/2/3

Behavior: Karpenter creates NodeClaims, Azure returns InsufficientCapacityError ("all requested instance types were unavailable during launch"). After repeated failures, Karpenter emits NoCompatibleInstanceTypes. This persisted for 12+ hours with retries every ~3 minutes.

Proof it's not actual capacity: az vm create --size Standard_E4as_v7 --zone 1 and --zone 2 both succeeded immediately in the same subscription and region. The SKU shows no restrictions via az vm list-skus, quota was 0/20 (plenty of headroom).

Workaround: Swapping to Standard_E4as_v6 (same 4c/32GB, same family) provisioned immediately through Karpenter with no issues.

AKSNodeClass: imageFamily: AzureLinux, osDiskSizeGB: 128, no zone pinning

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Ankit Yadav 13,135 Reputation points Microsoft External Staff Moderator
    2026-04-02T16:10:01.3366667+00:00

    Hello Alden Haight,

    The observed Karpenter provisioning failures for Standard_E4as_v7 are an expected Azure behavior and do not indicate a capacity shortfall, quota issue, or AKS misconfiguration.

    AKS node provisioning relies on Virtual Machine Scale Sets (VMSS), which use a more restrictive allocation model than single virtual machines; as a result, it is possible for az vm create to succeed immediately while VMSS‑based provisioning returns transient InsufficientCapacityError, especially when multiple availability zones are requested. Each VM SKU version also has its own independent capacity pool, which explains why Standard_E4as_v6 provisioned successfully despite having identical specifications. This scenario is documented in Microsoft Learn as a normal characteristic of Azure’s capacity management, and the successful fallback confirms platform health rather than instability or reduced Azure reliability.

    References:

    If this helped to clarify your query, please don't forget to click on "Accept Answer" button.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.