AWS CloudWatch Tutorial: Metrics, Logs, Alarms and SNS

Amazon CloudWatch is one of the most important AWS services for Cloud Engineers, DevOps Engineers, Site Reliability Engineers, and system administrators.

It helps teams monitor infrastructure, analyze logs, detect failures, create alerts, and automatically respond to operational problems.

What Is Amazon CloudWatch?

Amazon CloudWatch is an AWS monitoring and observability service.

It collects and analyzes operational data from AWS resources, applications, containers, on-premises servers, and hybrid environments. This data can include metrics, logs, and traces.

In simple English:

CloudWatch shows what is happening inside your AWS infrastructure and alerts you when something goes wrong.

For example, CloudWatch can notify the DevOps team when:

• EC2 CPU utilization becomes unusually high
• An EC2 instance fails a status check
• An application generates too many errors
• An ALB has unhealthy targets
• An RDS database is running low on storage
• A Lambda function is failing or being throttled
• Estimated AWS charges exceed a defined limit

Why Do DevOps Engineers Use CloudWatch?

DevOps engineers use CloudWatch to:

• Monitor infrastructure performance
• Centralize application and operating-system logs
• Create dashboards for production environments
• Detect problems before users report them
• Send notifications through Amazon SNS
• Trigger automated recovery or scaling actions
• Investigate incidents using metrics and logs
• Monitor AWS spending
• Create operational evidence for Jira incidents

Your source material correctly emphasizes alarms, dashboards, SNS topics, billing monitoring, detailed monitoring, and resolving CloudWatch-related Jira tickets as common daily responsibilities.

How Does CloudWatch Work?

A basic monitoring workflow is:

AWS resource → Metric or log → CloudWatch → Alarm → SNS notification → Engineer or automated action

Example:

1. An EC2 instance publishes CPU utilization to CloudWatch.
2. CloudWatch evaluates the metric.
3. CPU remains above the configured threshold.
4. The alarm changes from OK to ALARM.
5. CloudWatch publishes a notification to an SNS topic.
6. SNS emails or messages the operations team.
7. The engineer investigates the application or infrastructure.

CloudWatch alarms can also perform automated actions, including Auto Scaling actions and selected EC2 recovery, reboot, stop, or terminate actions.

Core CloudWatch Components

1. Metrics

A metric is numerical performance data collected over time.

Examples:

• EC2 CPU utilization
• ALB request count
• RDS database connections
• Lambda errors
• EBS read and write operations

AWS services publish many metrics automatically. You can also publish custom application metrics.

2. Namespace

A namespace groups metrics from the same AWS service or application.

Examples:

• AWS/EC2
• AWS/RDS
• AWS/Lambda
• AWS/ApplicationELB
• CWAgent

The CWAgent namespace commonly contains metrics collected by the CloudWatch Agent.

3. Dimensions

A dimension identifies the resource associated with a metric.

Examples:

• InstanceId
• DBInstanceIdentifier
• FunctionName
• LoadBalancer
• AutoScalingGroupName

CloudWatch treats each unique combination of metric and dimensions as a separate time series.

4. Statistics

Statistics determine how CloudWatch calculates metric data.

Common statistics include:

• Average
• Minimum
• Maximum
• Sum
• Sample count
• Percentiles such as p90, p95, and p99

Use the statistic that matches the metric. For example:

• Average: CPU utilization
• Sum: Request or error count
• Maximum: Peak resource usage
• Percentile: Application latency

Basic Monitoring vs Detailed Monitoring

For EC2:

• Basic monitoring: Metrics are normally published every five minutes.
• Detailed monitoring: Metrics are published every minute.

Detailed monitoring helps detect problems faster but can create additional cost. Enable it where one-minute visibility provides operational value, especially for important production workloads.

CloudWatch Agent

The CloudWatch Agent collects additional operating-system and application data from:

• EC2 instances
• On-premises servers
• Linux systems
• Windows servers
• Containerized applications

It can collect:

• Memory utilization
• Disk-space utilization
• Swap usage
• Process information
• Application logs
• System logs
• Custom metrics
• Traces

Important Interview Correction

EC2 provides infrastructure metrics such as CPU and network metrics, but memory and operating-system disk-space utilization are not standard EC2 metrics.

To monitor RAM and disk-space utilization, install and configure the unified CloudWatch Agent.

This corrects the common statement that CloudWatch automatically provides both CPU and RAM metrics for every EC2 instance.

CloudWatch Logs

CloudWatch Logs centralizes logs from AWS services, servers, and applications.

Log group

A log group contains logs with the same purpose, application, or retention policy.

Examples:

• /aws/lambda/payment-function
• /application/prod
• /var/log/messages
• /aws/eks/cluster/application

Log stream

A log stream contains log events from one source.

Examples:

• One EC2 instance
• One container
• One Lambda execution environment

