Explanation
Why the waste happens and who it affects.
Detailed monitoring switches those metrics to 1-minute granularity, and each metric EC2 sends is then billed at the CloudWatch custom metric rate for every instance, prorated by the hour. It is often switched on fleet-wide through launch templates, legacy launch configurations, AMI-baking pipelines or IaC modules, including for development, batch and test instances where nobody looks at 1-minute data.
The per-instance cost is small, but it applies to every instance for every hour it runs, so large or high-churn fleets pay a steady premium. Launch configurations created with the AWS CLI enable detailed monitoring by default, which is one way it spreads unnoticed. AWS's CloudWatch cost guidance says to enable detailed monitoring only when necessary. The main legitimate need is Auto Scaling groups with scaling policies, where AWS recommends 1-minute metrics for faster response to load.
Billing model
The pricing dimensions that drive this cost.
- Basic monitoring
- 5-minute EC2 metrics (1-minute status checks) sent to CloudWatch at no charge
- Detailed monitoring metrics
- Each 1-minute EC2 metric is billed as a custom metric per metric-month, in the same volume tiers as other custom metrics
- Hourly proration
- Detailed monitoring charges accrue only for hours in which the instance sends metrics
- No storage charge
- EC2 detailed monitoring is charged per metric sent, with no separate data storage charge
How to detect
4 checks to find it in your estate.
- Run describe-instances and list running instances with Monitoring.State set to enabled, grouped by account, environment tag and Auto Scaling group
- Check launch templates (Monitoring.Enabled) and launch configurations (InstanceMonitoring.Enabled) for detailed monitoring turned on, remembering that CLI-created launch configurations default to enabled
- Use the Cost and Usage Report query from the CloudWatch cost guide filtering line_item_operation MetricStorage:AWS/EC2 to list instances generating detailed monitoring charges
- For each group with detailed monitoring, confirm whether a scaling policy, alarm or dashboard actually uses 1-minute EC2 metrics
How to fix
4 ways to remove the waste.
- Turn off detailed monitoring with unmonitor-instances (or Manage detailed monitoring in the console) on instances where 5-minute metrics are enough, such as non-production, batch and steady-state instances
- Update launch templates to Monitoring Enabled false and move Auto Scaling groups off launch configurations with detailed monitoring; existing instances keep their setting until replaced, for example by instance refresh
- Keep detailed monitoring for Auto Scaling groups whose step or simple scaling policies need 1-minute data, and when switching a group to basic monitoring update its alarms to a 300-second period
- Set the default to basic monitoring in IaC modules and AMI launch tooling so detailed monitoring becomes an explicit opt-in
Documentation
Vendor references for pricing and configuration.