Amazon CloudWatch Metrics, Alarms, Logs, and Automation – SAP-C02 Study Guide

Purpose of This Lesson

Amazon CloudWatch is AWS’s central monitoring and observability service. It collects metrics and logs, evaluates alarm conditions, and can trigger automated responses when a system crosses an operational threshold.

For SAP-C02, CloudWatch is important because it connects operational visibility with architecture decisions. Monitoring data can support scaling, resource optimization, incident detection, and automated remediation across AWS and on-premises environments.

Key Concepts

CloudWatch’s Core Capabilities

CloudWatch provides several related capabilities:

• Metrics: Time-ordered numerical data points generated by AWS services, applications, agents, or custom integrations.
• Alarms: Rules that evaluate metrics and initiate actions when conditions are met.
• Logs: Centralized collection and analysis of system and application log data.
• Events: Notifications describing changes in AWS resources that can trigger actions. CloudWatch Events has largely been superseded by Amazon EventBridge.

CloudWatch can monitor AWS resources and, with the appropriate agent or integration, systems running in on-premises environments.

AWS Service Metrics

Many AWS services publish metrics to CloudWatch automatically. For example, EC2 publishes infrastructure-level metrics such as:

• CPU utilization
• Network traffic
• Disk read operations
• Instance status checks

EC2 monitoring frequency depends on the monitoring mode:

EC2 monitoring mode	Metric interval	Cost consideration
Basic monitoring	Typically 5 minutes	Included for supported standard metrics
Detailed monitoring	1 minute	Additional charges apply

A shorter interval provides faster visibility and can improve the responsiveness of metric-based scaling or alerting, but it increases monitoring cost.

EC2 Memory and Disk Utilization

EC2’s standard AWS-provided metrics do not include guest operating system metrics such as:

• Memory utilization
• Filesystem or disk-space utilization
• Other operating-system-level statistics

To publish these metrics, install and configure the CloudWatch agent on the EC2 instance. The unified CloudWatch agent can also collect system-level metrics from on-premises servers.

This distinction is a common exam issue: an alarm for EC2 memory utilization cannot be created from the default EC2 metric set unless an agent or another custom-metric publishing mechanism supplies the data.

Custom Metrics and Resolution

Applications and infrastructure can publish custom metrics using the CloudWatch API or AWS CLI. Custom metrics support different resolutions:

• Standard resolution: One-minute granularity.
• High resolution: One-second granularity.

High-resolution metrics can support faster detection and response, but they generally have higher monitoring and storage costs. Use them when the operational requirement justifies the additional expense.

CloudWatch Alarms

A CloudWatch alarm evaluates a metric or alarm expression over one or more evaluation periods. It can notify another AWS service or initiate an operational action when a condition is met.

Alarm states include:

• OK: The metric is within the configured acceptable range.
• ALARM: The metric has breached the configured condition.
• INSUFFICIENT_DATA: CloudWatch does not have enough data to determine the current state.

Alarm actions can support use cases such as:

• Triggering an Auto Scaling policy
• Sending a notification
• Initiating an automated operational response

Two important alarm types are:

• Metric alarm: Evaluates a single metric, potentially using its configured statistic and threshold.
• Composite alarm: Evaluates a rule based on multiple existing alarms, which can reduce noisy alerts and represent higher-level conditions.

The SetAlarmState API or CLI operation can be used to set an alarm’s state, commonly for testing alarm actions. It does not publish a custom metric; custom metrics are published separately through the CloudWatch API or CLI.

CloudWatch and Auto Scaling

A common architecture pattern is:

1. EC2 publishes CPU utilization or another metric to CloudWatch.
2. A CloudWatch alarm evaluates the metric.
3. The alarm invokes an Auto Scaling policy.
4. Auto Scaling launches or terminates EC2 instances through the appropriate EC2 operations.

This separates observation from action: CloudWatch detects the condition, while Auto Scaling implements the capacity change.

Exam-Relevant Takeaways

• EC2 basic monitoring is generally five-minute monitoring; detailed monitoring provides one-minute intervals for an additional charge.
• Default EC2 metrics include infrastructure data such as CPU, network, disk operations, and status checks.
• Memory and filesystem utilization are not standard EC2 metrics. Use the CloudWatch agent or publish custom metrics.
• The unified CloudWatch agent can collect operating-system metrics from EC2 and on-premises servers.
• CloudWatch alarms can initiate actions when thresholds or alarm expressions are met.
• A composite alarm combines the states of multiple alarms rather than directly evaluating one raw metric.
• OK, ALARM, and INSUFFICIENT_DATA are the primary CloudWatch alarm states.
• Standard custom metrics have one-minute granularity; high-resolution custom metrics can provide one-second granularity.
• CloudWatch Events is the legacy event service name; Amazon EventBridge is the current service for event-driven resource change processing.
• Monitoring interval and metric resolution are architecture tradeoffs involving detection speed, response time, and cost.

