How do you know when your application is secretly failing without watching it 24 hours a day? In the exam, you need to understand how to set up automatic monitoring so you get alerted before users complain — this chapter breaks down CloudWatch Metrics, Logs, and Alarms so you can answer those questions confidently even if you have never touched AWS.
Jump to a section
A busy restaurant kitchen on a Saturday night. The head chef needs to know if the grill is hot enough, if the walk-in cooler is at a safe temperature, and how many orders are pending. The chef cannot stand over every appliance all night, so they install thermometers, timers, and order-tracking sheets. These are the restaurant's 'metrics' — numbers that show what is happening right now: grill temp is 400 degrees, cooler is 38 degrees, fifteen tickets waiting.
The chef also keeps a paper log book. Every hour, the line cooks write down the exact temperature of the fridge, the time they started each batch of sauce, and any funny smells or sounds from the dishwasher. That is the 'log' — a detailed record of events that can be looked at later if something goes wrong, like if a customer gets food poisoning and the inspector wants to see the fridge temps from last Tuesday.
Finally, the chef sets up an 'alarm'. The walk-in cooler has a loud bell that rings if the temperature climbs above 40 degrees. This alarm does not fix the broken cooler door, but it alerts the chef instantly so they can move the milk and steaks to a backup fridge before they spoil. In the same way, an AWS developer uses CloudWatch metrics (like grill temp), log groups (like the paper log book), and alarms (like the loud bell) to keep their application healthy without staring at it all night.
If the alarm rings and the chef finds a broken seal, they know exactly where to look in the log book to see when the temperature first started rising. That is the power of combining metrics, logs, and alarms together — you get early warning, detailed history, and a clear path to fixing the problem.
CloudWatch is an AWS service that watches your applications and infrastructure. Think of it as a central dashboard that collects data from all your AWS resources — servers, databases, functions, and even custom parts of your own code. CloudWatch gives you three core tools: Metrics, Logs, and Alarms. Each one solves a different problem, and together they form the backbone of application monitoring on AWS.
A 'metric' is a single number measured over time. For example, your EC2 instance's CPU utilisation is a metric. It might be 45% right now, 38% an hour ago, and 72% yesterday at peak traffic. CloudWatch stores these values and can graph them, which helps you spot trends — like your server running at 95% CPU every day at 3 PM. That pattern tells you when you need more capacity. Metrics are lightweight and cheap, because they are just numbers with timestamps and a few labels (like the instance ID). AWS sends many default metrics automatically for services like EC2, Lambda, and RDS. You can also create 'custom metrics' by sending your own numbers from your application, for instance the number of items in a shopping cart or the response time of an API endpoint.
A 'log' is a text message that describes an event in detail. When your application crashes, it may write a log message like 'Error: Database connection refused at 2025-03-20 14:32:01'. Logs are rich with detail — they contain error messages, stack traces, user IDs, and timestamps. CloudWatch organises logs into 'log groups'. A log group is like a folder that holds all the logs from one source, such as all logs from a single Lambda function or all logs from an EC2 instance. Inside a log group, you have 'log streams' — individual files within the folder. So if you have three EC2 instances running the same application, you might have one log group called '/ec2/my-app' with three log streams, one per server. Logs are more expensive to store and search than metrics because they contain much more data, but they are essential for debugging exactly what happened during a failure.
An 'alarm' is a trigger that watches a metric and performs an action when the metric crosses a threshold for a certain amount of time. For example, you can create an alarm that watches your EC2 CPU utilisation metric. You set a threshold: if CPU stays above 80% for five consecutive minutes, the alarm goes to 'ALARM' state. When that happens, CloudWatch can send an email via Amazon SNS, or trigger an auto-scaling action to launch a new server, or call a Lambda function to run a recovery script. Alarms solve the problem of human inattention — you cannot watch a graph 24/7, but CloudWatch can.
The key relationship to remember: metrics are the what (numerical value), logs are the why (detailed text explanation), and alarms are the so-what (automated response). When you design monitoring for a real application, you typically set up metrics to detect symptoms, then when an alarm fires, you examine the logs to find the root cause.
CloudWatch also offers a feature called 'Logs Insights' that lets you run SQL-like queries across your logs. This is helpful when you have millions of log lines and need to find every occurrence of a specific error in the last hour. The exam expects you to know these basics: how metrics differ from logs, how log groups contain log streams, and how alarms use metrics and can trigger SNS topics. You do not need to memorise every CloudWatch setting, but you must understand the architecture of how these three parts fit together.
Identify What to Monitor
Decide which metrics matter to your application. For a web app, these might be CPU, memory, request latency, and error count. For the exam, think about what symptoms a user would feel — slow load times (latency) or errors (5xx status codes). This step determines which default metrics you will use and which custom metrics you need to create.
Collect Metrics and Logs
Enable the CloudWatch agent on EC2 instances to capture OS-level metrics like memory and disk. Send application logs to a CloudWatch log group by configuring the AWS SDK or used puts of the CloudWatch agent. For Lambda functions, logs are automatically sent to CloudWatch — no agent needed. This step ensures the data is flowing into CloudWatch so you can later analyse it.
Create a Metric Filter for Log-Based Alarms
If you want to be alerted when a specific error (e.g., 'Connection refused') appears in logs, create a metric filter on the log group. The filter parses log events and publishes a custom metric counting how many times that error occurs per minute. This turns text logs into a metric that an alarm can watch, bridging the gap between logs and metrics.
Set Up an Alarm on a Key Metric
Choose a metric — perhaps CPU utilisation or the custom error count from the metric filter. Define a threshold (e.g., CPU > 80%) and an evaluation period (e.g., 3 out of 5 consecutive data points are above the threshold). Configure the alarm to send a notification to an SNS topic. This step automates alerting so you know when something goes wrong without watching graphs.
Define a Remediation Action
Decide what should happen when the alarm fires. Common actions include sending an email to the on-call engineer, triggering an Auto Scaling policy to add capacity, or invoking a Lambda function that runs a fix (like restarting a service). On the exam, be prepared to select which action is appropriate for a given scenario — the alarm itself only detects the problem; the action actually fixes it.
Review and Adjust Over Time
After the alarms are active, monitor their behaviour. If you get too many false alarms, adjust the threshold or evaluation period. If you miss real problems, lower the threshold. This step is about ongoing tuning. The exam may test the concept of composite alarms (combining two alarms) to reduce noise — for example, only alerting if CPU is high AND request count is high, not just CPU spikes from a spike.
Imagine you are the sole developer for a small e-commerce site that sells handmade candles. The site runs on a single EC2 instance and a MySQL RDS database. You have been getting complaints from customers that the site is slow between 7 PM and 9 PM, but you are busy cooking dinner and cannot check the dashboard every evening. Here is exactly what you would set up with CloudWatch:
First, you look at the default metrics AWS already gives you. EC2 sends CPU utilisation, network in/out, and disk reads/writes. RDS sends database connections, read latency, and write latency. You open the CloudWatch console and see a graph of CPU utilisation over the last week. The spike at 8 PM every night confirms the problem is real.
Next, you decide to create a custom metric. Your application already counts how many active users are browsing candles. You add a few lines of code to push that number to CloudWatch as a custom metric called 'ActiveUsers'. Now you can see that when ActiveUsers rises above 200, CPU jumps to 90%. That links the user count directly to performance.
You also need deeper visibility, so you enable detailed logging on your web server. All access logs and error logs are sent to a CloudWatch log group called '/ec2/candle-shop'. You open the logs and see that at high traffic, the database queries for 'best-selling candles' take five seconds instead of 50 milliseconds. The logs tell you exactly which SQL query is slow.
Now you set up an alarm. You create an alarm on the CPU metric: if CPU stays above 85% for ten minutes, it sends a notification to your phone via an SNS topic. You also set a second alarm on the custom ActiveUsers metric: if ActiveUsers exceeds 250, it triggers an auto-scaling policy that launches a second EC2 instance. This way, the site handles the evening rush automatically.
One evening, your phone buzzes with an alarm: CPU is at 95%. You check the logs and see a new error message: 'Connection pool exhausted'. A recent code deploy accidentally set the database connection pool size too low. You roll back the code, and within minutes the alarm clears. Without CloudWatch metrics, logs, and alarms working together, you might have discovered this problem only when customers started emailing angry complaints the next morning.
For the exam, you should be comfortable with this workflow: identify symptoms (metrics), investigate cause (logs), and take action (alarms). You should also know that CloudWatch Alarms can be in three states: OK (metric within threshold), ALARM (metric crossed threshold), and INSUFFICIENT_DATA (not enough data points yet). That distinction matters for exam questions about alarm states.
For the DVA-C02 exam, Domain 4 includes about 20% of the total questions, and CloudWatch is the star of this domain. The exam expects you to understand exactly how Metrics, Log Groups, and Alarms work together, and they love to test the boundaries between these concepts. Here is what you must master:
Metrics focus:
Metrics are time-series data points. They have a namespace (like 'AWS/EC2'), a metric name (like 'CPUUtilization'), and dimensions (like InstanceId). Dimensions are name-value pairs that let you drill into specific resources.
You can publish your own custom metrics using the PutMetricData API. The exam will ask when to use custom metrics vs default metrics. For instance, you would use a custom metric to track the number of active users or the size of an order queue.
Key detail: Metrics are stored for 15 months. Older data is aggregated with lower resolution (1-minute data after 15 days, 5-minute data after 63 days, etc.). Questions may ask about data retention limits.
Trap: A question might say 'store every HTTP response code for analysis' — the correct answer is to send those counts as a custom metric, not to store each response as a log line. Metrics are designed for numerical data, not text.
Log groups and log streams:
A log group is a container for logs from a single source. Each log group contains multiple log streams. For example, a Lambda function creates a log group with one log stream per concurrent invocation.
Logs have a retention policy. By default, logs never expire, but you can set a retention period (1 day to 10 years). The exam may ask what happens if you do not set retention — logs persist forever and keep accruing costs.
Logs Insights is a query tool. You can use a simple query language like 'fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc' to find errors. Know that Logs Insights queries run against data in the log group.
Common trap: confusing log groups with log streams. A question might say 'all logs from the application are in the same log stream' — that is wrong if the application uses multiple servers; each server should have its own log stream inside a common log group.
Alarms:
Alarms watch a single metric (or a math expression combining metrics). The alarm transitions between three states: OK, ALARM, and INSUFFICIENT_DATA.
The alarm can trigger an SNS topic, which in turn sends email, SMS, or triggers a Lambda function. Know that SNS is the primary way to get notified.
Alarms can also trigger Auto Scaling actions. The exam may ask what to use to automatically add more EC2 instances when CPU is high — answer: a CloudWatch alarm with an Auto Scaling policy.
Trap: Alarms do not directly stop EC2 instances unless you configure a Lambda function or use Systems Manager automation. A question may present 'Create a CloudWatch alarm that stops the EC2 instance' — that is not possible natively; you need an intermediate action.
Common exam patterns:
Given a scenario where an application is slow, which CloudWatch feature do you use first? Answer: Check the CPU metric. Then logs to find the slow query.
How to monitor a custom application metric? Use PutMetricData API.
How to get notified when error logs appear? Create a metric filter on the log group that counts error messages, then create an alarm on that custom metric.
Memorise these three key definitions:
Metric filter: parses log data and turns matching log events into numerical metrics. For example, count how many times 'ERROR' appears in logs per minute.
CloudWatch agent: a software package you install on EC2 or on-premises servers to collect custom metrics and logs. The default EC2 metrics do not include memory usage; you need the CloudWatch agent to collect memory metrics.
Composite alarm: an alarm that uses a rule to combine multiple alarms. For example, trigger when CPU is high AND memory is high. This reduces noise from single-metric spikes.
CloudWatch Metrics store numerical time-series data (e.g., CPU, latency) and are cost-effective for tracking trends over months.
CloudWatch Log Groups hold text-based log events from a single source, containing multiple Log Streams for individual instances or invocations.
CloudWatch Alarms monitor a single metric and transition to ALARM state when a threshold is breached for a specified number of evaluation periods.
Custom metrics are published using the PutMetricData API and are essential for tracking application-specific values like shopping cart size or queue depth.
A metric filter converts log data into a metric, enabling alarms on the frequency of specific log events like error messages.
Default EC2 metrics do not include memory or disk usage — you must install the CloudWatch Agent to collect OS-level metrics.
Alarms can trigger SNS topics (notifications) or Auto Scaling actions but cannot directly restart services without additional automation.
Log Insights is a query engine for searching and analysing log data across log groups using a SQL-like syntax.
These come up on the exam all the time. Here's how to tell them apart.
Metric
Numerical time-series data (e.g., CPU 75%)
Low storage cost per data point
Best for trend analysis and alarms
Log
Text-based event record (e.g., error stack trace)
Higher storage cost per entry
Best for detailed debugging and root cause analysis
Default Metric (e.g., CPUUtilization)
Automatically sent by AWS services like EC2
No code changes needed to collect
Limited to what AWS exposes (no memory, no app-level data)
Custom Metric (e.g., ActiveUsers)
Sent by your own application code via PutMetricData API
Requires coding and IAM permissions
Can measure anything your app cares about (queue size, latency, etc.)
Single Alarm
Watches one metric against one threshold
Simple to set up and debug
Prone to false alarms if metric briefly spikes
Composite Alarm
Combines multiple alarms using AND/OR logic
Reduces false positives by requiring multiple conditions
More complex to configure and costs twice as many alarms
CloudWatch Logs
Stores raw log data from applications and services
Capacity to ingest and store terabytes of logs
You can only view recent events via the console's 'search' tab
CloudWatch Logs Insights
Query engine that runs SQL-like queries against log data
Designed for interactive analysis and pattern finding
Can scan months of data quickly to find specific errors
Mistake
CloudWatch logs are automatically deleted after 30 days if I do nothing.
Correct
The default retention of log data is 'never expire', meaning logs accumulate indefinitely and incur ongoing storage costs unless you explicitly set a retention policy.
Many beginners assume AWS applies a default auto-cleanup to save money, but AWS prioritises data preservation to avoid accidental loss, which can lead to unexpected bills.
Mistake
A CloudWatch alarm can fix the problem automatically, like restarting a failed service, without any additional setup.
Correct
An alarm itself only changes state and triggers a notification or an action via SNS, not directly. To restart a service, you need to configure a Lambda function or a Systems Manager automation as the alarm target.
The name 'alarm' sounds proactive, leading people to think it includes built-in remediation, when in reality it is just a trigger mechanism.
Mistake
I can use the same metric filter for both metrics and logs — they are essentially the same thing filtered differently.
Correct
A metric filter is a feature that extracts numerical data from log events to create a metric. It is not the same as searching logs; metrics are numerical time series, while logs are raw text. You cannot use a metric filter to search for text in logs.
The term 'filter' is vague, and beginners conflate CloudWatch Logs Insights queries (which search text) with metric filters (which create numbers).
Mistake
CloudWatch automatically monitors memory usage for EC2 instances out of the box.
Correct
Default EC2 metrics include CPU, network, and disk, but not memory. To monitor memory, you must install the CloudWatch agent and configure custom metrics.
Users assume because CPU and disk are captured, memory would be equally basic, but AWS requires explicit configuration due to the overhead of collecting that data from guest OS.
Mistake
If I set a CloudWatch alarm to trigger when CPU exceeds 80% for 5 minutes, the alarm will fire the moment the average CPU hits 80% at any point in those 5 minutes.
Correct
The alarm evaluates the metric over a period (e.g., 5 consecutive minutes). It uses the evaluation period setting; for instance, 3 out of 5 data points above threshold. It does not average the entire window only once.
People misunderstand 'period' as a single check rather than a sliding window of data points, causing confusion about why alarms sometimes fire late or not at all.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A metric is a single number measured over time, like CPU utilisation or request count. A log is a detailed text message describing an event, like an error message with a stack trace. Use metrics for tracking trends and thresholds, and logs for debugging exactly what happened.
Yes, CloudWatch Logs charges for data ingestion (sending logs) and data storage. You can reduce costs by setting a retention policy to automatically delete old logs after a certain number of days. Default retention is 'never expire', which can lead to high costs over time.
EC2 does not send memory metrics by default. You must install the CloudWatch Agent on the instance and configure it to collect memory metrics. The agent sends data as custom metrics, which you can then graph or set alarms on.
INSUFFICIENT_DATA means the alarm has not received enough data points to evaluate the threshold — often because the metric source is newly launched or temporarily unavailable. The alarm does not trigger any action in this state. It waits until there is enough data to move to OK or ALARM.
Not directly. Alarms can only send notifications via SNS or trigger Auto Scaling, Lambda, or Systems Manager actions. To restart an application, you would create a Lambda function that runs the restart command, and configure the alarm to invoke that Lambda function.
Use the PutMetricData API from the AWS SDK in your code. You define a namespace, metric name, value, and optional dimensions (like environment or version). For example, in Python with boto3, you call cloudwatch.put_metric_data(Namespace='MyApp', MetricData=[{'MetricName': 'ActiveUsers', 'Value': 150}]).
You've just covered CloudWatch Metrics, Logs, and Alarms for Application Monitoring — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?