EC2 rightsizing means matching each instance to the capacity its workload actually uses, instead of the size someone picked at launch. AWS Compute Optimizer gives you a free, data-driven starting point by analyzing CloudWatch metrics and recommending better-fit instance types. Used well, it turns guesswork into a ranked list of safe moves; used blindly, it can recommend cuts that cause slowdowns. This walkthrough is how we use it on engagements.
This article links up to our complete guide to AWS cost optimization, the pillar for this cluster. Rightsizing is the first move in the Cut step of our See, Cut, Lock, Run method, and it is where the first chunk of our 31 percent average reduction usually comes from. Critically, it must happen before you buy any commitment, a point we make in Savings Plans vs Reserved Instances.
A Savings Plan or Reserved Instance bought on an oversized fleet locks the waste in for one to three years. Rightsize first, then buy the rate against the smaller, true footprint. Sequence is what makes the saving stick.
Step 1: Turn on Compute Optimizer and let it gather data
Compute Optimizer is free to opt into and analyzes the CloudWatch metrics it already has for your EC2 instances and Auto Scaling groups. It needs a window of data to produce confident recommendations, so enable it across your accounts through AWS Organizations and give it time to build a profile. By default it reads CPU, memory where the CloudWatch agent reports it, network and disk metrics. If you want it to factor in longer-term patterns such as monthly peaks, enable enhanced infrastructure metrics, which extends the lookback at a small per-resource cost.
The output classifies each instance as under-provisioned, over-provisioned, or optimized, and proposes specific alternative instance types with projected cost and performance. Compute Optimizer also covers EBS volumes, Lambda functions, ECS services on Fargate and RDS, so the same console gives you rightsizing candidates well beyond EC2.
Step 2: Validate the recommendation against real utilization
Treat every recommendation as a candidate, not a verdict. Compute Optimizer does not know your latency requirements, your release calendar, or that a given instance carries a quarterly batch job. Before acting, pull at least two weeks of utilization, ideally a full month, and read the percentiles rather than the average.
An instance averaging 15 percent CPU looks idle, but if it hits 95 percent every weekday morning, the smaller type Compute Optimizer suggests will cause a daily slowdown. We size against the 95th percentile of utilization with headroom on top: target a type where p95 lands around 60 to 70 percent of the new capacity. Memory is the metric teams most often miss, because the default EC2 metrics do not include it until the CloudWatch agent is installed. The broader, cloud-agnostic version of this validation is in rightsizing compute: a step-by-step method.
Step 3: Prefer a newer or better-shaped family over a blunt downsize
Two moves often beat a simple smaller size. First, move to a current instance generation: newer families generally deliver better price-performance, so a same-size move to a current generation can cut cost with no capacity loss. Second, evaluate Graviton, AWS's Arm-based processors, which offer materially better price-performance for many general-purpose and compute workloads, provided your software runs on Arm. Compute Optimizer can surface Graviton recommendations directly. We cover that path in how AWS Graviton cuts compute costs.
Match the shape to the bottleneck. A memory-bound workload on a balanced instance should move to a memory-optimized family, which is often both cheaper and faster for that job than simply buying a bigger balanced instance.
Want the rightsizing done for you?
Our AWS cost audit reads Compute Optimizer and raw utilization across your whole estate, ranks every rightsizing opportunity by dollars, and hands you a safe, prioritized plan. On the performance model, you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Step 4: Resize safely, in reversible increments
The safest resize is staged and reversible. Change one size step at a time rather than jumping several, apply it to a canary or a single instance in an Auto Scaling group first, and watch the same metrics you sized against for a full business cycle before rolling out wider. Note the original type and the change time so a rollback is a one-line action if latency moves. Start with the largest dollar opportunities at the lowest risk, usually oversized non-production and stateless services, and leave databases and stateful systems for a more careful pass.
| Compute Optimizer says | Validate | Action |
|---|---|---|
| Over-provisioned | p95 CPU and memory both low | Downsize one step, canary first |
| Over-provisioned, but spiky | Low average, high p95 spikes | Autoscale rather than fix-size down |
| Optimized, older generation | Current-gen or Graviton available | Move family for price-performance |
| Under-provisioned | p95 near 100% | Size up; do not commit until stable |
Compute Optimizer behavior and instance families above reflect AWS offerings as of May 2026. Verify current generations and recommendations in the console before resizing, as families and pricing change.
The AWS Cost Optimization Field Guide includes the utilization queries and the scoring model we use to rank EC2 rightsizing opportunities by dollars. It is the downloadable companion to this walkthrough.
The short version
Turn on Compute Optimizer, treat its output as a ranked candidate list, validate each one against two weeks of p95 utilization including memory, prefer a newer or better-shaped family over a blunt downsize, and resize in reversible increments with a canary. Do it before you commit, and the savings carry through into every Savings Plan you buy afterward, exactly as in our SaaS on AWS case study. When you want it run across the whole estate at once, that is what our AWS cost optimization service delivers.