Azure VMs averaging over 80% CPU or 90% memory for 30 days that need a larger size
What does ZopNight detect here?
Azure VMs that average above 80% `Percentage CPU`, or use more than 90% of memory by `Available Memory Percentage`, over 30 days are saturated rather than efficient. ZopNight flags them for an upsize to the next larger size in the same family. The finding is a performance recommendation with no saving; the larger size costs more.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-262 |
| Category | performance |
| Severity | medium |
| Metric | Percentage CPU / Available Memory Percentage |
| Threshold | CPU average above 80% or memory used above 90% |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | Microsoft.Compute/virtualMachines/read · Microsoft.Insights/Metrics/Read |
Where it applies
Saturation has a cost too
Rightsizing usually means shrinking, but a VM pinned near its limits is also mis-sized. Sustained high CPU queues work, stretches response times and leaves no room for a spike, and when available memory runs low the guest starts paging or killing processes. The bill does not show that cost; the users of the application do.
Measuring a VM’s load over a month
az monitor metrics list \ --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm> \ --metric "Percentage CPU" "Available Memory Percentage" \ --aggregation Average --interval PT1H --offset 30dAvailable Memory Percentage reports free memory, so memory in use is 100 minus that value.
Either threshold is enough
- The VM is running.
Percentage CPUaveraged over the last 30 days is above 80%, or memory in use (100 minus the averageAvailable Memory Percentage) is above 90%.- The VM has a positive monthly price, which is shown on the finding for context.
The finding says which limit was crossed, CPU, memory or both, with the measured values.
When there is no upsize advice
If ZopNight has no Percentage CPU series for the VM, the rule does not run, even when memory
data exists. A VM with no memory metric can still be flagged on CPU alone. Stopped or deallocated
VMs are skipped. The rule looks at averages, so a VM that only spikes to 100% for a few minutes each
hour will not be flagged; short bursts are better handled by autoscaling than by a bigger size.
The opposite situation, a VM that is mostly idle, is covered by Idle Azure VM.
No saving, by design
The saving is $0 and the cost after the change is shown as unchanged. In practice the next size up costs more; the recommendation is about keeping the workload healthy, and the price difference is yours to weigh against the performance problem.
Resizing to the next size up
- Review CPU and memory in Azure Monitor and rule out a runaway process or a missing index as the real cause.
- List the sizes the VM can move to:
az vm list-vm-resize-options --resource-group <rg> --name <vm> -o table. - Resize:
az vm resize --resource-group <rg> --name <vm> --size <larger-size>. - Confirm the application’s response times and error rates improve.