Amazon CloudWatch Overview: Metrics, Logs, Alarms, and Dashboards

CloudWatch in simple terms

Think of CloudWatch like the instrument cluster in a car. The speedometer and fuel gauge are your metrics: numeric readings updated in real time. The warning light that flashes when oil pressure drops is an alarm: a threshold crossed, action required. The trip computer recording speed and engine temperature over the journey is a log. And the screen you glance at to assess everything at once is your dashboard.

When the warning light fires and you need to trace exactly which component is failing, that is AWS X-Ray: the diagnostic tool that follows a request through every part of the system to find the fault.

How CloudWatch works end to end

Here is the flow from infrastructure event to on-call notification:

1. Signals are emitted. When an Amazon EC2 instance runs, AWS automatically publishes CPUUtilization, NetworkIn, and disk metrics to CloudWatch every 5 minutes. A Lambda function publishes Invocations, Errors, and Duration after every execution. Your application can push custom metrics via the CloudWatch API on top of that.

2. Metrics are stored by namespace and dimension. EC2 metrics land in the AWS/EC2 namespace, keyed by InstanceId. Lambda metrics land in AWS/Lambda, keyed by FunctionName. This lets you query a single resource or aggregate across a whole fleet. See Metrics in AWS for a full guide to namespaces, dimensions, and resolution.

3. Alarms evaluate thresholds continuously. A CloudWatch alarm checks a metric every evaluation period. When CPUUtilization exceeds 80% for three consecutive 1-minute periods, the alarm transitions to ALARM state and takes action: sending an SNS notification, triggering Auto Scaling, or invoking a Lambda for automated remediation. See Creating CloudWatch Alarms in AWS.

4. Logs capture the detail behind the numbers. Metrics tell you something is wrong. Logs tell you what happened. Lambda automatically writes function output to CloudWatch Logs. EC2 application logs require the CloudWatch agent. Once logs are in CloudWatch, you can query them with Logs Insights or convert patterns into log-based metrics for alerting on log content.

5. Dashboards give the on-call engineer a starting point. A CloudWatch dashboard brings together graphs, alarm states, and log queries on one screen. This is what you open first when an alert fires at 2 AM.

6. Automation connects CloudWatch to the rest of AWS. Auto Scaling Groups use CloudWatch alarms to add or remove EC2 instances under load. Amazon EventBridge routes state-change events to downstream workflows. Amazon SNS fans notifications out to email, SMS, PagerDuty, or Slack.

What Amazon CloudWatch covers

CloudWatch is a managed observability service that handles several distinct but related jobs:

• Metrics. Numeric time-series data points (CPU%, request count, latency) stored and queryable over time.
• Logs. Text records from your applications and AWS services, organized into log groups and streams.
• Alarms. Rules that watch a metric and trigger actions when a threshold is crossed.
• Dashboards. Customizable screens combining metric graphs, alarm statuses, and log widgets.
• Events / EventBridge. Event-driven automation triggered by state changes across AWS services.
• Contributor Insights. Identifies the top contributors to metric spikes — for example, which IP is generating the most 500 errors.
• Synthetics. Scheduled scripts that simulate user interactions and alert if they fail.

You do not need to use every feature. Most teams start with metrics and alarms, add Logs Insights as their operations mature, and reach for Synthetics and Contributor Insights when more sophisticated monitoring is needed.

What CloudWatch monitors automatically

AWS services push metrics to CloudWatch without any configuration on your part. The moment you launch an EC2 instance, CloudWatch starts receiving CPUUtilization, NetworkIn, and NetworkOut every 5 minutes.

Namespaces and dimensions: how CloudWatch organizes data

Every metric belongs to a namespace, a container that groups related metrics so they do not collide with one another. AWS services use namespaces like AWS/EC2, AWS/Lambda, and AWS/RDS. When you publish custom metrics from your own application, you pick your own namespace such as MyApp/Orders.

Within a namespace, metrics are distinguished further by dimensions, which are key-value pairs that identify a specific resource. For EC2, the primary dimension is InstanceId. For Lambda, it is FunctionName. Dimensions let you filter down to a single resource or aggregate across many. See Metrics in AWS for a full guide to namespaces, dimensions, resolution, and custom metrics.

Alarms: turning data into action

A CloudWatch alarm watches a single metric over a time period and triggers when the metric crosses a threshold you define. When an alarm fires, it can:

• Send a notification via Amazon SNS (email, SMS, or a webhook to PagerDuty or Slack)
• Trigger an Auto Scaling Group action to add or remove EC2 instances
• Stop, terminate, or reboot an EC2 instance automatically
• Invoke a Lambda function for custom remediation logic

Alarms have three states: OK (metric is within threshold), ALARM (threshold is breached), and INSUFFICIENT_DATA (not enough data points yet to evaluate). A new alarm starts in INSUFFICIENT_DATA until enough metric data arrives. This is the most common reason a freshly created alarm appears stuck and never transitions.

For a full walkthrough, see Creating CloudWatch Alarms in AWS.

CloudWatch Logs: capturing what happened

