AKS Cost Optimisation: The Engineering Levers That Deliver Real Savings

The AKS Cost Problem

Azure Kubernetes Service clusters are commonly over-provisioned. Organisations provision for peak load, don't implement autoscaling, and run expensive VM SKUs for workloads that don't require them.

The result is clusters running at 20–35% average utilisation — paying for significant capacity that delivers no value the majority of the time.

The good news: AKS provides more cost engineering levers than almost any other Azure service. Used well, they can reduce cluster costs by 40–60% without impacting reliability or performance.

Lever 1: Node Pool Architecture

Most AKS clusters are over-simple: one or two node pools, one VM SKU, all workloads co-located. A cost-optimised node pool architecture separates workloads by profile:

• System node pool — Small, reserved for Kubernetes system components. B-series VMs are typically appropriate.
• General purpose node pool — Standard D-series VMs for most application workloads
• Memory-optimised pool — E-series for memory-intensive workloads (databases, caching)
• Spot pool — Low-priority spot instances for fault-tolerant, interruptible workloads

This separation enables right-sizing at the workload level and creates the foundation for spot instance adoption.

Lever 2: Spot Instances

Spot instances (low-priority VMs) provide up to 90% cost reduction compared to Pay-as-you-Go pricing. The trade-off is eviction risk — spot VMs can be evicted with 30 seconds notice when Azure needs capacity.

The engineering solution is to run only eviction-tolerant workloads on spot pools:

• Batch processing
• CI/CD agents
• Development and testing workloads
• Stateless microservices with redundancy

Well-architected applications can run significant portions of their workload on spot, dramatically reducing cluster costs.

Lever 3: Cluster Autoscaler

The cluster autoscaler dynamically adjusts node count based on pending pod demand. Without autoscaler, clusters provision for peak load and waste capacity at off-peak times.

With autoscaler correctly configured, clusters scale down during low-demand periods (overnight, weekends) and scale up only when workload demand increases. For most enterprise workloads, this alone delivers 20–30% cost reduction.

Key configuration decisions: minimum and maximum node counts, scale-down delay, and utilisation threshold. Default configurations are often too conservative — tuning for your specific workload profile is important.

Lever 4: Vertical Pod Autoscaler (VPA)

Kubernetes pods are commonly allocated resource requests significantly above their actual consumption. VPA automatically adjusts pod resource requests based on actual usage, enabling the scheduler to pack workloads more efficiently onto nodes.

VPA is not appropriate for all workloads — pods with spiky, unpredictable resource consumption may be disrupted by VPA-driven eviction. But for stable workloads, VPA-enabled right-sizing consistently reduces cluster compute requirements.

Lever 5: Reserved Instances

Once cluster baseline utilisation is understood (post-autoscaling), reserved instances for the consistent baseline compute deliver 30–50% cost reduction compared to Pay-as-you-Go.

The key is not to reserve before right-sizing. Reserve after autoscaling and right-sizing are in place — then the reservation covers the actual sustained baseline, not an over-provisioned estimate.

Lever 6: Workload Scheduling

Node affinity and pod topology spread constraints can be used to consolidate workloads onto fewer nodes during low-demand periods, enabling the autoscaler to scale down more aggressively.

This is advanced optimisation — appropriate for organisations with mature AKS operations — but can deliver meaningful additional savings.

Putting It Together

A typical AKS cost optimisation engagement follows this sequence:

1. Baseline current utilisation (compute, memory, storage)
2. Implement autoscaler with appropriate configuration
3. Introduce node pool segmentation and spot pools
4. Deploy VPA for stable workloads
5. Right-size reservations based on post-optimisation baseline

The result: 40–60% cost reduction, maintained reliability, and a cluster architecture that scales efficiently with demand rather than sitting idle waiting for peak.