Right-size Azure virtual machines before yesterday's peak becomes tomorrow's bill.

Right-sizing means matching each Azure virtual machine to the work it actually does, rather than the size it was first deployed at. Most estates carry VMs picked during a migration or a project peak and never revisited, so they run at a fraction of their capacity while billing at full rate. Right-sizing moves them to a smaller SKU, or shuts down the ones nothing is using.

Collect at least two weeks of CPU, memory, disk and network metrics so a quiet fortnight does not mislead you. Rank instances by the gap between provisioned and used capacity. Pick a candidate SKU in the same family to keep the workload profile predictable. Confirm the change with the application owner, schedule it in a maintenance window, then re-measure after a full business cycle.

Look for sustained low CPU and memory against provisioned capacity, disks far larger than the data on them, and machines with no recent sign-in or session activity. Azure Advisor surfaces some of this. EtherInsights adds the part that usually stalls the work: it names an owner for each candidate and tracks the saving from recommendation through to approval.

The analysis can be fully automated, and it should be, because it is a continuous measurement problem rather than a one off audit. The resize itself is better kept human approved. An automatic downsize on a workload with a seasonal peak or an undocumented dependency is how right-sizing programmes lose the trust of application owners.

Percentile values, not averages. A machine averaging twenty percent CPU can still hit ninety five percent at month end, and an average hides that completely. Use P95 for CPU and memory across a full billing cycle, add disk IOPS and throughput for data workloads, and check network for anything chatty.

Yes, and it is often overlooked because App Service plans are bought once and rarely revisited. Look at the plan tier against actual request volume and memory use, consolidate underused apps onto a shared plan, and scale down non production slots. The method is the same as VMs even though the levers differ.

It depends entirely on how much of the estate was sized during a migration and never reviewed, so a headline percentage is not useful. Measure your own tenant instead. The honest way to size the prize is to rank candidates by monthly cost and only count the ones an owner has agreed to change.

Right-sizing reduces what you consume. Reservations reduce what you pay for the consumption you have committed to. Do them in that order, because reserving capacity you are about to eliminate locks in the wrong baseline for one to three years.

Cloud PCs are sized per licence rather than per machine, so the question becomes which users are on a larger Cloud PC than their work needs, and which are provisioned but not signing in. Review usage per user against the assigned Cloud PC size, then adjust at the licence level. EtherInsights reports Cloud PC usage alongside Azure VM sizing so the two are reviewed together.

Quarterly for a stable estate, monthly if you are actively migrating or scaling. The important part is that it is a standing review with an owner rather than a project. Estates drift back toward oversized within a couple of quarters once the attention moves elsewhere.

Azure's own Advisor recommendations monitor CPU and outbound network usage for seven days and flag VMs running at 5% CPU or less, with 7MB or less outbound network, for four or more days as low-utilisation. That's the underlying signal Microsoft ships by default; the review and owner sign-off around that signal, not the metric itself, is what turns a flagged VM into an approved change.

No, they're complementary. Right-sizing changes the VM's compute tier to match actual usage; Azure Hybrid Benefit reduces the cost of that VM's Windows Server or SQL Server licence by applying licences you already own under Software Assurance. Applying Hybrid Benefit to an oversized VM still leaves the sizing waste in place, so do both, not either.