AWSCostAWS cost · EC2 right-sizing
How to find idle and oversized EC2 instances draining your bill
Instances get sized for a moment that rarely comes. Someone picked a size at launch to be safe, or provisioned for a peak that was really a guess, and then the instance ran for years at 5% CPU. It works, so nobody looks. But an oversized instance is not a little wasteful - EC2 pricing roughly doubles at each size, so an instance one step too big is paying double for capacity it never touches. This is the same mistake as an over-provisioned RDS instance, just on the compute side.
An EC2 instance idling under 10% CPU is sized for a peak that never comes, and EC2 pricing doubles at each size - so one size too big is paying roughly double for headroom it never uses. Check CloudWatch CPU over a few weeks, drop a size where it stays low, and stop anything that is truly idle.
How do I spot an oversized instance?
A few signals in CloudWatch tell you almost everything:
| Signal | Verdict | Action |
|---|---|---|
| Average CPU under 10% | Oversized | drop a size and watch it |
| Peak CPU never above 40% | Oversized | headroom you are paying for and not using |
| Low CPU and low memory | Right-size down | a smaller type does the same job |
| Zero network, no logins for weeks | Idle - stop it | possibly nothing is using it at all |
Why do instances end up oversized?
Because picking a bigger size feels safe and costs nothing today. Nobody gets blamed for an instance that never runs out of headroom; they do get blamed if it falls over under load. So the default is to over-provision and move on. The bill never complains, the instance never errors, and the extra capacity quietly bills every hour for years. It is waste that comes from caution, not carelessness - which is exactly why it survives.
How do I find and fix them?
Pull the average CPU for an instance over a few weeks. If it sits low, drop it a size - stop the instance, change the type, start it again, and watch the same metric for a week. This reads the average CPU over a window you set; lots of idle headroom means the instance is oversized. AWS Compute Optimizer will also recommend a target size from the same data:
# average CPU for one instance over a window (edit id and dates)
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 --metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--start-time 2026-06-08T00:00:00Z \
--end-time 2026-07-08T00:00:00Z \
--period 86400 --statistics AverageRight-size first, then commit. Once an instance is the right size and steady, a Savings Plan or reservation discounts the compute you were going to run anyway - never the other way around.
Want to know which of your instances are oversized - and what dropping a size would save? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
How do I know if my EC2 instance is oversized?+
Check CloudWatch CPUUtilization over a few weeks. If the average sits under 10% and even the peaks stay low, the instance is bigger than the workload needs. Consistently low CPU with low memory pressure is the clearest sign you can drop a size and still have comfortable headroom.
How much do I save by right-sizing an EC2 instance?+
Roughly linear with the size. EC2 pricing doubles with each step up in a family, so dropping one size - say m5.2xlarge to m5.xlarge - cuts that instance's compute cost by about half. On an always-on instance that is hundreds to thousands of dollars a year for a change that takes minutes.
What is the difference between idle and oversized?+
Oversized means the instance does real work but has far more capacity than it uses - right-size it down. Idle means nothing is really using it at all - no traffic, no activity for weeks - in which case the fix is to stop or terminate it, not shrink it.
How do I right-size an EC2 instance?+
Confirm low utilization in CloudWatch, pick the next size down (or a better-fit family), stop the instance, change the instance type, and start it again. It is a brief restart, not a migration. Then watch the same metrics for a week to confirm the smaller size holds up.
Does AWS tell me which instances are oversized?+
Yes - AWS Compute Optimizer analyzes your CloudWatch metrics and recommends right-sizing across EC2, with a suggested instance type and the estimated saving. It is free to enable and a good starting point, though you should sanity-check its picks against how the workload actually behaves.
Should I right-size or reserve first?+
Right-size first, always. Reserving or buying a Savings Plan on an oversized instance just locks in a discount on waste. Get the instance to the right size, confirm it is steady, and only then commit to it.
Related cost breakdowns
Why EKS is expensive: the $73/month control plane
Every EKS cluster bills $0.10/hour - about $73/month - for the control plane before a single node runs, and $0.60/hour once it falls out of standard support. Idle and forgotten clusters are pure waste.
Why your stopped EC2 instance is still being charged
A stopped EC2 instance keeps billing for its attached EBS disk and any Elastic IP. One 8 GB volume quietly cost me ~$70 over six years. Here is what still charges when an instance is off.
Spot instances: what is safe to run on them, and what is not
Spot instances are up to 90% cheaper than on-demand - I moved almost everything to spot. The catch is a 2-minute interruption notice. Here is what is safe to run on spot and what is not.
Graviton (ARM) is ~20% cheaper than x86 for the same work
AWS Graviton instances cost about 20% less than comparable x86 at equal or better performance, and arm64 Lambda is a one-dropdown switch. Here is how to find migration candidates.