Rightsizing matches a resource's size to its measured use: a smaller instance, fewer nodes, a lower storage or database tier. It changes usage, not rate: the bill falls because fewer units are billed, not because a unit costs less. For the invoice it is the most direct lever a team can pull without finance and without a contract, and also the one whose effect is most often estimated and never proven.

How it works

The decision rests on metrics the provider collects anyway. The hypervisor reports CPU utilisation for every instance, and network and disk throughput with it. Memory it cannot see: it is measured only when an agent runs inside the guest and reports it. A recommendation without a memory metric rests on CPU and network alone.

Three parameters decide what follows from the same metrics. The lookback window sets how many days the analysis reaches back; anything before it does not exist for the tool. The percentile or aggregation sets whether a maximum or an average counts: the maximum in each five-minute interval is more conservative than a daily mean. Headroom is the reserve a workload keeps on purpose so that a peak does not saturate it; it is the owner's decision, not a measurement.

AWS

AWS Compute Optimizer analyses the CloudWatch metrics of the last 14 days once an account opts in, or up to 93 days with the paid enhanced infrastructure metrics preference. For EC2 it uses the maximum utilisation point in each five-minute interval. Memory utilisation is analysed only where the CloudWatch agent is installed or an external observability product supplies it. Each instance receives a finding: under-provisioned when at least one specification does not meet the workload's requirement, over-provisioned when at least one can be sized down and none is too small, optimized when all of them fit; for optimized instances the tool may still suggest a newer generation. A recommendation carries a performance risk from very low to very high and the price difference, and the rightsizing preferences let an organisation set headroom, thresholds and preferred instance families. Beside it sit the rightsizing recommendations in Cost Explorer: they also look back 14 days, classify an instance whose maximum CPU utilisation stays at or below 1 % as idle and recommend termination, recommend a type change above that, and show only recommendations with an estimated saving of zero or more.

Azure

Azure Advisor evaluates virtual machines over the last seven days by default; the window can be set to 14, 21, 30, 60 or 90 days. A shutdown recommendation is raised when the 95th percentile of maximum CPU utilisation is below 3 %, the peak of average CPU over the last three days is at most 2 % and outbound network utilisation is below 2 %; memory is not considered for that decision. A resize recommendation considers CPU, memory and outbound network and targets at most 40 % CPU at the 95th percentile and 60 % memory at the 99th on the new size for user-facing workloads, 80 % for the rest. Advisor recommends smaller sizes in the same family, newer versions and other families, without taking reservations or savings plans into account; the saving rests on retail rates. The resize itself restarts the VM and requires deallocation when the new size is not available on the hardware cluster hosting it.

Google Cloud

Google Cloud produces machine type recommendations through the Recommender from the system metrics Cloud Monitoring collected over the last eight days. CPU values are averages over 60 seconds, so short spikes do not register; the documentation suggests the Ops Agent for more accurate recommendations. VMs from GKE, Dataflow and App Engine flexible environment are excluded, as are VMs with GPUs, TPUs or ephemeral disks and the memory-optimised family. The cost estimate compares the monthly cost of the current and the recommended type before sustained use discounts.

What it means for your cost

The saving is the price difference between the two sizes multiplied by the hours the resource runs; Compute Optimizer calculates it exactly that way. In billing data it appears as the same line with a smaller quantity or a different product, never as a credit. It is proven only when the next invoice shows the line with the new type and the old one has gone; that is the point where a savings opportunity becomes a realised saving.

A commitment changes the arithmetic. Where a Reserved Instance covers the instance, downsizing lowers the bill only if the freed discount applies somewhere else. At AWS, regional Reserved Instances for Linux with default tenancy carry instance size flexibility within the family through the normalisation factor; Cost Explorer assumes a size-flexible reservation keeps covering the smaller instance of the same family and otherwise counts only On-Demand hours. Windows, dedicated tenancy and zonal reservations have no such flexibility. Azure lets reservations be exchanged, with the new reservation carrying at least the remaining commitment of the old one; the documentation states that reservations bought from 1 February 2027 for services that savings plans cover are no longer exchangeable, and earlier ones keep one final exchange. A Savings Plan follows usage, but it too runs empty after a downsize if nothing else fills the committed hour.

Modernisation is the case that touches usage and rate at once: a newer generation does the same work at a lower list price, Compute Optimizer proposes it even for instances it classifies as optimized, and Advisor lists newer versions among its resize targets.

Where it goes wrong

  • Peaks outside the window: the month-end close, the Sunday batch or the campaign fell before the 14 days, and the recommendation knows nothing of them. The symptom is an instance that saturates two weeks after the change.
  • Memory never measured: without an agent the recommendation rests on CPU, so a memory-bound service looks empty and ends up too small.
  • A downsize that breaks a limit: network bandwidth, EBS throughput, attached disks or a licence bound to cores all depend on the size. The platform differences listed with a recommendation are the list to read before the change.
  • Rightsizing before allocation: with no owner nobody accepts the recommendation, and nobody notices when it breaks. The loop starts at allocation, not at the tool.
  • Estimated and never verified: the saving went into the report before the instance was changed and stayed there. A saving exists only on the invoice.
  • Applied without the owner: a low-risk finding is not an approval. Whoever runs the resource decides; the same rule holds for idle and orphaned resources.

Sources

Read on 2026-10-15. AWS What is Compute Optimizer, EC2 instance recommendations and findings, rightsizing recommendation calculations in Cost Explorer, how Reserved Instances are applied and instance size flexibility; Microsoft Advisor recommendations for underutilised VMs, resize a virtual machine, exchange and refund reservations; Google Cloud apply machine type recommendations.