Let's think about this for a second
CloudWatch Metrics are performance data (CPU utilization, network traffic, disk I/O) that resources like EC2/RDS/ALB automatically send in — you can view them as graphs on a dashboard. CloudWatch Logs is a service for centralizing application/system logs — with hundreds of EC2 instances, you don't need to go check each instance's log individually; you can search/filter right inside CloudWatch Logs. A CloudWatch Alarm lets you set a threshold on a metric (e.g. CPU > 80%) and send a notification (email, SNS) when it's crossed — you can also use it as an Auto Scaling trigger.
Let's connect this to a real scenario
You can view an EC2 instance's CPU utilization metric as a graph on a CloudWatch dashboard — if you set up an Alarm to email you when CPU crosses 80% (which, like in the ASG lesson, can also be used as an auto-scale trigger), you'll get advance warning before the server overloads. Once your application's error logs are flowing into CloudWatch Logs, you can search error messages by keyword to debug.
Let's look at this together
# Create an alarm: notify if CPU > 80% for 5 minutes
aws cloudwatch put-metric-alarm \
--alarm-name high-cpu-tutorial \
--metric-name CPUUtilization \
--namespace AWS/EC2 \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
--evaluation-periods 1$ aws cloudwatch describe-alarms --alarm-names high-cpu-tutorial --query 'MetricAlarms[].StateValue'
["OK"]Try it in 5 minutes
Take a look at your EC2 instance's (from the Basic chapter) CPU utilization metric in the CloudWatch Console — try setting up an Alarm that alerts you when CPU exceeds 70%.
A quick word of caution
Make sure you set up CloudWatch Alarms for at least your critical production metrics (database connection count, error rate) — it's always the metric you assumed 'that'll never happen' that ends up causing the production incident.