This chapter covers Amazon CloudWatch Alarms and Dashboards, two essential monitoring tools for AWS environments. For the CLF-C02 exam, this falls under Domain 3: Cloud Technology Services, Objective 3.5: Identify the purposes of AWS services used in monitoring and reporting. This objective represents about 12-15% of the exam questions. Understanding CloudWatch Alarms and Dashboards is critical because they enable proactive operational health monitoring, automated incident response, and cost optimization—all key responsibilities of a cloud practitioner.
Jump to a section
Imagine you manage a large office building. You need to monitor temperature, humidity, and energy usage across every floor. Instead of walking around with a clipboard, you install smart sensors in each room. These sensors constantly send data to a central dashboard. You set thresholds: if any room exceeds 75°F, the system sends an alert to your phone. Additionally, you create rules: if the entire building's energy consumption spikes above normal, the system automatically adjusts the HVAC to reduce load. This is exactly how CloudWatch Alarms and Dashboards work. CloudWatch collects metrics (like CPU usage, disk reads, and network traffic) from your AWS resources. You create alarms that trigger actions when a metric crosses a threshold—like sending an SNS notification or auto-scaling your EC2 fleet. Dashboards provide a real-time view of all your critical metrics in one place, just like the building manager's central console. The mechanism is the same: sensors (CloudWatch agents), thresholds (alarms), and automated responses (actions). The only difference is that AWS resources are virtual, so the 'sensors' are software-based and can be deployed at scale across thousands of instances.
What CloudWatch Alarms and Dashboards Are and the Problem They Solve
Amazon CloudWatch is the native monitoring service for AWS. It collects and tracks metrics, logs, and events from your AWS resources and applications. CloudWatch Alarms allow you to watch a single metric or a math expression based on multiple metrics over a specified time period. When the metric breaches a defined threshold, the alarm triggers one or more actions—such as sending a notification via Amazon Simple Notification Service (SNS), executing an Auto Scaling policy, or performing an EC2 action (stop, terminate, reboot, or recover). CloudWatch Dashboards are customizable pages in the CloudWatch console that display graphs and other widgets for your metrics, allowing you to create a unified view of your environment.
The core problem CloudWatch Alarms solve is the need for automated, real-time response to changing conditions. Without alarms, you would have to manually check metrics and react after a problem has already impacted users. Alarms enable proactive detection and automated remediation. Dashboards solve the problem of scattered data—instead of logging into each resource console to see metrics, you can aggregate them into a single pane of glass.
How CloudWatch Alarms Work – The Mechanism
A CloudWatch Alarm is essentially a state machine. It has three possible states: - OK: The metric is within the defined threshold. - ALARM: The metric has breached the threshold for a specified number of consecutive evaluation periods. - INSUFFICIENT_DATA: Not enough data is available to determine the state (e.g., the metric hasn't been reported for the period).
When you create an alarm, you specify: - Metric: The metric to monitor (e.g., AWS/EC2 CPUUtilization). - Statistic: How to aggregate the data points over each period (e.g., Average, Sum, Minimum, Maximum, SampleCount, or percentile). - Period: The length of time (in seconds) to evaluate the metric (e.g., 60 seconds, 300 seconds). The default is 300 seconds (5 minutes) for basic monitoring, but you can use 60 seconds for detailed monitoring. - Evaluation Periods: The number of most recent periods to evaluate. The alarm transitions to ALARM only when the metric breaches the threshold for the specified number of consecutive periods. - Datapoints to Alarm: The number of data points within the evaluation periods that must be breaching to trigger the alarm. This allows you to define a "M out of N" condition. - Threshold: The value that triggers the alarm (e.g., CPUUtilization > 80). - Actions: One or more actions to take when the alarm enters ALARM, OK, or INSUFFICIENT_DATA states. Common actions include:
Sending a notification to an SNS topic.
Executing an Auto Scaling policy (e.g., scale out).
Performing an EC2 action: stop, terminate, reboot, or recover (recover moves the instance to a new host).
Triggering a Lambda function for custom logic.
Creating a Systems Manager OpsItem.
Behind the scenes: CloudWatch continuously receives metric data points from sources like EC2, load balancers, RDS, and custom applications. When you create an alarm, CloudWatch evaluates the metric against the threshold every period. If the condition is met for the required number of evaluation periods, the alarm state changes to ALARM, and the associated actions are executed. The alarm remains in ALARM until the metric returns to OK for the required number of evaluation periods.
Key Tiers, Configurations, and Pricing
CloudWatch Alarms are priced per alarm per month. As of the CLF-C02 exam, pricing is approximately $0.10 per alarm per month for standard resolution alarms (evaluation period of 60 seconds or more). High-resolution alarms (period of 10 seconds or 30 seconds) cost more. There is no charge for alarms in the INSUFFICIENT_DATA state.
CloudWatch Dashboards are free for the first three dashboards per account (each with up to 50 widgets). Additional dashboards cost $3 per dashboard per month. Cross-account dashboards are also supported, allowing you to view metrics from multiple AWS accounts in a single dashboard.
Comparison to On-Premises or Competing Approaches
In an on-premises data center, you might use tools like Nagios, Zabbix, or PRTG to monitor servers and network devices. These tools require you to install agents, configure thresholds, and set up alerting. CloudWatch Alarms are similar in concept but are fully managed and deeply integrated with AWS services. For example, an alarm on an EC2 instance's CPUUtilization can automatically trigger an Auto Scaling policy to add more instances—a capability that would require custom scripting in an on-premises environment.
Competing cloud monitoring services include Azure Monitor and Google Cloud Monitoring. CloudWatch is native to AWS and offers the tightest integration with services like EC2, RDS, Lambda, and ELB. One key differentiator is CloudWatch's ability to monitor custom metrics (via the PutMetricData API) and to perform metric math (e.g., combining multiple metrics into a single expression).
When to Use CloudWatch Alarms vs Alternatives
CloudWatch Alarms are ideal for:
Monitoring standard AWS metrics (CPU, memory, disk I/O, network).
Triggering automated actions like Auto Scaling or EC2 recovery.
Sending notifications for operational issues.
Creating composite alarms that combine multiple conditions.
Alternatives include: - AWS Config: For configuration compliance, not real-time performance metrics. - AWS Trusted Advisor: For best-practice checks, not real-time monitoring. - Third-party tools (e.g., Datadog, New Relic): For advanced analytics and cross-cloud monitoring.
CloudWatch Dashboards are best for:
Creating a centralized view of key metrics for your operations team.
Sharing with stakeholders via a read-only URL (without AWS console access).
Quick troubleshooting by viewing metrics from multiple resources in one place.
Use third-party dashboards if you need advanced visualization, multi-cloud support, or custom data sources beyond CloudWatch.
Create a CloudWatch Alarm
Open the CloudWatch console and navigate to Alarms > All alarms. Click 'Create alarm'. First, select the metric you want to monitor. You can browse by service (e.g., EC2, RDS) or search for a specific metric like 'CPUUtilization'. After selecting the metric, you specify the statistic (e.g., Average) and the period (e.g., 5 minutes). Then, set the threshold type: 'Static' uses a fixed value (e.g., > 80), while 'Anomaly detection' uses machine learning to create a band of expected values. For a static threshold, enter the threshold value and select the condition (e.g., Greater than threshold). Next, configure the alarm state trigger: choose how many evaluation periods (consecutive data points) must breach the threshold to trigger the alarm. For example, 1 out of 1 means a single breach triggers; 3 out of 3 means three consecutive breaches. Finally, configure actions: select an SNS topic to send a notification, or choose an EC2 action or Auto Scaling policy. Give the alarm a name and description, then click 'Create alarm'.
Configure SNS Notification
To receive notifications from CloudWatch Alarms, you need an Amazon SNS topic. In the SNS console, create a topic (e.g., 'CloudWatch-Alerts'). Choose a standard topic (not FIFO) for alarm notifications. Then, create a subscription: choose protocol (email, SMS, HTTP, Lambda, etc.) and enter the endpoint (e.g., your email address). Confirm the subscription (for email, click the link in the confirmation email). When you create the alarm, you select this SNS topic as the action. When the alarm state changes to ALARM, CloudWatch publishes a message to the topic, which SNS delivers to all subscribers. You can also use SNS to trigger Lambda functions or send messages to other systems. For the exam, remember that SNS is the primary way to send notifications from CloudWatch Alarms.
Create a CloudWatch Dashboard
In the CloudWatch console, go to Dashboards and click 'Create dashboard'. Enter a name (e.g., 'Production-Overview'). You can choose to create a new dashboard or use a template. After creation, you add widgets. Click 'Add widget' and select a widget type: Line, Stacked area, Number, Text, or Alarm status. For metrics, select 'Line' and then choose the metrics you want to graph. You can select multiple metrics from different services (e.g., CPUUtilization from several EC2 instances and RequestCount from an ALB). Customize the time range, statistic, and period. You can also add a text widget for notes or links. Arrange widgets on the grid. Dashboards can be shared via a public URL (read-only) or with specific AWS accounts. Dashboards support automatic refresh, and you can set a refresh interval (e.g., 10 seconds, 1 minute). For the exam, know that dashboards are created in the CloudWatch console and can display metrics from any region (cross-region) and any account (cross-account).
Test the Alarm and Dashboard
After creating an alarm, it's important to test that it fires correctly. You can manually trigger an alarm by generating load on the monitored resource. For example, for a CPU alarm, you can run a stress tool on an EC2 instance. Alternatively, you can use the CloudWatch console to 'Set alarm state' to ALARM for testing purposes (this does not actually change the metric but triggers the actions). Verify that the SNS notification is received, or that the Auto Scaling policy executes. For dashboards, ensure the metrics are populating correctly. Check that the time range shows recent data. You can also use the 'Automated Dashboards' feature to create a dashboard automatically from a CloudFormation stack. Testing is critical because misconfigured alarms can lead to false positives (unnecessary alerts) or false negatives (missed issues).
Monitor and Optimize Alarms
Once alarms are active, regularly review their performance. Use CloudWatch Logs Insights to analyze alarm history. Look for alarms that are frequently in ALARM state (possible threshold too low) or never in ALARM (threshold too high or metric not being emitted). You can also set up composite alarms that combine multiple conditions—for example, trigger ALARM only if both CPU > 80% AND memory > 90%. Composite alarms reduce noise. For cost optimization, consider that each alarm costs $0.10/month. Delete unused alarms. Use high-resolution alarms only when needed (e.g., for critical systems). Also, consider setting up an alarm on the 'EstimatedCharges' metric to monitor cost spikes. The exam often tests that you can alarm on billing metrics, but only the root user or an IAM user with billing permissions can view billing data.
Scenario 1: E-commerce Auto Scaling An e-commerce company runs a website on EC2 behind an Application Load Balancer (ALB). During flash sales, traffic spikes unexpectedly. They configure a CloudWatch Alarm on the ALB's 'RequestCountPerTarget' metric. If the average request count per EC2 instance exceeds 1000 requests per minute for 3 consecutive periods (5 minutes each), the alarm triggers an Auto Scaling policy to launch additional EC2 instances. This ensures the site stays responsive. Without this alarm, traffic spikes could cause slow page loads or outages, leading to lost revenue. The cost of the alarm is negligible compared to the cost of downtime. Misconfiguration example: setting the threshold too low (e.g., 100 requests) would trigger unnecessary scaling, increasing costs. Setting it too high (e.g., 5000 requests) would cause slow response before scaling kicks in.
Scenario 2: Database Recovery Monitoring A financial services company uses Amazon RDS for their transactional database. They need to ensure high availability. They create a CloudWatch Alarm on the 'DatabaseConnections' metric with a threshold of > 500 connections for 5 minutes. If breached, the alarm triggers an EC2 instance recovery action (not applicable to RDS directly, but they use a Lambda function to restart the RDS instance). Additionally, they have a dashboard showing key RDS metrics: CPU, memory, free storage space, and read/write latency. The operations team monitors this dashboard 24/7. One day, free storage drops below 10 GB, triggering an alarm that notifies the DBA via SNS. The DBA increases storage before the database runs out of space. Without this alarm, the database could become read-only, causing application failures. Misconfiguration: if they set the alarm on 'FreeStorageSpace' with a threshold of < 1 GB, they might not have enough time to react before the database locks.
Scenario 3: Cost Anomaly Detection A startup uses multiple AWS services and wants to avoid surprise bills. They enable billing metrics in the Billing console and create a CloudWatch Alarm on the 'EstimatedCharges' metric (in the AWS/Billing namespace). The alarm triggers if the estimated cost exceeds $5000 in a month. When it triggers, it sends an SNS email to the finance team. They also have a dashboard showing daily cost trends by service. This helps them catch cost spikes early. For example, if a developer leaves a large EC2 instance running over the weekend, the cost alarm will alert them. Without this alarm, they might not notice until the end of the month. Misconfiguration: forgetting to enable billing metrics (they are disabled by default) means the alarm will never fire. Also, the 'EstimatedCharges' metric updates only a few times per day, so it's not real-time.
Exactly What CLF-C02 Tests on This Objective The CLF-C02 exam tests your ability to identify the purpose and features of CloudWatch Alarms and Dashboards as part of monitoring and reporting. Specifically, you should know:
The three states of an alarm: OK, ALARM, INSUFFICIENT_DATA.
That alarms can trigger actions: SNS notifications, Auto Scaling policies, EC2 actions (stop, terminate, reboot, recover), and Lambda functions.
That you can create alarms on any CloudWatch metric, including custom metrics.
That CloudWatch Dashboards provide a customizable view of metrics and can include text, graphs, and alarm status widgets.
That dashboards can be shared publicly (read-only) or cross-account.
That billing alarms require enabling billing metrics in the Billing console (root user or IAM with billing permissions).
The difference between standard (1-minute) and detailed (5-minute) monitoring for EC2.
Common Wrong Answers and Why Candidates Choose Them 1. "CloudWatch Alarms can automatically patch EC2 instances." – Wrong. Patching is done via Systems Manager Patch Manager, not CloudWatch Alarms. Candidates confuse the action types. 2. "Dashboards can be used to modify resources directly." – Wrong. Dashboards are read-only views. Candidates think because you see metrics, you can click to change resources. 3. "Alarms can be created in CloudWatch Logs." – Wrong. Alarms are created on metrics, not logs. Logs can be used to create metric filters, which then can be alarmed, but alarms themselves are not created in Logs. 4. "EC2 basic monitoring provides 1-minute metrics." – Wrong. Basic monitoring is 5-minute; detailed monitoring is 1-minute. Candidates often reverse them. 5. "A composite alarm can include alarms from different regions." – Wrong. Composite alarms can only include alarms from the same region. Candidates think cross-region is possible.
Specific Terms and Values to Memorize - Alarm states: OK, ALARM, INSUFFICIENT_DATA. - Default EC2 monitoring: 5-minute periods (basic), 1-minute (detailed) at extra cost. - CloudWatch Dashboard default: up to 50 widgets per dashboard. - Billing alarm: must be in the US East (N. Virginia) region (us-east-1) for the EstimatedCharges metric. - SNS is the typical notification action. - Auto Scaling policies can be triggered by alarms.
Tricky Distinctions - CloudWatch Alarms vs. AWS Config Rules: Alarms are for performance and operational metrics; Config Rules are for configuration compliance. - CloudWatch Dashboards vs. QuickSight: Dashboards are for real-time operational metrics; QuickSight is for business analytics and reporting. - CloudWatch Alarms vs. EventBridge: Alarms are metric-based; EventBridge is event-driven (e.g., state changes, API calls).
Decision Rule for Multi-Choice Questions If a question asks about automated actions based on a metric threshold, the answer is CloudWatch Alarm. If it asks about a visual aggregation of metrics, the answer is CloudWatch Dashboard. If it asks about notifications, think SNS. If it asks about configuration compliance, think AWS Config. If it asks about scheduling actions, think EventBridge.
CloudWatch Alarms have three states: OK, ALARM, INSUFFICIENT_DATA.
Alarms can trigger SNS notifications, Auto Scaling policies, EC2 actions, and Lambda functions.
Default EC2 monitoring period is 5 minutes (basic); detailed monitoring is 1 minute (extra cost).
CloudWatch Dashboards are customizable, read-only views that can include metrics from multiple regions and accounts.
Billing alarms must be created in the us-east-1 region and require billing metrics to be enabled.
Composite alarms combine multiple alarms into a single ALARM state, reducing noise.
CloudWatch Alarms cost $0.10 per alarm per month (standard resolution).
These come up on the exam all the time. Here's how to tell them apart.
CloudWatch Alarms
Monitor performance metrics like CPU, memory, and request counts.
Trigger actions like Auto Scaling or SNS notifications.
Have states: OK, ALARM, INSUFFICIENT_DATA.
Based on time-series metric data.
Can be used for proactive auto-scaling and recovery.
AWS Config Rules
Monitor configuration compliance (e.g., whether EBS volumes are encrypted).
Trigger actions like SNS notifications or auto-remediation via Systems Manager.
Have states: Compliant, Non-compliant.
Based on resource configuration and rules.
Used for security and compliance auditing.
Mistake
CloudWatch Alarms can monitor memory utilization by default on EC2.
Correct
By default, EC2 only sends hypervisor-level metrics: CPU, disk, network. Memory is a guest OS metric and requires the CloudWatch agent to be installed on the instance.
Mistake
You can create an alarm on any CloudWatch log group directly.
Correct
Alarms are based on metrics, not logs. To alarm on log data, you must first create a metric filter on the log group that extracts a metric, then create an alarm on that metric.
Mistake
CloudWatch Dashboards can be used to perform actions like stopping an instance.
Correct
Dashboards are read-only views. They display metrics and alarm status but do not allow direct modification of resources. Actions require separate services like AWS Console, CLI, or SDK.
Mistake
A billing alarm can be created in any region.
Correct
Billing metrics (EstimatedCharges) are only available in the US East (N. Virginia) region (us-east-1). You must create the alarm in that region.
Mistake
Alarms in the ALARM state incur additional charges.
Correct
Charges are per alarm per month regardless of state. There is no extra charge for being in ALARM state. However, actions like SNS notifications may incur their own costs.
Open CloudWatch console, go to Alarms, click Create alarm, select the EC2 metric CPUUtilization, set the statistic (e.g., Average), period (e.g., 5 minutes), threshold (e.g., > 80%), choose evaluation periods (e.g., 2 out of 2), and configure actions like sending an SNS notification. The alarm will transition to ALARM when CPU exceeds 80% for two consecutive 5-minute periods.
CloudWatch Alarms are metric-based: they trigger when a metric crosses a threshold. EventBridge is event-driven: it reacts to state changes or API calls (e.g., EC2 instance state change, S3 object creation). Alarms are for performance thresholds; EventBridge is for operational events. Both can trigger actions like Lambda or SNS.
Yes, you can share a dashboard publicly by generating a shareable link. The dashboard will be read-only and accessible without authentication. However, you must ensure you are not exposing sensitive data. You can also share with specific AWS accounts using cross-account sharing.
First, enable billing metrics in the Billing console (root user or IAM with billing permissions). Then, go to CloudWatch in the us-east-1 region, create an alarm on the AWS/Billing namespace, select EstimatedCharges metric, set a threshold (e.g., > $1000), and configure an SNS notification. The alarm will alert you when your estimated charges exceed that amount.
A composite alarm uses a rule expression that includes multiple other alarms. For example, ALARM(CPUHigh) AND ALARM(MemoryHigh). It reduces noise by only triggering when multiple conditions are met. Use it when you want to avoid false positives from a single metric spike.
Yes, CloudWatch Alarms support anomaly detection. Instead of a static threshold, you can use a machine learning model that establishes a band of expected values. The alarm triggers when the metric falls outside this band. This is useful for metrics with seasonal patterns (e.g., web traffic).
If CloudWatch does not receive enough metric data points to evaluate the alarm, it enters the INSUFFICIENT_DATA state. This can happen if the resource is stopped or the metric is not being emitted. You can configure actions to trigger on this state (e.g., notify that data is missing).
You've just covered CloudWatch Alarms and Dashboards — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?