Sizing an AKS Cluster often feels like packing for a holiday when you don’t quite know what the weather will be like. Pack too light, and you’ll be unprepared when conditions change. Pack too heavy, and you end up carrying unnecessary baggage - which, in cloud terms, translates directly into wasted cost.

After working with dozens of organisations deploying AKS in real production environments, one thing becomes clear: while every workload is different, the mistakes people make during sizing are remarkably consistent. More importantly, there are repeatable patterns you can use to make sizing decisions with far more confidence than guesswork.

Before jumping into VM SKUs, node counts, or autoscaling thresholds, it’s worth stepping back and clarifying what an AKS cluster really is.

At its core, an AKS cluster is a fleet of virtual machines - called nodes - working together to run containerised workloads. Each node is a worker with a finite amount of CPU and memory. Your applications, packaged as containers, are the jobs those workers need to execute.

Sizing an AKS cluster, then, is not about picking “the right number” upfront. It’s about answering two fundamental questions:

Once you frame sizing this way, the problem becomes far more practical - and far less intimidating.

Start with what you’re actually running. Each containerised application - running in a Kubernetes pod - consumes CPU and memory. A simple web frontend might need 0.5 vCPU and 512 MB RAM, while a data-processing service could require 2 vCPUs and 4 GB RAM.

In Kubernetes, this is expressed using resource requests. Requests define the minimum guaranteed resources for a pod and are the only values used by Kubernetes for scheduling decisions. When the scheduler decides which node can run a pod, it evaluates requests only - not limits.

You can optionally define limits, which cap how much CPU or memory a pod may consume at runtime. Limits are enforced after the pod is scheduled and do not increase schedulable capacity, so they do not factor into cluster sizing.

A typical web application pod might define:

For sizing purposes, these are the only numbers that matter.

If you run 20 replicas of this pod, the cluster must provide at minimum:

This is the baseline capacity required just to schedule these pods - before accounting for system overhead, headroom, or failures.

Running a production workload on a single node is like having only one person in the organisation who knows how to perform a critical task. When they’re on leave - or worse, unavailable without notice - work simply stops.

AKS nodes are no different. They will fail: during platform maintenance, kernel upgrades, VM reboots, scaling events, or plain bad luck. Designing for availability means assuming failure as a normal condition, not an exception.

For production workloads, applications should be spread across at least three nodes. This ensures that when one node disappears, the remaining nodes can continue to serve traffic without interruption.

This is where cluster sizing quietly shifts from capacity planning to resilience planning.

Let’s say your traffic profile requires 10 replicas of a pod to operate comfortably under normal conditions. If you spread those replicas evenly across three nodes and one node fails, you immediately lose roughly a third of your capacity.

To survive that failure without degradation, you need spare headroom.

In practice, that means:

Those extra replicas aren’t waste - they’re insurance. They absorb node failures, rolling upgrades, and sudden load spikes without forcing emergency scaling or customer-visible impact.

High availability is not achieved by Kubernetes alone.
It’s achieved by over-provisioning with intent.

If your cluster only has enough capacity to run exactly what you need in the happy path, it is not highly available - it is fragile.

In AKS, resilience comes from:

Anything less is optimism dressed up as architecture.

Applications never stay static. Traffic grows, features expand, and data volumes increase. If you size only for today, you’re already behind.

A cluster running at ~70% utilisation is healthy.
At ~95%, you’re one spike away from an incident.

Plan for how your application grows:

Rule of thumb:
Size AKS for comfort, not survival. If the cluster is always “just enough,” failure is only a matter of time.

Let’s walk through a realistic AKS sizing example for an e-commerce platform.

CPU
(10×0.5) + (15×1) + (5×2) + (3×4) = 42 vCPUs

Memory
(10×0.5) + (15×1) + (5×4) + (3×8) = 64 GB

Using Standard_D8s_v5 (8 vCPU, 32 GB RAM):

