100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
AWS

CloudWatch Monitoring Basics

Learn how Amazon CloudWatch collects metrics and logs from your AWS resources, and how to build alarms that alert you before small issues become outages.

PracticeBeginner9 min readJul 10, 2026
Analogies

What Is Amazon CloudWatch?

Amazon CloudWatch is AWS's native monitoring and observability service. It automatically collects metrics from most AWS resources the moment you create them — an EC2 instance reports CPUUtilization, NetworkIn, and StatusCheckFailed every five minutes by default, or every one minute if you enable detailed monitoring. CloudWatch also ingests logs, custom application metrics, and events, giving you a single console to answer 'is my system healthy right now, and was it healthy an hour ago?'

🏏

Cricket analogy: Like a stadium's electronic scoreboard that continuously updates run rate, overs bowled, and wickets without anyone manually re-entering numbers, CloudWatch auto-populates EC2 metrics the instant the instance launches.

Metrics, Namespaces, and Dimensions

Every CloudWatch metric lives inside a namespace, such as AWS/EC2 or AWS/RDS, which prevents naming collisions between services. Within a namespace, dimensions like InstanceId or DBInstanceIdentifier let you filter a metric down to one specific resource instead of an aggregate. Beyond the built-in metrics, you can publish your own with the PutMetricData API — for example, an application could emit a custom 'CheckoutLatency' metric in a namespace called MyApp/Checkout, at standard one-minute resolution or high resolution down to one second for latency-sensitive workloads.

🏏

Cricket analogy: A namespace is like the ICC separating T20I stats from Test stats so Virat Kohli's T20 strike rate never gets mixed into his Test batting average, and dimensions let you drill into just his innings against Australia.

Alarms and Actions

A CloudWatch alarm watches a single metric against a threshold over a configurable number of evaluation periods and moves between three states: OK, ALARM, and INSUFFICIENT_DATA. For example, an alarm might trigger when average CPUUtilization exceeds 80% for three consecutive five-minute periods. Once in ALARM state, it can invoke an action automatically — publishing to an SNS topic that emails the on-call engineer, or triggering an Auto Scaling policy that launches additional instances — turning passive monitoring into active, automated response.

🏏

Cricket analogy: It's like a bowling captain setting a rule that if the economy rate crosses 9 runs per over for three consecutive overs, the bowler is automatically taken off — the threshold breach triggers an automatic substitution.

bash
# Create a CloudWatch alarm that notifies an SNS topic when average CPU
# stays above 80% for three consecutive 5-minute periods
aws cloudwatch put-metric-alarm \
  --alarm-name "high-cpu-web-fleet" \
  --namespace "AWS/EC2" \
  --metric-name "CPUUtilization" \
  --dimensions Name=InstanceId,Value=i-0abcd1234efgh5678 \
  --statistic "Average" \
  --period 300 \
  --evaluation-periods 3 \
  --threshold 80 \
  --comparison-operator "GreaterThanThreshold" \
  --alarm-actions "arn:aws:sns:us-east-1:123456789012:ops-alerts"

Logs, Log Groups, and Log Insights

The CloudWatch unified agent (or the older CloudWatch Logs agent) ships application and system logs from EC2 instances into log groups, which are further subdivided into log streams — typically one stream per instance or process. Each log group has its own retention setting, from one day up to indefinite, so you control storage cost independently per application. CloudWatch Logs Insights adds a purpose-built query language for filtering and aggregating those logs, letting you run something like 'count errors by status code over the last hour' without exporting data to a separate tool.

🏏

Cricket analogy: Log groups are like a team's separate scorebooks for ODIs, T20s, and Tests, each with its own archival policy, while Logs Insights is like a stats analyst querying 'how many boundaries were hit in the death overs this season.'

The CloudWatch free tier includes 10 custom metrics, 10 alarms, 1 million API requests, and basic dashboards each month — enough to fully monitor a small project without incurring charges, as long as you stick to standard (not high-resolution) metrics and avoid excessive custom metric cardinality.

High-resolution custom metrics (sub-minute) and detailed EC2 monitoring both cost more than the standard one-minute or five-minute defaults, and a metric with high-cardinality dimensions (like per-request unique IDs) can silently generate thousands of billable metric streams — always review the Billing dashboard after adding custom metrics.

  • CloudWatch automatically collects default metrics (like CPUUtilization) from most AWS resources without any setup.
  • Metrics are organized by namespace (e.g., AWS/EC2) and filtered further using dimensions (e.g., InstanceId).
  • Custom application metrics can be published via PutMetricData at standard (1-minute) or high (1-second) resolution.
  • Alarms move between OK, ALARM, and INSUFFICIENT_DATA states based on a threshold evaluated over multiple periods.
  • Alarm actions can notify via SNS or trigger Auto Scaling policies automatically, without human intervention.
  • CloudWatch Logs organizes ingested logs into log groups and streams, each with independently configurable retention.
  • Logs Insights provides a query language to filter and aggregate log data directly inside the CloudWatch console.

Practice what you learned

Was this page helpful?

Topics covered

#AWS#AWSFundamentalsStudyNotes#CloudComputing#CloudWatchMonitoringBasics#CloudWatch#Monitoring#Amazon#Metrics#StudyNotes#SkillVeris