How VM Sizing Works

VM Sizing produces a recommendation for every Azure VM and VM Scale Set with enough performance history. This page explains how those recommendations are generated, what data feeds them, and the concepts that show up on the Recommendations page.

Recommendation Lifecycle

Recommendations are pre-computed during each scan, not generated on-demand when you open the page. Every scan refreshes recommendations against the latest performance metrics and your current Scanner Settings, so the page loads instantly and toggle changes don't need to re-query the server.

Setting changes apply on the next scan

Changing aggressiveness or the minimum data window in Scanner Settings doesn't affect existing recommendations until the next scan runs. Trigger a manual scan to apply changes immediately.

VM Sizing never recommends deletion

For safety and reversibility, recommendations only suggest downsizing. Resources that appear completely unused are surfaced separately by Orphaned Resources.

What Data Feeds Recommendations

The recommendation engine sizes against statistical percentiles of observed usage, not averages. This protects against right-sizing for the average and under-sizing for real workload peaks.

CPU: Daily metrics aggregated from Azure Monitor over a rolling window of up to 365 days. Sized against P95 utilization.
Memory: Sized against P99 when at least 100 days of data exist, otherwise P95. Requires the diagnostic agent and memory counters.
Disk IOPS: Daily disk pressure metrics over the same rolling window.
SKU pricing: Pulled from the Azure Retail Prices API in USD. Does not include enterprise discounts.

Workload Profile

Each VM is automatically classified by its observed CPU, memory, and disk usage patterns. The workload profile shapes which SKU families are considered when cross-family recommendations are enabled.

Compute Intensive: CPU is the dominant pressure. F-series and similar compute-optimized families are preferred.
Memory Intensive: Memory pressure dominates. E-series and other memory-optimized families are preferred.
Balanced: No single resource dominates. General-purpose families like D-series fit best.
Burstable: Long idle periods with occasional spikes. B-series is the natural fit, but is opt-in via the toggle on the Recommendations page.
Oversized: Utilization is consistently low across the board. The largest savings opportunities are in this group.

Confidence Score

Every recommendation carries a confidence level — Very High, High, Medium, or Low — that reflects how trustworthy the underlying data is. Confidence is calculated from five factors:

Data sufficiency — how many days of metrics exist for this VM.
Workload stability — whether utilization stays within a predictable band or swings widely.
Resource headroom — how much buffer the recommended SKU leaves between observed peaks and capacity.
Workload pattern — whether the workload has a consistent shape (e.g., business-hours spikes vs. random bursts).
Memory data availability — whether real memory metrics exist or the safety floor is in effect.

Use confidence as a sequencing tool

Filter to Very High and High confidence first when starting a rightsizing initiative. Save Medium and Low confidence recommendations for after you've banked the easy wins.

Aggressiveness

Aggressiveness is a single environment-wide setting that controls how much utilization headroom the engine targets. Higher aggressiveness gives larger savings with less buffer for workload spikes.

Conservative: 70% target utilization. Largest headroom, smallest savings.
Balanced: 80% target utilization. Default. Moderate headroom and good savings.
Aggressive: 90% target utilization. Tightest sizing, maximum savings, least buffer.

No per-VM aggressiveness override

Aggressiveness applies to every recommendation in your environment. To set per-VM tolerance, hide the recommendation for VMs you want to leave alone.

Realized Savings

When a VM is actually downsized, StratoLens records the savings and surfaces them in the Show Resolved view on the Recommendations page. Realized savings are calculated cumulatively against the originally detected SKU and cost, so a VM that's been downsized in two steps shows the full savings from the original SKU, not just the most recent change.

Recommendations require performance history

By default, a VM must run for at least 7 days before its first recommendation is created. Existing recommendations continue to update regardless of how new the data window setting is. To include shorter-running VMs, lower the Minimum Data Window in Scanner Settings.

← Previous: Overview Next: Recommendations Page →