What it observes
Recommendations are based on how each VM has actually been used over a recent window of time, not on a single snapshot. CostGraph looks at:
It considers both typical usage and peaks. A VM that is quiet most of the day but busy at certain times is sized for the busy times.
Enough data first
CostGraph only makes a recommendation when it has enough good data to stand behind it. This is the usual reason a VM has no suggestion. If any of these checks fails, the VM shows no recommendation and CostGraph tells you why:- The agent has reported for long enough. Gaps or a recently installed agent mean there is not yet enough history.
- All the metrics it needs are present.
- The current price of the VM is known, so the saving can be calculated.
- The metrics make sense together. Readings that contradict each other are treated as unreliable rather than acted on.
How it sizes a VM
CostGraph works out how much CPU and memory the VM really needs, then adds headroom so normal peaks still fit comfortably. Bursty workloads, very small instances, and hosts affected by noisy neighbours get extra headroom. Memory is sized to cover the highest usage observed plus expected growth, and never below what the VM has actually used.The recommendation it makes
A cheaper instance safely fits the VM’s needs and passes every safety check. For example, it keeps the same CPU architecture, the saving is worthwhile, and it never jumps from a large instance to a tiny one.
Only when sustained pressure is detected and the VM genuinely needs more capacity than it has. CostGraph then picks the cheapest instance that resolves the pressure.
The VM is confirmed idle (see below). The estimated saving is its full monthly cost.
The current shape is safe and nothing cheaper passed the safety checks, or a risk signal blocks a downsize without proving more capacity is needed.
Any pressure signal blocks a downsize. CostGraph will never recommend shrinking a VM that shows IO wait, CPU steal, contention, swapping, or out-of-memory kills.