Confused by AKS costs on an idle cluster? Learn why ’empty’ doesn’t mean ‘free’ and get three actionable strategies from the trenches to slash your Azure bill.

Why Is My “Empty” AKS Cluster Costing Me Money? A Senior Engineer’s Guide

I remember a junior engineer, let’s call him Alex, frantically messaging me on a Monday morning. “Darian, the dev cluster bill is climbing, but I swear I deleted all my deployments on Friday!” He was right; a quick kubectl get pods -A showed nothing but the system essentials. His app was gone, but the Azure cost meter was still happily spinning. This isn’t a bug or a misconfiguration; it’s a fundamental misunderstanding many of us have when we start with managed Kubernetes. You’re not paying for your pods; you’re paying for the virtual machines that are ready to run your pods.

The “Why”: Your Cluster Is Never Truly Empty

When you spin up an Azure Kubernetes Service (AKS) cluster, you’re not just getting a Kubernetes API. You’re provisioning real, tangible infrastructure in your Azure subscription. The biggest culprit for cost is the Node Pool. A node pool is just a set of virtual machines (VMs). Even a single-node cluster is, at its heart, one VM running 24/7.

That VM isn’t sitting idle, either. It’s running critical Kubernetes system pods in the kube-system namespace. Things like:

• coredns: For service discovery and DNS within the cluster.
• konnectivity-agent: To provide a secure tunnel from the control plane to your nodes.
• azure-cni-networkmonitor: For managing the networking layer.
• And several others…

So, even if you delete every single one of your own applications, these system components still need a VM to live on. That VM has a CPU, RAM, and a managed OS disk, and you’re billed for every second it’s in a “Running” state. That’s the ghost cost Alex was seeing.

Pro Tip: Remember the AKS Control Plane itself. While Azure offers a ‘Free’ tier, any production-grade cluster on the ‘Standard’ tier (which you should be using for its Uptime SLA) incurs a small hourly fee for the managed control plane. This is separate from your node costs and is often overlooked.

So, how do we fight back and get our costs under control, especially for non-production environments? Here are three strategies I use regularly, ranging from a quick fix to a full architectural shift.

Solution 1: The After-Hours Fix (The ‘Stop’ Button)

This is the simplest and most direct way to stop the bleeding. If you have a dev or test cluster that’s only used during business hours, just turn it off. AKS has a built-in feature to “stop” the cluster, which effectively deallocates all the VMs in your node pools.

When you deallocate a VM, you stop paying for the compute costs. You’re still paying for the attached managed disks (which is minimal), but you’ve just eliminated 95% of the cost.

How to do it:

It’s a single Azure CLI command. To stop your cluster:

az aks stop --name dev-webapp-cluster --resource-group rg-project-alpha

And to start it back up the next morning:

az aks start --name dev-webapp-cluster --resource-group rg-project-alpha

This is a fantastic, pragmatic solution for individual developer sandboxes or team-shared dev clusters. You can easily wrap these commands in a simple runbook or a scheduled pipeline to automate the process.

Solution 2: The Architect’s Approach (Right-Sizing & Scaling to Zero)

If you need your cluster to be available 24/7 but your workloads are bursty, stopping it isn’t an option. The next step is to architect for cost efficiency. This means ensuring your cluster can scale down to the bare minimum required.

The key here is to use multiple node pools and the cluster autoscaler.

1. System Node Pool: This pool is dedicated to running only the critical kube-system pods. You can keep it small (e.g., 1-2 nodes) and use a cheaper VM SKU like a Standard_B2s.
2. User Node Pool(s): This is where your applications run. You can configure the autoscaler on this pool to scale down to zero nodes when there are no pods scheduled on it.

When you delete your last application, the user node pool autoscaler will see it’s no longer needed and terminate the VMs. Your cluster remains “on” and ready, but you’re only paying for the tiny system node pool.

How to do it:

When creating a new node pool for your apps, you enable the autoscaler and set the minimum count to zero.

az aks nodepool add \
    --resource-group rg-project-alpha \
    --cluster-name dev-webapp-cluster \
    --name userpool \
    --node-count 1 \
    --min-count 0 \
    --max-count 5 \
    --enable-cluster-autoscaler

Warning: Be careful with this! If your system node pool is too small or has taints that prevent your user pods from scheduling there temporarily, scaling a user pool to zero might cause issues when you try to deploy something new, as there might be a delay while a new node is provisioned.

Solution 3: The “Nuke & Pave” (IaC Purist’s Method)

This is the most aggressive option, but it’s also the most effective for guaranteeing zero cost. Instead of leaving a cluster running, you treat it as completely ephemeral. When you’re done, you don’t stop it; you destroy it.

This approach is only feasible if your entire cluster definition and application deployment process is managed with Infrastructure as Code (IaC) tools like Terraform or Bicep, and your deployments are automated with CI/CD pipelines.

The workflow looks like this:

1. A developer needs a test environment for a new feature branch.
2. A pipeline runs, executing a terraform apply to build a brand new, dedicated AKS cluster.
3. The pipeline then deploys the application to that cluster.
4. Once testing is complete, the developer triggers another pipeline (or it runs on a schedule) that executes terraform destroy.

The entire infrastructure, from the cluster itself to the VNet and public IPs, vanishes without a trace. The cost is zero. This is a “hacky” solution for a dev sandbox but is the gold standard for automated integration testing environments.

Solution	Cost Savings	Effort	Best For
1. The Stop Button	High (Compute only)	Low	Dev/Test clusters used during business hours.
2. Architect’s Approach	Medium to High	Medium	Shared environments with unpredictable workloads.
3. Nuke & Pave	Maximum (100%)	High (Requires mature IaC/CI/CD)	Automated testing, ephemeral preview environments.

Ultimately, there’s no single right answer. For Alex’s problem, we started with Solution 1, scheduling the cluster to stop every evening. As his team’s needs grew, we evolved to Solution 2. The key is understanding that “empty” is never free, and actively choosing the cost management strategy that best fits your workflow.

---

🤖 Frequently Asked Questions