Metrics tell you that something changed. Logs tell you what actually happened. CloudWatch Logs stores log data in log groups (one per application or service) that contain log streams (one per source, such as one per EC2 instance or Lambda invocation).

CloudWatch Logs Insights is a built-in query language over your log data. It lets you search, filter, and aggregate using SQL-like syntax: find the top 10 error messages in the last hour, calculate average Lambda cold start duration, or count distinct users that hit a 500. Formatting your logs as JSON — covered in the Structured Logging in AWS guide — makes individual fields queryable and dramatically improves the usefulness of Insights.

You can also convert log patterns directly into metrics using log-based metrics, letting you alarm on log content without running a full Insights query each time.

See CloudWatch Logs Explained for the full guide including retention policies, the CloudWatch agent, and Logs Insights.

Dashboards: visibility at a glance

A CloudWatch dashboard is a customizable page of widgets showing metric graphs, alarm statuses, log query results, and plain text annotations. A well-designed dashboard gives your on-call engineer everything they need on one screen: error rate, p99 latency, database connections, SQS queue depth, and current alarm states.

Dashboards can be shared publicly (read-only) or across AWS accounts, which is useful for showing operational status to stakeholders without granting console access.

See CloudWatch Dashboards in AWS for how to build, organize, and share them.

When to use Amazon CloudWatch

CloudWatch applies to almost every AWS workload. Here are the most common starting points:

• Alert when EC2 CPU is too high. Set an alarm on CPUUtilization with an SNS notification. Enable detailed monitoring (1-minute resolution) for production instances so the alarm catches short spikes that basic 5-minute metrics would miss.
• Monitor Lambda errors and duration. Lambda automatically publishes Errors, Duration, and Throttles. Alarm on Errors greater than 0 for critical functions. See Monitoring AWS Lambda with CloudWatch for the full pattern.
• Centralize application logs. Ship logs from EC2, containers, and custom apps to CloudWatch Logs so all log data is searchable in one place with Logs Insights.
• Build an on-call dashboard. Combine your most important metrics and alarm states in a single CloudWatch dashboard that you open first during incidents.
• Troubleshoot production latency spikes. Use Logs Insights to identify the error spike, then pair with X-Ray to pinpoint which downstream service call is slow.
• Watch queue depth and database connections. SQS ApproximateAgeOfOldestMessage and RDS DatabaseConnections are critical health signals for async and data-heavy workloads.
• Monitor Kubernetes workloads. See Monitoring EKS Clusters in AWS for cluster-level and pod-level metrics via Container Insights.
• Respond to incidents end to end. See Incident Response Using AWS Monitoring Tools for how CloudWatch fits into a full incident response workflow.

CloudWatch vs CloudTrail vs X-Ray

These three services are frequently confused by beginners. They are complementary tools, not alternatives to each other.

CloudWatch vs CloudTrail in practice. AWS CloudTrail records API activity: every CreateBucket, TerminateInstance, or AttachRolePolicy call in your account, with the caller identity and timestamp. CloudWatch monitors performance and health. If you want to know “why is my Lambda erroring”, use CloudWatch. If you want to know “who deleted that S3 bucket”, use CloudTrail.

CloudWatch vs X-Ray in practice. CloudWatch can tell you your error rate is elevated or p99 latency has doubled. It cannot tell you which of your downstream services is responsible. AWS X-Ray traces the full path of individual requests across Lambda, API Gateway, DynamoDB, and external HTTP calls, showing exactly where time is spent and where errors originate. Use CloudWatch for broad health signals and alerts; use X-Ray to investigate specific failures in distributed systems. For more on the tracing layer, see Distributed Tracing in AWS.

Navigating CloudWatch in the AWS console

Open the CloudWatch console at console.aws.amazon.com/cloudwatch. The left sidebar is organized into the main feature areas: Dashboards, Alarms, Metrics, Logs, and Insights. Here is a quick orientation:

• Overview. A summary of alarms currently in ALARM state across all regions.
• Metrics / All metrics. Browse every metric namespace available in your account.
• Logs / Log groups. List of all log groups; click one to browse streams or run Insights queries.
• Alarms / All alarms. Current state of every alarm; filter by state to focus on firing ones.
• Dashboards. Create and manage your operational screens.

A useful starting point: click Metrics / All metrics / AWS/EC2 and select an instance to see its CPU graph. This gives you a feel for how namespaces and dimensions work before you build anything more complex.

Basic CloudWatch CLI commands

The AWS CLI gives you programmatic access to all CloudWatch data. These are the commands you will use most often:

# List all metric namespaces in your account
aws cloudwatch list-metrics --query 'Metrics[*].Namespace' --output text | sort -u

# List metrics for a specific namespace
aws cloudwatch list-metrics --namespace AWS/Lambda

# Get the last 10 minutes of CPU for a specific EC2 instance
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456789 \
  --start-time $(date -u -d '10 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 60 \
  --statistics Average

# List all alarms and their current state
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[*].{Name:AlarmName,State:StateValue}' \
  --output table

# List log groups
aws logs describe-log-groups \
  --query 'logGroups[*].logGroupName' \
  --output text