AWS CloudWatch Metrics
Work with default EC2 metrics, create a CPU alarm, understand log groups and streams, and use metric filters for operational insight.
CloudWatch metrics are the first layer of visibility for most AWS workloads. EC2 publishes default measurements such as CPUUtilization, network in and out, and status checks. These metrics are enough to answer basic operational questions like whether an instance is overloaded, idle, or unreachable, even before you add application-specific telemetry.
Creating a CPU alarm is a useful first exercise because it connects monitoring to action. An alarm on CPU greater than 80 percent for several evaluation periods can notify an SNS topic, trigger automation, or simply prove that your metric pipeline is working. The value is not only the threshold itself but the habit of defining what abnormal behavior looks like.
| CloudWatch item | What it represents |
|---|---|
| Metric | Numeric time-series data |
| Alarm | Threshold-based evaluation of a metric |
| Log group | Collection of related logs |
| Log stream | Sequence of log events from one source |
| Metric filter | Pattern that turns logs into metrics |
Logs fill the gaps metrics cannot. A CPU spike tells you something is wrong; application logs often tell you why. Organizing logs into sensible log groups and streams makes troubleshooting faster, especially in serverless and container-heavy environments where hosts are short-lived.
Metric filters are a bridge between logs and alerts. You can count lines containing ERROR, extract latency values, or surface deployment failures as metrics that alarms can watch. That pattern helps when an application does not yet emit custom metrics directly.
Pair this lesson with AWS CloudWatch and try to choose alarms that map to real operational decisions rather than vanity graphs.
aws cloudwatch list-metrics --namespace AWS/EC2 --query 'Metrics[].MetricName' --output table
aws cloudwatch put-metric-alarm --alarm-name high-cpu-demo --metric-name CPUUtilization --namespace AWS/EC2 --statistic Average --period 300 --threshold 80 --comparison-operator GreaterThanThreshold --evaluation-periods 2 --dimensions Name=InstanceId,Value=i-1234567890abcdef0
aws logs describe-log-groups
Operational note
Good monitoring is less about collecting everything and more about creating signals that lead to action. Prefer alarms tied to user impact, error budgets, queue backlogs, or sustained saturation over noisy one-off spikes. Teams trust observability more when alerts are specific, actionable, and rarely ignored. Shared standards like this make future environments easier to launch, review, and support.
EC2 monitoring
Which metric is commonly used to see whether an EC2 instance is CPU constrained?
Metric filters
Why would you create a CloudWatch metric filter on application logs?