Unexpected AKS node pool scaled to 8 D8lds v6 nodes – need root cause investigation

Matt Farrell 0 Reputation points
2026-08-09T16:29:15.6533333+00:00

I have been directed here by Azure Billing Support after trying to obtain technical assistance with this issue.

This currently appears to be my only available route to request a technical investigation. I have attempted to open an Azure Technical Support ticket through the Azure Portal against the affected AKS cluster, but after completing the automated diagnostics I am only presented with documentation and Microsoft Q&A. I cannot find any option that allows me to actually submit a technical support case.

The automated AKS diagnostics all pass, but this does not address my issue because I am not reporting a current cluster health problem. I need assistance investigating a historical and unexpected scaling event.

My AKS environment unexpectedly reached approximately 8 D8lds v6 nodes, despite the application having effectively no meaningful user traffic. This resulted in substantial unexpected Azure costs.

I have already been working with Azure Billing Support regarding the resulting charges. I have specifically asked them for help establishing how this scaling occurred, but they advised that their team does not have visibility into the resource-level Activity Logs, deployment history, autoscale events or other diagnostics necessary to determine the cause. They therefore instructed me to seek assistance from Azure Technical Support.

As I currently cannot find a way to open that technical support ticket through the Azure Portal, I am posting here in the hope that someone can either assist with the investigation or help escalate this to the appropriate Azure/AKS technical support team.

I need to establish:

  • When the node pool increased to approximately 8 nodes.
  • What triggered the scaling.
  • Whether AKS Cluster Autoscaler was responsible.
  • What the configured minimum and maximum node counts were at the time.
  • Whether pending pods, resource requests/limits or scheduling problems triggered the scaling.
  • Whether a deployment, ARM/Bicep configuration, CI/CD process or other automation changed the node pool.
  • Which user, service principal, managed identity or process initiated any relevant changes.
  • Why D8lds v6 instances were being provisioned.
  • Whether Activity Logs, deployment history, VMSS events or autoscaler logs can establish a timeline of what happened.

As soon as I became aware of the unexpected costs, I immediately began scaling the resources down and subsequently stopped the entire environment. The application is currently offline specifically to prevent any further costs.

I am not simply looking for general advice on configuring AKS autoscaling in the future. I need help establishing the root cause of what already happened, ideally with a documented technical explanation, both so that I can prevent it from happening again and because the findings are relevant to an ongoing Azure Billing Support review.

If this requires access to subscription-level information that cannot be investigated through Microsoft Q&A, could someone please help me get this escalated to the appropriate Azure technical support team?

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.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jose Benjamin Solis Nolasco 12,036 Reputation points Volunteer Moderator
    2026-08-10T00:41:53.4233333+00:00

    Hello @Matt Farrell I hope you are doing well,

    Welcome to Microsoft Q&A.

    Based on your description, this requires a resource-level investigation rather than general AKS troubleshooting. The key point is to determine whether the node increase was caused by Cluster Autoscaler, a deployment/configuration change, or another automation process.

    Following this guide we should fine the root cause:

    I recommend reviewing the following for the period when the unexpected scaling occurred:

    Azure Activity Log – look for AKS/VMSS write operations and identify the initiating user, service principal, or managed identity.

    AKS Cluster Autoscaler logs – determine whether pending pods or resource pressure triggered the scale-out.

    AKS node pool configuration – verify the minCount, maxCount, and autoscaler settings at that time.

    Deployment history / Azure Resource Graph – check whether ARM/Bicep, CI/CD, or another automation changed the node pool.

    VMSS Activity Log – confirm when the D8lds v6 instances were created and what initiated the operation.

    Is important to check what cause this :

    1. The timestamp when the node pool scaled to ~8 nodes.
    2. Whether Cluster Autoscaler initiated the scale-out.
    3. The minCount/maxCount configuration at that time.
    4. Any ARM/AKS node-pool update operations.
    5. The identity that initiated any configuration change.
    6. VMSS/node provisioning events and the reason for the D8lds v6 SKU allocation.

    Reference

    If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.

    Was this answer helpful?

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.