Architecture Decision Guide

Requirement	Appropriate CloudWatch capability	Important consideration
Monitor EC2 CPU or network utilization	Built-in EC2 CloudWatch metrics	Choose basic or detailed monitoring based on response-time needs
Monitor EC2 memory usage	CloudWatch agent or custom metric publisher	The default EC2 metrics do not provide guest memory usage
Monitor disk-space consumption	CloudWatch agent or custom metric publisher	Disk operations and disk space are different measurements
Scale an EC2 fleet based on utilization	CloudWatch metric alarm with Auto Scaling	Select an evaluation period that avoids excessive or delayed scaling
Combine several operational conditions	Composite alarm	Useful for reducing alert noise and representing a higher-level incident
Collect application or system logs centrally	CloudWatch Logs and an appropriate agent or integration	Configure collection, retention, and access controls separately
Detect changes to AWS resources and route events	Amazon EventBridge	CloudWatch Events is the legacy terminology
Measure application-specific behavior	Custom CloudWatch metric	Choose standard or high resolution according to the required response time
Monitor on-premises operating-system metrics	Unified CloudWatch agent	Requires connectivity, installation, and correct agent configuration

Common Exam Traps

• Assuming EC2 publishes memory utilization automatically: It does not. Install the CloudWatch agent or publish a custom metric.
• Confusing disk operations with disk capacity: EC2 disk read/write metrics do not tell you how much filesystem space remains.
• Choosing detailed monitoring without a requirement for faster data: One-minute monitoring costs more and should be justified by the scaling or alerting requirement.
• Treating INSUFFICIENT_DATA as a healthy state: It means CloudWatch cannot currently determine whether the metric satisfies the alarm condition.
• Using a metric alarm when multiple conditions must be combined: A composite alarm is designed to evaluate multiple alarm states.
• Confusing CloudWatch Events with EventBridge: EventBridge is the current event bus and event-routing service name.
• Assuming a CloudWatch alarm performs the capacity change itself: The alarm typically invokes a target such as an Auto Scaling policy, which performs the scaling action.
• Using high-resolution metrics everywhere: One-second data may be unnecessary for slower-moving operational signals and can increase cost.
• Confusing custom metrics with alarm state testing: Publishing a custom metric and calling SetAlarmState are separate operations.

Real-World Engineer Notes

• Define the operational objective before selecting the monitoring interval. A workload that can tolerate several minutes of delay may not need detailed monitoring.
• Memory and filesystem utilization are often more useful for capacity planning than CPU alone, especially for memory-bound applications or instances with constrained storage.
• Alarm thresholds should account for normal workload variability. A threshold that is too sensitive can cause scaling oscillation or alert fatigue.
• Composite alarms can help suppress secondary alerts when a broader infrastructure failure already explains multiple symptoms.
• Standardize CloudWatch agent configuration across instance fleets using automation rather than configuring hosts manually.
• Treat monitoring as part of the architecture. Metric collection, log collection, alarm actions, permissions, retention, and cost controls all require explicit design.
• When monitoring on-premises servers, validate network connectivity, agent permissions, metric namespaces, and the impact of collection frequency before deploying at scale.

Quick Reference Summary

• CloudWatch metrics: Numerical, time-ordered data points.
• EC2 basic monitoring: Usually five-minute intervals.
• EC2 detailed monitoring: One-minute intervals for an additional charge.
• CloudWatch agent: Required for common guest OS metrics such as memory and filesystem utilization.
• Custom metrics: Published through the API or CLI; standard or high resolution.
• Metric alarm: Evaluates a metric and can initiate an action.
• Composite alarm: Evaluates multiple alarm states.
• Alarm states: OK, ALARM, and INSUFFICIENT_DATA.
• Scaling pattern: CloudWatch metric → alarm → Auto Scaling policy → EC2 capacity change.
• Event service terminology: Prefer Amazon EventBridge over the legacy CloudWatch Events name.

Flashcards

