The most surprising thing about EC2 detailed monitoring is that it’s not actually "detailed" in the way you might expect; it’s simply faster metric reporting, and it costs extra.
Let’s see it in action. Imagine you’ve got a web server on EC2. You’re watching its CPU utilization. By default, CloudWatch reports metrics like CPUUtilization every 5 minutes. This is "basic" monitoring.
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--start-time 2023-10-27T10:00:00Z \
--end-time 2023-10-27T10:05:00Z \
--period 300 \
--statistics Average \
--dimensions InstanceId=i-0123456789abcdef0
This might give you output like:
{
"Datapoints": [
{
"Timestamp": "2023-10-27T10:05:00Z",
"Average": 15.5,
"Unit": "Percent"
}
],
"Label": "CPUUtilization"
}
You’re getting a single data point for that 5-minute window. Now, you want to see what happened in the last minute to catch a brief spike. That’s where detailed monitoring comes in.
To enable it, you use the EC2 API or AWS CLI. It’s an attribute of the instance itself.
aws ec2 modify-instance-attribute \
--instance-id i-0123456789abcdef0 \
--detailed-monitoring '{"State": "enabled"}'
This command tells the EC2 service to start sending metrics for this specific instance to CloudWatch every minute. The State parameter is either enabled or disabled.
Once enabled, the same get-metric-statistics command, but with a different --period value, will show you the faster reporting.
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--start-time 2023-10-27T10:00:00Z \
--end-time 2023-10-27T10:01:00Z \
--period 60 \
--statistics Average \
--dimensions InstanceId=i-0123456789abcdef0
Now, you’ll get a data point for each minute:
{
"Datapoints": [
{
"Timestamp": "2023-10-27T10:01:00Z",
"Average": 12.1,
"Unit": "Percent"
},
{
"Timestamp": "2023-10-27T10:00:00Z",
"Average": 10.5,
"Unit": "Percent"
}
],
"Label": "CPUUtilization"
}
This is incredibly useful for troubleshooting microbursts of activity, understanding the immediate impact of application deployments, or reacting to sudden load changes. The key is that the EC2 agent on the instance is now reporting metrics more frequently. CloudWatch itself doesn’t magically "get more detailed"; it just receives data more often.
It’s important to remember that enabling detailed monitoring incurs an additional charge. You’re billed per instance, per month, for this feature. The cost is typically around $3.00 per instance per month. For basic monitoring, there’s no extra charge; it’s included with your EC2 usage.
The underlying mechanism is that enabling detailed monitoring flips a flag on the EC2 instance. This flag tells the EC2 instance’s system to send its internal performance counters to CloudWatch more frequently. Without this flag, the default behavior is to send them every 5 minutes. CloudWatch then acts as the collector and storage for these metrics, making them available via API and the console. You can also set up alarms based on these 1-minute metrics, allowing for much faster automated responses to performance issues.
When you enable detailed monitoring, you’re not just changing a setting in the AWS console; you’re actually modifying an attribute of the EC2 instance that dictates how often its underlying hypervisor and operating system report metrics. The modify-instance-attribute API call is the definitive way to manage this.
Be aware that while you can request 1-minute metrics, the actual availability of data points can sometimes have a slight lag, though it’s generally very close to real-time. The period parameter in get-metric-statistics specifies the granularity of the data you want to retrieve; to see 1-minute data, you must set --period to 60. If you set --period to 300 (5 minutes) after enabling detailed monitoring, you’ll still only get 5-minute aggregated data, even though the instance is sending metrics every minute.
The next thing you’ll want to explore is setting up CloudWatch Alarms on these 1-minute metrics to trigger automated actions.