A simple way to make AKS clusters more stable—and cheaper—is to separate system and user workloads into different node pools. Running everything on the default node pool often leads to system pods being evicted when app workloads spike, causing unnecessary instability and over-provisioning.

When system and app pods share the same nodes, you risk:

Teams typically see 20–30% savings by right-sizing system nodes and letting user nodes autoscale based on demand.

There’s a peculiar phenomenon that happens in cloud environments: VMs tend to grow, but they rarely shrink.

A project usually starts with the mindset of “let’s provision something safe,” and soon you’re running a Standard_D16s_v5 for a workload that barely touches 15% CPU. Sounds familiar?

The cost impact is where things really start to hurt.

An oversized VM can quietly add far more to your monthly bill than necessary. When this pattern repeats across multiple workloads, the overall cost impact becomes significant, and it quickly raises questions about whether your cloud resources are being used efficiently.

But here’s the real challenge: rightsizing isn’t about randomly downsizing until your bill stops hurting. Done poorly, it leads to performance issues, SLA breaches, urgent messages from application owners, and those unwanted 2 AM escalation calls.

The real art is finding the sweet spot where performance and cost efficiency meet.

Let’s talk numbers:

Take a typical environment with around 50 VMs. If even half of them are oversized by a single tier, you’re wasting close to $7,500 USD every month—that’s $90,000 USD a year. That’s not a small amount; that’s the cost of a full-time senior engineer.

Unlike on-prem hardware that just depreciates quietly in the corner, cloud resources bill you by the hour—730 times each month. Every oversized VM is a recurring decision.

Why do teams overprovision?

Because they are cautious.
Cautious about performance complaints.
Cautious about outages.
Cautious about being the architect who slowed down production.

Is that mindset understandable? Yes.
Is it costly? Very.

So the cost is high, the waste is real, and the reasons behind oversizing are understandable. But cautious provisioning isn’t a strategy—it’s just a reaction. The only way to rightsize confidently is to replace assumptions with data. And that starts with understanding how your workloads actually behave.

Before changing any VM size, it’s important to understand how your workloads actually behave. Azure Monitor and Log Analytics give you the visibility you need to make informed decisions.

Here are the key things to focus on:

CPU utilisation:
This is the obvious starting point, but don’t rely on averages alone. A VM sitting at 20% CPU most of the day might still jump to 80% during batch jobs or peak activity. Those peaks matter.

Memory pressure:
For many applications—especially databases—memory is often more important than CPU. If the VM doesn’t have enough memory, it will fall back to disk more frequently, and performance will drop sharply even if CPU looks fine.

Disk IOPS and throughput:
This is one of the most commonly overlooked areas. In Azure, storage performance is closely tied to VM size. Downsizing a VM may cut your IOPS limit significantly, which can cause issues for disk-heavy workloads.

Network throughput:
Larger VM sizes typically come with higher network bandwidth. If your application depends on frequent or heavy data movement, downsizing could introduce unexpected bottlenecks.

Local/Temporary SSDs:

Local SSDs offer high performance, but their capacity is linked directly to the VM size. When you downsize, the temporary disk may shrink—or disappear entirely. This can be problematic if a workload, such as a database or caching layer, relies on that disk for fast temporary storage. It’s one of the most common oversights during rightsizing.

And finally, don’t ignore the monitoring window.
A week of data may miss monthly processing jobs. A month may miss quarterly spikes. For production workloads, aim to collect at least 30 days of metrics—and ideally cover any known business cycles—to get an accurate picture.

Here’s a practical, step-by-step approach that works well across most environments.

Start with Azure Advisor. It’s the most straightforward place to begin, and while many teams know about it, surprisingly few review its recommendations regularly. Advisor looks at your utilisation patterns and highlights where you may be overprovisioned.

However, take its guidance as a starting point—not the final answer. Advisor uses conservative thresholds (for example, workloads running below 5% CPU or 10% network utilisation over long periods). This helps identify obvious waste but won’t always catch more subtle optimisation opportunities.

To get a clearer picture, build custom Azure Monitor workbooks that track:

This deeper analysis helps distinguish between workloads that are genuinely oversized and those that actually need the resources they currently have.

Not every VM is an ideal target for rightsizing, so it helps to prioritise thoughtfully.

This is where many teams underestimate the effort required. Proper testing is essential and takes time, but it's what ensures you can rightsize with confidence.

For each target VM:

Once testing is complete and you’re ready to proceed:

They’re the most oversized—and the most dangerous to undersize.

Reasons:

Sometimes the right answer is shifting from D-series to E-series, not going smaller.

These scale horizontally better than vertically.

Running three smaller VMs instead of one large one improves resilience—and sometimes lowers cost.

These workloads are perfect for scheduled up/down scaling.

Scale up during nightly jobs → scale down after.
Or move to Azure Batch or Azure Functions for real elasticity.

Rightsizing isn’t a one-time task—it’s a habit. With the right data and a careful approach, you can reduce costs without affecting performance. Start small, validate each change, and make optimisation a regular part of how you run your environment. Over time, these adjustments lead to a leaner, more efficient cloud footprint.

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