Amazon CloudWatch
AWS's native monitoring service — metrics, alarms, logs, and dashboards that give you visibility into what your infrastructure is actually doing.
Want a visual for this topic?
Generate a diagram tailored to Amazon CloudWatch — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain the difference between a metric, an alarm, and a log group
- •Configure an alarm that takes an automated action (e.g. triggering Auto Scaling)
- •Explain the difference between standard and detailed monitoring resolution
- •Write a basic CloudWatch Logs Insights query
What is it?
Amazon CloudWatch is AWS's native monitoring and observability service — it collects metrics (numeric time-series data like CPU utilization or request count) from AWS services and your own applications, lets you set alarms that trigger notifications or automated actions when thresholds are crossed, and centralizes log data for search and analysis.
Why it exists
Running infrastructure without visibility into its actual behavior means you only find out something is wrong when a user complains, or worse, not at all. CloudWatch exists to give you continuous, automatic visibility into every AWS resource's health and performance, plus a place to send and search your own application's logs, without needing to build or operate separate monitoring infrastructure.
Problem it solves
It solves the visibility problem (metrics and dashboards show you what's actually happening across your infrastructure in near-real-time), the reactive-response problem (alarms can automatically trigger actions — like Auto Scaling adjustments or SNS notifications — the moment a threshold is crossed, rather than requiring a human to notice), and the log-centralization problem (application and infrastructure logs from many sources land in one searchable place instead of being scattered across individual servers).
Intuition
CloudWatch is like a building's central monitoring panel: gauges showing current readings from every system (metrics), alarm bells that ring automatically when a reading crosses a dangerous threshold (alarms), and a logbook recording everything that's happened, searchable later (logs) — all feeding into one place instead of needing to physically check each individual room's own equipment.
Analogy
A car's dashboard combined with a black box flight recorder: the dashboard gauges (metrics) show you current speed, fuel, and engine temperature at a glance; warning lights (alarms) alert you the instant something crosses a dangerous threshold; and the flight recorder (logs) keeps a detailed history you can review after the fact to understand exactly what happened during an incident.
Technical explanation
Metrics are published at a resolution — Standard resolution (1-minute granularity, the default and free for most AWS service metrics) or Detailed/High-Resolution monitoring (down to 1-second granularity, at additional cost, useful when you need to detect and react to very short-lived spikes that 1-minute averages would smooth over and hide). Alarms have three states: OK (within threshold), ALARM (threshold breached), and INSUFFICIENT_DATA (not enough data yet to evaluate), and can be configured with a specific number of consecutive breaching data points required before actually transitioning to ALARM, avoiding over-reaction to a single noisy spike. CloudWatch Logs Insights provides a purpose-built query language for searching and aggregating log data across one or more log groups — e.g. filtering for error-level log lines and counting them per 5-minute window — without needing to export logs to a separate analysis tool.
Architecture
A production web application publishes custom application metrics (e.g. checkout_completion_rate) alongside AWS's automatic infrastructure metrics (EC2 CPU, ALB request count, RDS connections). CloudWatch Alarms watch ALB 5xx error rate and RDS CPU, notifying an on-call team via SNS when thresholds are breached, while a separate alarm on Auto Scaling Group CPU directly triggers a scaling action. Application logs from Lambda functions and EC2 instances (via the CloudWatch agent) land in CloudWatch Logs, where a Logs Insights query helps the team quickly find all error-level log entries related to a specific customer's failed checkout during an incident investigation.
Workflow
- Confirm which metrics AWS services publish automatically (most do, with no setup) and identify any custom application metrics worth publishing (business-relevant numbers, not just infrastructure health). 2) Set alarms on the metrics that actually matter for availability/performance, with thresholds based on real historical behavior, not arbitrary guesses. 3) Connect alarms to appropriate actions — SNS notification for human awareness, Auto Scaling for automated capacity response, Lambda for custom automated remediation. 4) Route application and infrastructure logs into CloudWatch Logs, organized into logically-named log groups. 5) Build dashboards combining the metrics most relevant to a specific team or on-call rotation's daily visibility needs.
Example
An API team sets a CloudWatch Alarm on their ALB's target 5xx error rate, triggering an SNS notification to their on-call PagerDuty integration if error rate exceeds 5% for 3 consecutive 1-minute periods (avoiding false alarms from a single brief blip). During an actual incident, they use CloudWatch Logs Insights to query their Lambda function's logs for all ERROR-level entries in the last 15 minutes, quickly narrowing down the root cause without needing to manually search through raw log files.
Real-world usage
CloudWatch is the default, near-universal monitoring layer for AWS-hosted applications, used across virtually every AWS customer regardless of size; CloudWatch Alarms feeding Auto Scaling actions is one of the most fundamental and widely-used automation patterns in AWS architectures, directly enabling the elastic scaling behavior covered in the Auto Scaling topic.
Trade-offs
Standard monitoring resolution is free and sufficient for most steady-state operational visibility; Detailed/High-Resolution monitoring costs more but is necessary when you need to detect and react to spikes shorter than a minute (common for auto-scaling on genuinely volatile traffic). Setting alarm thresholds tightly (reacting to small deviations) catches problems earlier but risks more false-positive noise; looser thresholds reduce noise but may delay detecting a real, gradually worsening issue.
Visual explanation
Picture AWS services (EC2, RDS, Lambda, and dozens more) automatically publishing metrics into CloudWatch with zero configuration — CPU utilization, request counts, error rates. A CloudWatch Alarm watches one specific metric against a threshold you define, and when breached, it can notify an SNS topic, trigger an Auto Scaling action, or invoke a Lambda function. Separately, CloudWatch Logs collects log data (from Lambda automatically, from EC2/ECS via the CloudWatch agent, from other services) into Log Groups, searchable via CloudWatch Logs Insights' query language.
Advantages
- —
Automatic metric collection for most AWS services requires zero setup — visibility exists from the moment a resource is created
- —
Alarms can trigger fully automated responses (scaling, remediation) without requiring a human to notice and react manually
- —
Centralizes logs from many sources into one searchable place, avoiding the need to individually access each server/service's local logs
- —
Native integration with virtually every other AWS service, requiring no third-party monitoring agent installation for most infrastructure metrics
Disadvantages
- —
Standard 1-minute metric resolution can hide very short-lived spikes; Detailed Monitoring for finer granularity has an additional cost
- —
CloudWatch Logs storage and Logs Insights query costs can grow significantly at high log volume if retention and query patterns aren't managed deliberately
- —
Building genuinely useful dashboards and well-tuned alarm thresholds takes real, ongoing effort — a wall of default metrics without curation doesn't provide much actual operational insight
- —
Cross-account or cross-Region metric/log aggregation requires deliberate additional configuration, not automatic by default
Common mistakes
- —
Not setting any alarms at all and relying purely on manually checking dashboards or waiting for user complaints to notice problems
- —
Setting alarm thresholds based on guesses rather than actual historical metric behavior, leading to either constant false alarms or alarms that never fire when they should
- —
Not requiring multiple consecutive breaching data points before triggering an alarm, causing false alarms from single brief, harmless spikes
- —
Leaving CloudWatch Logs retention set to 'Never expire' by default across many log groups, accumulating unnecessary storage cost for logs no one will ever need to look at again
- —
Building dashboards showing every available metric indiscriminately instead of curating the specific handful that actually matter for a given team's operational decisions
In the AWS Console
- 1
AWS Console → CloudWatch → Alarms → Create alarm
Select the metric to monitor (e.g. an ALB's HTTPCode_Target_5XX_Count), define the threshold and evaluation period, and configure an action (SNS notification, Auto Scaling action, or EC2 action).
Set 'Datapoints to alarm' to require multiple consecutive breaching periods (e.g. 3 out of 3) rather than a single data point, to avoid false alarms from brief noise.
- 2
CloudWatch → Log groups → select a group → Create log stream (or view existing)
Review incoming log entries, and use the 'Search log group' feature for simple text filtering.
Lambda automatically creates and writes to a log group per function with no configuration; EC2/ECS require installing and configuring the CloudWatch agent first.
- 3
CloudWatch → Logs Insights → select log group(s)
Write a query using CloudWatch Logs Insights' query language, e.g. `fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20`.
Logs Insights charges based on the volume of log data scanned by a query — narrowing the time range and log groups queried keeps this cost reasonable.
- 4
CloudWatch → Dashboards → Create dashboard
Add widgets for the specific metrics most relevant to daily operational visibility, grouping related metrics together logically.
Curate deliberately — a dashboard showing every available metric indiscriminately provides less actual insight than one showing a focused, relevant set.
🎤 Interview questions
What's the difference between a CloudWatch metric, an alarm, and a log group? (Listen for: metric = numeric time-series data; alarm = a rule watching a metric against a threshold, capable of triggering an action; log group = a container for log data, searchable via Logs Insights.)
Why would you require multiple consecutive breaching data points before an alarm fires, instead of just one? (Listen for: avoids false alarms and unnecessary automated actions from a single brief, harmless spike rather than a genuine sustained problem.)
How does a CloudWatch Alarm typically trigger an Auto Scaling action? (Listen for: the alarm watches a metric like average CPU utilization across an Auto Scaling Group, and when breached, directly triggers a scaling policy to add or remove instances.)
When would you need Detailed/High-Resolution monitoring instead of Standard? (Listen for: when you need to detect and react to spikes shorter than the 1-minute Standard resolution would capture — e.g. very rapid, brief traffic bursts.)
How would you investigate an application error using CloudWatch during an incident? (Listen for: query the relevant log group(s) via CloudWatch Logs Insights, filtering for error-level entries within the relevant time window, to quickly narrow down root cause without manually searching raw logs.)