Log retention

Set an appropriate retention period instead of keeping every log indefinitely.

Example:

• Development logs: 7–30 days
• Production application logs: based on operational requirements
• Security or compliance logs: based on company policy

Metric filters

Metric filters convert matching log patterns into CloudWatch metrics.

Example:

• Search logs for ERROR
• Convert matches into an ApplicationErrorCount metric
• Create an alarm when the error count increases

CloudWatch Logs can also route matching events through subscription filters and display incoming logs through Live Tail.

CloudWatch Logs Insights

CloudWatch Logs Insights helps engineers search and analyze log data during troubleshooting. It supports its native Logs Insights query language as well as supported OpenSearch query languages.

Example query to find recent errors:

fields @timestamp, @message
| filter @message like /ERROR|Exception/
| sort @timestamp desc
| limit 50

Typical uses:

• Find application errors
• Investigate failed requests
• Identify slow operations
• Count HTTP status codes
• Search by request ID
• Validate a production fix

CloudWatch Dashboards

Dashboards display important metrics and logs in one place.

Useful production dashboards include:

Web-server dashboard

• CPU utilization
• Memory utilization
• Disk usage
• Network traffic
• Instance status checks

Application dashboard

• Request count
• Error rate
• Response time
• Active users
• Application exceptions

Database dashboard

• CPU utilization
• Connections
• Free storage
• Memory
• Read and write latency

CloudWatch also supports cross-account and cross-Region dashboards for centralized operational visibility.

CloudWatch Alarms

A CloudWatch alarm evaluates a metric or metric expression against a configured condition.

An alarm has three states:

• OK: The metric is within the expected threshold.
• ALARM: The metric has breached the condition.
• INSUFFICIENT_DATA: CloudWatch does not have enough data to evaluate it.

Alarm configuration

When creating an alarm, configure:

1. Metric
2. Statistic
3. Period
4. Threshold or anomaly band
5. Evaluation periods
6. Datapoints to alarm
7. Missing-data treatment
8. Notification or automated action

Do not select thresholds such as 80% or 90% without understanding the application’s normal behavior.

CloudWatch and SNS Integration

Amazon SNS delivers CloudWatch alarm notifications to subscribers.

Supported endpoints can include:

• Email
• SMS
• HTTP or HTTPS endpoints
• Lambda
• SQS
• Mobile push services

Basic setup

1. Create an SNS topic.
2. Add a subscription.
3. Confirm the email subscription.
4. Create a CloudWatch alarm.
5. Select the SNS topic as the alarm action.
6. Test the alarm and notification path.

A frequent reason for missing email alerts is that the recipient has not confirmed the SNS subscription.

CloudWatch can also monitor SNS delivery metrics such as failed notifications.

Important Metrics to Monitor

EC2

• CPUUtilization
• StatusCheckFailed
• Network traffic
• Disk read and write operations
• Memory and disk-space metrics through the CloudWatch Agent

Application Load Balancer

• Request count
• Target response time
• HealthyHostCount
• HTTPCode_Target_5XX_Count
• Rejected connections

RDS

• CPU utilization
• Database connections
• Free storage space
• Freeable memory
• Read and write latency
• Replica lag where applicable

RDS automatically publishes standard monitoring metrics to CloudWatch, while Enhanced Monitoring provides deeper operating-system visibility.

Lambda

• Invocations
• Errors
• Duration
• Throttles
• Concurrent executions
• Iterator age for stream-based workloads

Use the Maximum statistic when evaluating Lambda concurrency.

Billing Alarms

CloudWatch billing alarms notify teams when estimated AWS charges exceed a threshold.

Important points:

• Enable CloudWatch billing alerts in Billing Preferences.
• Create the billing alarm in US East (N. Virginia).
• Billing data in that Region represents worldwide estimated charges.
• Send the alarm to an SNS topic.

For stronger cost governance, combine billing alarms with AWS Budgets and cost-allocation controls.

Real-World DevOps Daily Tasks

Common CloudWatch responsibilities include:

• Review active and recently triggered alarms
• Check production dashboards
• Investigate CPU, memory, disk, latency, and error spikes
• Analyze logs using Logs Insights
• Create or modify alarms
• Validate SNS notifications
• Review billing alerts
• Enable detailed monitoring where required
• Configure dashboards for web, application, and database tiers
• Resolve CloudWatch and SNS Jira tickets
• Coordinate with application, database, networking, and AWS support teams
• Tune noisy or ineffective alarms
• Verify log retention and ingestion cost

These responsibilities expand the practical tasks contained in the original CloudWatch and SNS notes.

Common Errors and Solutions

SNS email notification is not received

Check:

• Subscription confirmation
• Correct SNS topic
• Correct AWS Region
• Alarm action configuration
• Topic policy
• Email spam folder
• Alarm state history

