The metric that lies by omission
Open the CloudWatch console for almost any EC2 dev box and you'll see CPUUtilization hovering at 1-3% for hours. Someone on the team will glance at that graph and call the instance idle. Sometimes they're right. Sometimes there's a monitoring agent polling every 60 seconds, a cron job doing a health check, or a background sync process keeping just enough CPU alive to look active without anyone actually using the machine.
The reverse is just as common. An instance running a long compile or a data import will show low CPU in the 5-minute average even though someone is actively waiting on it, because CloudWatch's default granularity smooths over the bursts. A single number sampled every five minutes and averaged is not evidence of anything by itself. It's a hint, and hints need corroboration.
This matters because "idle" is the load-bearing word in most cost-cutting decisions - shut it down, right-size it, schedule it off. If the measurement is wrong, the action is wrong. So before writing any automation that acts on idle time, it's worth building a small script that actually checks idle time properly, using more than one CloudWatch metric, and understanding exactly where that check will still fool you.
