By Cloudledger · Updated
Most AKS cost is the resources the cluster runs
An AKS bill is largely the node virtual machines, their disks, load balancers, public IP addresses, egress and any monitoring or logging attached to the cluster. Understanding cluster cost therefore means reading the underlying resource meters, not just looking for a single AKS line.
Node pools are the main lever
Node size, count, scaling rules and the split between system and user pools determine most of the spend. Idle capacity from generous minimum counts or oversized nodes is common. Review requests, limits and actual utilization together: a cluster can look busy because of reservations in the scheduler while nodes remain largely idle.
- List node pools with VM size, minimum and maximum counts.
- Compare node utilization with pod requests and limits.
- Review autoscaler settings and observed scaling behaviour.
- Check disks, load balancers and IPs attached to the cluster.
Attributing cost to teams needs labels
Kubernetes does not bill per namespace by default. Attribution usually requires consistent labels, namespace conventions and a cost allocation approach agreed with the platform team. Without it, cluster cost stays a single shared number that nobody can act on.
Logging and egress add up
Container insights, control-plane logs and verbose application logging can produce significant ingestion volume, and cross-zone, cross-region or outbound traffic can add networking charges that have nothing to do with node size. Review these meters alongside compute rather than optimising nodes alone, and check which log categories are actually used during incidents before reducing them.
Optimize with the platform owners
Options include rightsizing nodes, tuning autoscaling, consolidating pools, using appropriate disk types and reviewing log verbosity. Every change affects reliability and deployment behaviour, so involve the team that operates the cluster and validate against the next complete billing period.