CPU is the limiting factor, so 7 nodes would technically satisfy the requirement.

But this is where experienced AKS design diverges from “just enough math” -
and where a better approach emerges.

A common AKS anti-pattern is building a single, uniform cluster and hoping it works for every workload. It rarely does.

Using multiple node pools lets you match workloads to the hardware they actually need. Think of it like building a team of specialists instead of expecting everyone to be a generalist. You get better performance, higher efficiency, and lower cost - all at the same time.

Different workloads stress different resources. AKS lets you reflect this reality directly in your architecture.

Separating workloads into node pools gives you:

The system node pool deserves special attention. This pool runs critical Kubernetes components like CoreDNS, metrics-server, and cluster monitoring agents. These aren't your application workloads - they're the infrastructure keeping everything running.

System workload characteristics:

Microsoft's Official Sizing Guidance:

The key factor is cluster complexity, not just node count. A 20-node cluster running Istio service mesh with advanced monitoring needs more system capacity than a 50-node cluster running basic workloads.

Strategy for Our E-Commerce Example

≈ $2,236

This setup prioritises system stability, clean workload isolation, and cost efficiency - appropriate for a production-grade AKS cluster with predictable traffic and standard observability requirements.

For workloads that can tolerate interruptions, Azure Spot instances are one of the biggest cost levers available in AKS. They can deliver up to 90% savings compared to on-demand VMs.

The trade-off is simple: Azure can reclaim a Spot VM with as little as 30 seconds’ notice when capacity is needed elsewhere. If your workload is designed for that reality, the savings are absolutely worth it.

Spot works best for workloads that are interruptible by design:

These workloads expect restarts. Spot just makes those restarts cheaper.

Spot is a bad fit for anything that assumes continuity:

If losing a node causes customer impact, Spot is the wrong tool.

Those background jobs handling imports, exports, and data processing?
They’re ideal candidates for Spot.

By running that node pool on Spot instances, the cluster saves ~$780 per month on that pool alone - without touching availability or user experience.

Spot isn’t a gamble when used correctly.
It’s deliberate architectural leverage.

One of the most common AKS sizing mistakes is provisioning for absolute peak load 24/7. Real workloads don’t behave that way. Traffic fluctuates throughout the day, e-commerce spikes during sales, and batch workloads ramp up and down on demand. Clusters sized permanently for peak are simply wasteful.

The smarter approach is to size for baseline load - normal daily traffic - and rely on auto-scaling to absorb spikes.

AKS provides multiple layers of elasticity:

Instead of running 10 nodes for peak capacity all month (~$1,400/month), size for a 4–5 node baseline (~$560–$700/month) and let auto-scaling handle bursts.

If peak load occurs only 20% of the time, the average monthly cost settles around ~$850/month - roughly 40% savings - while still delivering full performance during peaks.

This is where the headroom you build into initial sizing matters. That 20% buffer becomes the elastic space auto-scaling uses to respond quickly, without risking instability.

Auto-scaling turns capacity planning from a worst-case guess into a demand-driven model.

Sizing an AKS cluster is about balancing performance, reliability, cost, and growth. There’s no single right answer - different applications need different setups.

You don’t need to get it perfect on day one. You just need to avoid getting it wrong.

Start conservative, not minimal. A few well-sized nodes are better than one huge node or many tiny ones. Use node pools to separate workloads. Turn on autoscaling from the start. Use Spot instances for background or batch work. Monitor closely in the early months.

Most importantly, remember this: cloud infrastructure is not fixed. You can resize, scale, and adjust as you learn. Watch basic signals like CPU and memory, and also the quieter ones like IP usage and disk performance.

Good AKS sizing isn’t guesswork - it’s iterate, observe, adjust.

The goal is simple: reasonable costs, stable systems, and users who never notice the platform underneath.

If you found this useful, tap Subscribe at the bottom of the page to get future updates straight to your inbox.