Trusted Advisor — Low Utilization EC2 Instances

TL;DR: Most EC2 fleets carry a tail of instances doing nothing — the dev box from a finished project, the Jenkins runner replaced by GitHub Actions, the Windows VM someone RDP'd once. Trusted Advisor's Low Utilization check is the list of suspects (<10% CPU and <5 MB network on 4+ of the last 14 days), not a list of "delete these." It's blunt and CPU-only, so it's the start of a conversation — stop, schedule, terminate, or rightsize — where only you know which. Pair it with Compute Optimizer before acting.

The numbers

• Trip wire: <10% daily CPU and <5 MB network I/O on ≥4 of 14 days — intentionally low, so a flagged instance was mostly idle for most of two weeks.
• The estimate is a signal, not a quote: it uses on-demand list price, so RI/SP-covered instances save less (near zero short-term), Spot instances save less, and instances with big attached storage save more than shown.
• Three verdicts: stop (idle now, used again — pay storage only), terminate (no future — take an AMI first if unsure), downsize (steady but oversized — Compute Optimizer gives the target type). When in doubt, stop first, terminate later.
• Field examples: 12 forgotten dev instances = $1,420/mo (~$17K/yr), 9 terminated + 3 scheduled; a mislabeled "production" m5.large zombie (service moved to Fargate 6 months prior) = $852/yr after snapshot-and-terminate.

Do this

1. Triage the list in three passes: by environment tag (dev/test/staging → stop or terminate), then a 90-day stale check via CloudTrail last-login (untouched → terminate after AMI), then hand real workloads to Compute Optimizer for rightsizing.
2. Schedule, don't moralize, dev/test idle — tag Schedule=BusinessHours and use AWS Instance Scheduler / EventBridge to stop at 7 PM, start at 7 AM weekdays (~75% compute cut); a manual one-time stop just re-flags in 14 days.
3. For "production" that looks idle, ask why — over-provisioned headroom (rightsize), spiky batch averaging to ~0 (move to Lambda/Fargate/Spot), or a zombie whose service already migrated (terminate). "It's production, don't touch" is how a $200/mo box runs for years doing nothing.
4. Take an AMI before terminating anything you might recreate — an AMI is cents/month; recreating a setup from scratch costs hours.
5. Refresh the check after acting (24h auto-refresh, or manual) and add an instance-ownership review to a recurring ops meeting.

Gotchas

• CPU-only blindness: GPU workloads show 0% CPU but 100% GPU; a cache serving small in-VPC payloads shows low network but is vital — verify against app logs.
• Burstable t2/t3/t4g are meant to idle — low average CPU may be correct sizing for an event-driven service; check the burst pattern before acting.
• 4-of-14 means new instances (<4 days) won't appear yet.
• RI/SP coverage skews the dollar math — the gross estimate isn't your net savings; the freed capacity moves to wherever the commitment re-applies.

Skip this if

• You need what to change to, not just what's underutilized — go to Compute Optimizer (the analytical engine behind this) or Rightsizing Recommendations in Cost Explorer.
• The instances are dev/test flagged repeatedly — the structural fix is EC2 Instance Scheduling, not repeated manual stops. When rightsizing anyway, consider Graviton for ~20% more, and commit the survivors with Compute Savings Plans. Parent: Trusted Advisor Cost Optimization.