Oversized EC2 instances
Not the idle instance — the one that works while using a third of what it has. The gap between provisioned and used is billed all the same.
What this problem is
An idle instance is easy to argue for shutting down: nobody uses it. An oversized one is a different case — it serves requests, the application depends on it, everything works. What is wrong is the ratio: the machine has four times the CPU the workload consumes, and EC2 bills for what was provisioned, not what was used.
The cause is nearly always the initial sizing. At the start of a project nobody knows what the load will be, so it is chosen with headroom — which is prudent. Then the load settles below the estimate and the type stays as it was, because touching a machine that works requires a reason, and "it works too well" is rarely seen as one.
Stepping down one size in the same family typically halves the price and delivers half the resources. The validation that requires is looking at the peak, not the average: a workload averaging 15% with 70% spikes still needs the headroom; one averaging 15% and peaking at 22% does not.
How we detect it
We list running instances with DescribeInstances and read the average CPU utilization CloudWatch collects, via GetMetricStatistics, across a multi-week window — long enough for a genuine month-end peak to show up.
- Over-provisioned EC2 instances
What it costs
Each step down a family typically halves the price: an m5.2xlarge runs about $280 a month on demand, an m5.xlarge about $140, an m5.large about $70 (us-east-1, Linux).
Public AWS list prices, us-east-1, subject to change. The figure in your report is computed against your resources in your regions.
How it appears in the report
An illustrative example, with invented resources and figures. In the report each finding carries the real resource, its region, and the fix command where a safe one exists.
Does your account have this?
The scan is read-only and shows you what it found before you pay for anything.
Run a free scan