1. Q: What is Amazon CloudWatch used for?

A: Monitoring metrics and logs, evaluating alarms, providing operational visibility, and triggering automated responses.

1. Q: What is the default EC2 metric interval for basic monitoring?

A: Typically five minutes.

1. Q: What interval does EC2 detailed monitoring provide?

A: One minute, for an additional charge.

1. Q: Does default EC2 monitoring include memory utilization?

A: No. Use the CloudWatch agent or publish a custom metric.

1. Q: What does the unified CloudWatch agent collect?

A: System-level metrics such as memory and disk utilization from EC2 and on-premises servers, along with other configured data.

1. Q: What are the three primary CloudWatch alarm states?

A: OK, ALARM, and INSUFFICIENT_DATA.

1. Q: What is a composite alarm?

A: An alarm that evaluates a rule based on multiple existing alarms.

1. Q: What is the difference between standard- and high-resolution custom metrics?

A: Standard resolution provides one-minute granularity, while high resolution can provide one-second granularity.

1. Q: How can CloudWatch support EC2 scaling?

A: A metric alarm can invoke an Auto Scaling policy when a threshold is reached.

1. Q: What service replaced CloudWatch Events terminology?

A: Amazon EventBridge.

1. Q: What does INSUFFICIENT_DATA mean?

A: CloudWatch has not received enough information to determine the alarm state.

1. Q: What does SetAlarmState do?

A: It sets an alarm’s state, commonly for testing alarm actions; it does not publish a custom metric.

Practice Questions

Question 1

A company runs a fleet of Linux EC2 instances. The operations team needs an alarm when the average filesystem utilization on the root volume exceeds 85%. The instances currently use only default EC2 monitoring.

What should the solutions architect recommend?

A. Create a CloudWatch alarm directly on the default EC2 disk read operations metric.
B. Enable EC2 detailed monitoring.
C. Install and configure the unified CloudWatch agent to publish filesystem utilization.
D. Create a composite alarm using CPU and network metrics.

Correct answer: C

Explanation: Default EC2 metrics do not provide guest filesystem utilization. Detailed monitoring changes the frequency of supported metrics but does not add operating-system metrics. The CloudWatch agent can collect and publish filesystem statistics.

Question 2

An application’s EC2 fleet should scale out when CPU utilization remains above a threshold. The company wants to minimize scaling delay and accepts additional monitoring charges.

Which design best meets the requirement?

A. Use basic EC2 monitoring and evaluate the alarm once per hour.
B. Enable detailed EC2 monitoring and connect a CloudWatch metric alarm to an Auto Scaling policy.
C. Install the CloudWatch agent only; no alarm is required.
D. Use a composite alarm containing no underlying metric alarms.

Correct answer: B

Explanation: Detailed monitoring provides one-minute EC2 metric intervals. A CloudWatch alarm can evaluate CPU utilization and invoke an Auto Scaling policy to change fleet capacity.

Question 3

A monitoring team wants one alert only when both high CPU utilization and failed EC2 status checks are present. Separate alarms already exist for each condition.

Which CloudWatch capability should the team use?

A. A composite alarm
B. A high-resolution custom metric
C. Detailed monitoring
D. The SetAlarmState API

Correct answer: A

Explanation: A composite alarm evaluates a rule based on multiple existing alarms, making it appropriate for combining CPU and status-check conditions.

Question 4

A security team needs to detect changes to AWS resources and route those changes to downstream targets. An older design refers to CloudWatch Events.

Which current AWS service should be selected for the event-routing design?

A. CloudWatch detailed monitoring
B. Amazon EventBridge
C. CloudWatch high-resolution metrics
D. CloudWatch composite alarms

Correct answer: B

Explanation: Amazon EventBridge is the current event-driven service associated with the functionality historically called CloudWatch Events. Metrics and alarms solve different monitoring problems.

Question 5

An application publishes a custom metric every second because an automated response must occur very quickly. The team wants to reduce cost without changing the application’s behavior.

Which consideration is most relevant?

A. Replace the custom metric with default EC2 CPU metrics.
B. Evaluate whether high-resolution metrics are actually required, because they carry additional cost.
C. Use INSUFFICIENT_DATA as the alarm’s normal state.
D. Replace the alarm with a CloudWatch log group.

Correct answer: B

Explanation: High-resolution custom metrics provide one-second granularity but cost more. The team should confirm that the response-time requirement justifies high resolution; otherwise, standard-resolution metrics may be sufficient.