Azure Advisor tells you which VM is oversized. It doesn't tell you which one is load-bearing.

01

Azure Advisor may be completely right

This is not an argument against Azure Advisor. It is a useful way to surface waste at scale. A human cannot stare at every CPU chart, every day, across every subscription. Advisor can narrow the field.

But cost recommendations are built from the configuration and utilisation Azure can observe. Business responsibility is not a metric. Neither is the consequence of a bad change.

A VM at 8% average CPU may be oversized. It may also spend most of the month waiting for the two-hour workload that pays for the system. Both statements can be true.

The useful response is not “ignore the tool.” It is “complete the analysis.”

02

What “load-bearing” actually means

A load-bearing VM is not always busy. It is a machine whose failure or slowdown creates a business consequence larger than its apparent infrastructure cost.

That can mean:

• It is the only instance of a customer-facing service.
• It runs payroll, billing, reporting, or regulatory work on a schedule.
• A legacy system, vendor allowlist, fixed IP, or licence is tied to it.
• Other applications call it synchronously and fail when it slows down.
• It holds state that makes replacement slower than the architecture diagram suggests.
• It is spare recovery capacity that has never been labelled as such.

None of those facts makes an oversized VM acceptable forever. They change how you remove the waste. A safe plan may require a second instance, a dependency change, a different schedule, a licence conversation, or a tested recovery route before the size changes.

03

Read the recommendation, not just the saving

I start by recording the current size, proposed size, estimated saving, observation period, subscription, resource group, region, operating system, and recommendation date. Then I check whether the VM is covered by a reservation, Savings Plan, Azure Hybrid Benefit, or another commercial arrangement.

Why? Because a retail-rate saving is not always the saving that reaches the invoice. A resize can change commitment utilisation, software licensing, available disk and network throughput, and what other workloads now consume the unused commitment.

I want the recommendation in the same document as the current cost baseline. That prevents an attractive percentage from floating free of the money actually being paid.

Microsoft documents how Azure Advisor generates cost recommendations. Treat the output as evidence, with a timestamp and assumptions, rather than a permanent truth about the machine.

04

Average CPU is where the review starts, not where it ends

Averages flatten the moment you may care about most.

A VM can sit nearly idle for 29 days and become critical on day 30. It can have low CPU while memory pressure causes paging. It can be limited by disk latency, IOPS, network throughput, queue depth, a single-threaded process, or an application dependency outside the VM.

The observation window must include the business cycle. Fourteen days can be enough for a steady API. It is useless for a quarterly reporting server if the quarter-end run is not inside those fourteen days.

05

Find the person who knows why the VM exists

Tags help. Names help. Architecture diagrams help. None replaces a conversation with the workload owner.

I ask five questions:

1. What business process stops if this VM is unavailable?
2. When does it experience its real peak?
3. Is there another healthy instance or a tested recovery route?
4. Which systems connect to it, and how will they behave during a restart?
5. Who can confirm that the change worked?

If nobody can answer, the risk has not disappeared. It has become undocumented. That may be the strongest reason to investigate before touching the machine.

06

Map what the VM carries before you make it smaller

The resource name rarely tells the full story. Check attached disks, extensions, backup, monitoring, availability configuration, network interfaces, load balancers, DNS, private endpoints, scheduled tasks, licences, and inbound or outbound allowlists.

Then write the failure mode in plain language. Not “potential service degradation.” Write: “The 06:00 invoice batch may miss its bank cut-off,” or “There is no second node, so customers cannot sign in during the restart.”

That sentence changes the quality of the decision. It tells you who must approve the work, when it can happen, what must be observed, and what rollback actually means.

This resource-by-resource context is how the Magrid Azure cost reduction work removed roughly EUR 3,000 from an approximately EUR 4,500 monthly baseline without breaking production. Their CTO could explain what each resource did. The team changed the environment after the workload was understood.

07

Turn the recommendation into a reversible change

Once the evidence supports a resize, define the change before scheduling it.

Test in non-production where the environment is representative. If production is the only place the workload can be proved, reduce the blast radius: change one instance, keep capacity elsewhere, watch the business transaction, and make rollback quick.

If the recommendation exposes dependencies that must be fixed first, that work belongs in a scoped Azure remediation, not in an impulsive cost-cleanup session.

08

Verify the saving and the system

After the resize, watch the same metrics used to justify it. Compare response time, error rate, queue depth, CPU, memory, disk, and network behaviour across a representative period. Confirm the scheduled job, month-end process, or traffic peak still completes inside its real requirement.

Then verify the bill. Check that the resource cost moved as expected and that commitment utilisation or another service did not absorb the difference.

A successful rightsizing change has two outcomes: Azure costs less, and the workload still does its job. If you cannot show both, the work is unfinished. Only after that new baseline is stable should you decide how much to commit; buying Azure Reservations before rightsizing can lock in the overspend.