Production EC2 instances still on 5-minute metrics
What does ZopNight detect here?
Detailed monitoring moves an EC2 instance from 5-minute to 1-minute CloudWatch metrics for roughly $2.10 per month (7 instance metrics at $0.30 each). ZopNight flags running production instances with it disabled, and deliberately keeps quiet about dev and test boxes, where paying for finer metrics rarely makes sense.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-151 |
| Category | compliance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | ec2_detailed_monitoring.go |
Where it applies
What changes at 1-minute resolution
By default the metrics EC2 sends to CloudWatch land at 5-minute intervals. That is fine for capacity trends and poor for incident forensics: a 90-second CPU spike that caused an outage may not even be visible after 5-minute averaging. Detailed monitoring raises the resolution to 1 minute, which also lets autoscaling and alarms react roughly five times sooner, since they evaluate fresher data.
A recommendation that costs money to accept
This is one of the few findings where the fix increases the bill: about $2.10 per instance per month, which is 7 EC2 metrics at CloudWatch’s $0.30 per metric per month. That is exactly why the finding carries no savings figure, and why it is scoped to production instances only.
The production filter, precisely
Nagging a throwaway test box to spend more on monitoring is noise, so the rule suppresses itself when an instance looks non-production: a dev/test-shaped name or a dev/test environment tag. An explicit production environment tag overrides both signals and keeps the instance eligible. This gate exists because of real data: in one production account audit, 71 of 122 raw findings landed on uat, sit and perftest instances, and the filter removed all of them.
Read the current state
aws ec2 describe-instances \ --filters Name=instance-state-name,Values=running \ --query 'Reservations[].Instances[].[InstanceId,Monitoring.State,Tags[?Key==`Name`]|[0].Value]' \ --output tableThe middle column showing disabled is the same state discovery records; the rule
fires only on a confirmed disabled and abstains when the monitoring state was not
captured at all.
What it will not tell you
Nothing is said about stopped instances. And the rule cannot tell you whether your alarms actually exploit the finer resolution. Enabling detailed monitoring without tightening alarm evaluation periods buys data, not faster reactions. That second step is yours to take after the switch is on.