Memory metric is missing

Cause:

• Memory is not a default EC2 metric.

Solution:

• Install the CloudWatch Agent.
• Attach the required IAM role.
• Configure memory collection.
• Start and verify the agent.

Alarm remains in INSUFFICIENT_DATA

Check:

• Metric is being published
• Correct namespace and dimensions
• Alarm period matches metric resolution
• Missing-data configuration
• Resource is active

CloudWatch allows missing data to be treated as breaching, not breaching, ignored, or missing. Select the option based on what missing data means for that metric.

Alarm generates too many alerts

Possible solutions:

• Increase evaluation periods
• Use multiple datapoints before alarming
• Adjust the threshold
• Use anomaly detection
• Use composite alarms
• Alert on customer impact instead of every infrastructure fluctuation

Composite alarms can combine several underlying alarms and reduce unnecessary notification noise.

Logs are becoming expensive

Check:

• Log ingestion volume
• Retention periods
• Debug logging in production
• High-cardinality custom metrics
• Large Logs Insights query ranges
• Unnecessary dashboards or alarms

CloudWatch cost depends on the features and volume used, including log ingestion, storage, queries, custom metrics, alarms, and dashboards.

CloudWatch Best Practices

• Monitor customer-facing symptoms such as errors and latency.
• Use separate warning and critical alarms only when both require different actions.
• Configure missing-data handling deliberately.
• Add useful alarm descriptions, owners, and runbook links.
• Use dimensions consistently.
• Set log retention policies.
• Use the CloudWatch Agent only for required operating-system metrics and logs.
• Use metric math for meaningful service-level indicators.
• Use anomaly detection for workloads with changing traffic patterns.
• Use composite alarms to reduce alert fatigue.
• Manage dashboards and alarms through Terraform, CloudFormation, or another IaC tool.
• Test the complete alarm-to-notification workflow.

CloudWatch anomaly detection builds expected ranges from historical metric behavior and can account for common hourly, daily, and weekly patterns.

CloudWatch vs CloudTrail vs AWS Config vs SNS

CloudWatch

Monitors performance, logs, application health, operational events, and alarms.

Question answered: Is the system healthy?

CloudTrail

Records AWS API activity and account actions.

Question answered: Who performed this AWS action?

AWS Config

Tracks resource configuration and evaluates compliance.

Question answered: Is this resource configured according to policy?

Amazon SNS

Distributes messages and notifications to subscribers.

Question answered: How should this alert be delivered?

Important Interview Questions

1. What is Amazon CloudWatch?

CloudWatch is an AWS monitoring and observability service used to collect metrics, logs, and traces, create dashboards and alarms, and respond to operational conditions.

2. What is a CloudWatch metric?

A metric is time-series numerical data that represents the performance or behavior of a resource or application.

3. Does CloudWatch monitor EC2 memory by default?

No. Install and configure the CloudWatch Agent to collect operating-system memory and disk-space metrics.

4. What are the CloudWatch alarm states?

OK, ALARM, and INSUFFICIENT_DATA.

5. What is the difference between a log group and a log stream?

A log group contains related logs with common settings. A log stream contains events from one source, such as an instance, container, or Lambda execution environment.

6. How does CloudWatch work with SNS?

A CloudWatch alarm publishes a message to an SNS topic when its state changes. SNS then delivers that message to confirmed subscribers.

7. What metrics do you monitor in your project?

A strong answer:

I monitor infrastructure and application metrics based on the workload. For EC2, I monitor CPU, status checks, memory, disk usage, and network traffic. For ALB, I monitor healthy hosts, target response time, and HTTP errors. For RDS, I monitor CPU, connections, storage, memory, and latency. I also monitor application errors and log patterns through CloudWatch Logs.

8. How do you troubleshoot a CloudWatch alarm?

Check the alarm history, metric graph, namespace, dimensions, statistic, period, threshold, datapoints, missing-data handling, and configured actions. Then correlate the alarm with application and system logs.

9. What is a composite alarm?

A composite alarm evaluates the states of multiple alarms. It is useful for reducing alert noise and notifying teams only when a meaningful combination of conditions occurs.

10. What is the difference between CloudWatch and CloudTrail?

CloudWatch focuses on system health, performance, logs, and alerts. CloudTrail records AWS API calls and account activity for security, auditing, and compliance.

Final Summary

Amazon CloudWatch is the central AWS service for operational monitoring and observability.

The highest-value concepts for jobs and interviews are:

• Metrics
• Logs
• Dashboards
• Alarms
• CloudWatch Agent
• SNS notifications
• Logs Insights
• Missing-data handling
• Billing alarms
• Production troubleshooting

For practical preparation, build one lab that monitors an EC2 application using:

EC2 → CloudWatch Agent → Metrics and logs → CloudWatch Alarm → SNS email notification