Rightsizing Recommendations in Cost Explorer

TL;DR: Cost Explorer has a free Rightsizing Recommendations tab (Cost Management → Recommendations → Compute) that compares each EC2 instance's 14-day CloudWatch utilization against its size and returns one of three verdicts — right-sized, downsize, or terminate — each with a dollar figure and a target type. It's the closest tool (already enabled and populated), not the deepest (Compute Optimizer is that). Its one big trap: without the CloudWatch Agent it sees only CPU, so a memory-bound box at 8% CPU / 90% RAM looks downsizable and breaks when you act.

The numbers

• Data source: last 14 days of CloudWatch — CPU always; memory/disk only with the CloudWatch Agent installed.
• Three verdicts: right-sized (skip), downsize (one or more sizes — the bread and butter, from prod boxes idling at 10–20% CPU), terminate (so idle it shouldn't exist — forgotten test/dev boxes).
• vs Compute Optimizer: CE is EC2-only, 14-day, conservative within-family; Compute Optimizer covers EC2/EBS/Lambda/Fargate/ASG, up to 93 days (Enhanced), and recommends modernization (m5→m6i/m7i, Graviton). Both free — CE for the quick scan, CO for the deep dive.
• Field examples: a 38-instance SaaS recovered $1,440/mo ($17k/yr) from a 90-min audit (4 terminates + 5 downsizes); a lift-and-shift fleet oversized "for safety" downsized 19 of 22 flagged boxes for $3,800/mo ($46k/yr); 47 forgotten dev sandboxes flagged for termination, 31 killed for ~$2,400/mo.

Do this

1. Open the tab and sort by estimated monthly savings descending — the top rows are where the dollars are.
2. Verify memory data exists before trusting a downsize — no CloudWatch Agent means the recommendation is CPU-blind; install the Agent fleet-wide via SSM Run Command (or bake it into the AMI) and re-run after two weeks.
3. Prefer "one size down" over "three sizes down", pilot on non-prod first, and downsize prod in a maintenance window (it needs a stop/start) with the original type written down for rollback.
4. Validate terminate candidates by who logs in and what traffic they serve — the finding is a signal to investigate, not to delete.
5. Make it a quarterly recurring ticket owned by a real person — one hour, top 5, one Saturday window; the reason it never gets done is that nobody owns it.

Gotchas

• Memory-blindness is the headline risk — JVM apps, Redis/Memcached, and DBs with big buffer pools all look idle on CPU alone and break when downsized.
• 14-day lookback misses cycles — a month-end close job idle from the 1st–14th can be flagged "terminate"; the tool also doesn't know weekend traffic is intentionally low.
• Burstable t-family confuses it — "low CPU" may just be living within baseline credits; check CPUCreditBalance before downsizing.
• Savings assume on-demand list price — RI/SP-covered resources save less than shown, and the number doesn't include additional savings from moving to SPs, Spot, or newer families.

Skip this if

• You need broader or deeper coverage (RDS/EBS/Lambda/Fargate, modernization, longer lookback) — go to Compute Optimizer.
• Your fleet is locked to instance-type-specific Reserved Instances that would strand a discount on downsize — prefer flexible Compute Savings Plans so you can rightsize freely first, then commit. And rightsize before committing — locking discounts onto oversized capacity is a real mistake; catch stragglers with the Trusted Advisor Low Utilization EC2 check.