Oversized EC2 instances are one of the most common and easiest to fix sources of cloud waste, and also one of the easiest to get wrong. This guide walks through how AWS Compute Optimizer generates right-sizing recommendations, how to evaluate and apply one safely, and where the native workflow starts to break down once you're managing more than a handful of instances.
TLDR
- AWS Compute Optimizer generates EC2 right-sizing recommendations from CloudWatch utilization metrics. It's free, built into every AWS account, and a reasonable place to start.
- Each recommendation carries a performance risk rating and a migration effort estimate. Read both before acting, not just the suggested instance type.
- Resizing an EC2 instance requires a stop and restart, so plan for a short window of unavailability unless the workload runs across multiple instances behind a load balancer.
- Compute Optimizer looks at CPU, memory (if the CloudWatch agent is reporting it), and network utilization in isolation. It has no view of what the instance actually does, which dependencies call it, or how much risk your team is willing to accept, so treat its output as a starting point for review, not an instruction to execute.
- At scale, across hundreds or thousands of instances, the manual review-and-apply cycle is what breaks first, not the recommendations themselves.
What EC2 right-sizing means
Right-sizing is matching an instance's type and size to what its workload actually uses, rather than what it was provisioned for. Instances are commonly oversized because of conservative initial sizing, a workload that shrank after a migration or refactor, or a size that made sense at launch and was never revisited. The fix is usually straightforward once the oversizing is confirmed: move to a smaller instance size or a more efficient instance family with the same vCPU and memory ratio the workload needs.
How AWS Compute Optimizer works
Compute Optimizer reads CloudWatch utilization data (CPU utilization by default, plus memory if the CloudWatch agent is installed and reporting it, and network and EBS throughput where relevant) over a rolling lookback window, and compares actual usage against the instance's provisioned capacity. When usage sits well below what the current instance type provides, it recommends a smaller size or a different family with a closer match.
Each recommendation includes two things worth reading before the suggested instance type itself:
- Performance risk: an estimate of how likely the workload is to hit a resource constraint on the recommended size, based on historical peaks, not just averages.
- Migration effort: how much work the change requires, since moving within the same instance family is a straightforward resize, while moving across families or architectures (for example, to Graviton) can involve compatibility testing.
Step 1: Enable Compute Optimizer and let it collect data
Compute Optimizer needs a baseline period of utilization history before its recommendations are reliable. A newly launched instance, or one that just went through a deploy or a traffic change, won't have enough history yet for the tool to draw a confident conclusion. Let it run before acting on early recommendations.
Step 2: Read the recommendation, not just the headline number
The suggested instance type is the least useful part of the recommendation on its own. Check the performance risk rating against your own tolerance for the workload (a batch job and a customer-facing API don't carry the same risk budget), and check whether historical peaks, not just the CloudWatch average, are already accounted for. A workload with a predictable end-of-month spike can look over-provisioned nine days out of ten and still need the capacity on day ten.
Step 3: Apply the resize safely
Changing an EC2 instance type requires stopping the instance, changing the instance type, and starting it again, which means a short window where that instance is unavailable. For a single instance behind no load balancer, plan the change during a maintenance window. For a workload running across multiple instances in an Auto Scaling group, resize by updating the launch template and cycling instances through the group instead, so there's always capacity serving traffic. After the change, verify the instance is healthy and confirm the new utilization pattern looks like what the recommendation predicted, not just that the instance came back up.
Where Compute Optimizer's analysis stops
Compute Optimizer is a reasonable starting point and it's free, built into every AWS account. Its limits show up as the environment grows:
- It scores CPU, memory, and network utilization in isolation. It has no context for what the instance does, which services depend on it, or whether it's safe to touch without a broader look at the architecture around it.
- Reviewing and applying recommendations one instance at a time works for a handful of instances. It doesn't scale to an environment with hundreds or thousands of them, and nothing in the native workflow batches similar-risk recommendations or routes them to the engineer who owns the resource.
- It's EC2-only. It has nothing to say about unattached EBS volumes, idle load balancers, unused NAT gateways, or oversized resources on other services, all of which typically account for more total waste than oversized compute alone.
- There's no verification step. Compute Optimizer tells you what to change; it doesn't confirm what the change actually saved once the new bill arrives.
Where automated detection changes the process
This is the point where a lot of teams reach for a dedicated tool instead of the console. PointFive's DeepWaste engine covers this with 500+ deep detections across cloud, data, and AI, right-sizing included, with root cause analysis and ownership built into every finding, and ships new detections weekly. Deployment is agentless and read-only, and any remediation, including a right-sizing change, requires human-in-the-loop approval before it runs. For teams that want the fix generated rather than written by hand, agentic remediation produces engineering-grade output: automated pull requests, one-click deployment, and IDE-native remediation prompts through an MCP server, so the change lands as a reviewable diff in the same workflow the team already uses instead of a manual console edit.
Frequently asked questions
Is AWS Compute Optimizer enough, or do I need a third-party tool?
Compute Optimizer, alongside AWS Cost Explorer (free, built into every AWS account) and AWS Trusted Advisor (some checks free, more in the Business support tier), is a reasonable starting point. They tend to become difficult to maintain once an environment spans many accounts and instance types, at which point the manual review-and-apply cycle, not the recommendation quality, is usually the bottleneck.
How do I find unused EC2 instances, not just oversized ones?
An idle instance and an oversized one are different problems. Compute Optimizer addresses the second. Finding the first, along with unattached EBS volumes and other unused resources, needs usage validated over a sustained period rather than a single check, so a resource serving a monthly batch job or a rare failover isn't flagged as safe to remove.
What's the best way to automate rightsizing recommendations and apply them safely?
Automate the low-risk end of the distribution, an instance that's shown consistent, sustained underutilization with no historical spikes, and keep a human in the loop for anything with real performance risk or business criticality attached. The safest automated workflows verify the change against actual billing outcomes afterward, rather than assuming the recommended saving materialized just because the resize was applied.
The bottom line
AWS Compute Optimizer is a solid, free starting point for EC2 right-sizing, and worth turning on regardless of what else is in your stack. Its ceiling is reach and context, not accuracy: it only looks at EC2, it has no view of what an instance actually does, and reviewing recommendations one at a time doesn't hold up past a few dozen instances. Past that point, the process needs cross-service coverage, ownership routing, and verification against the real bill, not just a better recommendation engine.
Methodology
This guide draws on public AWS Compute Optimizer documentation and PointFive product documentation. For corrections, reach out at pointfive.co/contact.