What triggers this finding
A running EC2 instance on a large size (xlarge and above) with average CPU between 0% and 20% over the last 30 days, where a smaller instance type is available.
Typical fix
Downsize to the recommended instance type. Paid plans include a CLI script to modify the instance type — review warnings and schedule a maintenance window first.
Example savings
The difference between current and recommended instance pricing — often 25–50% of instance cost.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
What the size step is worth
Within an EC2 family the on-demand rate scales linearly with size: a m5.2xlarge costs exactly twice a m5.xlarge, which costs exactly twice a m5.large. That linearity is what makes this finding arithmetic rather than judgement. Parsivex looks up the current type and the next size down in the same family, and reports the difference — around half the instance's compute cost, every time.
The estimate covers compute only. EBS volumes are attached to the instance, not to its size, so they bill identically before and after; if the instance carries 2 TB of gp3 the storage line does not move at all. Data transfer is unaffected too. On a machine with a large disk, halving the instance type can be a much smaller percentage of the total than the headline suggests, which is worth checking before the change is sold internally as a 50% cut.
Only one step is ever proposed. If a m5.8xlarge is running at 3% CPU, this finding recommends m5.4xlarge and nothing further — Parsivex will re-evaluate against the new baseline on the next scan rather than proposing a four-step drop on a single month of data.
The band this finding occupies
Three conditions have to hold together. The instance must be on a large size — xlarge or above — its 30-day average CPUUtilization must fall below 20%, and a next size down has to exist in the same family. That last condition is narrower than it sounds: the right-sizing map covers m5, c5, r5, and t3, so a large instance in an unmapped family produces no finding.
There is also a floor, and it comes from an adjacent detector. Idle EC2 claims anything under 5% average CPU first, and the two detectors deliberately do not overlap. An oversized finding therefore describes an instance running between roughly 5% and 20% — busy enough to be doing real work, too quiet for the capacity it holds. An instance below that band is not a right-sizing candidate; it is an idle one, and the recommended action is different.
aws cloudwatch get-metric-statistics --namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-07-13T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Average Maximum
When the CPU average is the wrong measure
Average CPU is a poor proxy for whether an instance is correctly sized, and this is the finding where that matters most.
- Memory-bound workloads. An in-memory cache or a JVM with a large heap can hold 90% of its RAM while burning 8% of its CPU. Halving the instance halves the memory too, and the failure mode is an out-of-memory kill rather than a slowdown.
- Single-threaded work. One saturated core on a 16-vCPU instance reports 6% average utilization. The instance is at its limit on the only dimension that matters, and the next size down has fewer cores, not slower ones.
- Bandwidth ceilings. Network throughput and EBS-optimized bandwidth are provisioned per instance size. A host moving large volumes of data may be sized for its pipe.
- Headroom bought deliberately. A 30-day average conceals the quarter-end peak. Check the maximum column before acting on the average.
- Licensing tied to vCPU count. Some commercial software is licensed per core, and the licence cost may already have been paid for the current shape.
Changing the instance type
An instance type change is not an online operation. The instance has to be stopped, modified, and started again, which means real downtime measured in minutes and a set of side effects worth planning for: instance-store data is discarded, an auto-assigned public IPv4 address is replaced, and the instance may land on different underlying hardware.
The change itself is reversible — the same stop, modify, start cycle takes you back to the original type — so the risk is in the interruption rather than in the decision. What is not automatically reversible is drift. If the instance was created by an Auto Scaling group, a launch template, Terraform, or CloudFormation, the console change lives only until the next deploy or scale-out, at which point the original size returns and the finding comes back. Change the definition, not just the instance, or the saving lasts exactly one release cycle.
Before scheduling the window, confirm the target type is available in the instance's Availability Zone and that it supports the same virtualization and networking attributes — most steps within m5, c5, r5, and t3 do, but the check is cheap and the failed start is not.