Welcome back. In our last lesson, we mastered the various layers of S3 security, ensuring that we can protect our data assets in the cloud. We've now covered the essentials of provisioning and securing core AWS infrastructure: VPCs for our network, EC2 for compute, and S3 for object storage. This completes a major milestone in our journey.
This lesson marks the final piece of our "AWS Core Infrastructure" module, shifting our focus from building and securing to operating and observing. After all, a running system is only useful if you know what it's doing. We will address the learning outcome: Monitor AWS resources by creating CloudWatch dashboards, alarms, and log groups. For a DevOps engineer, particularly one targeting a FAANG-level role, proficiency in monitoring isn't just a skill—it's a fundamental responsibility for maintaining system reliability, performance, and health.
We'll explore Amazon CloudWatch, AWS's native observability service. You will learn how to collect and visualize key performance indicators (metrics), how to automate responses to issues using alarms, and how to centralize application and system logs for troubleshooting. This knowledge is the foundation for building resilient, self-healing systems.
1. The Architecture of AWS Monitoring
Before diving into the components, let's look at the big picture. How does data from a resource, like an EC2 instance, make its way to an engineer's inbox as an alert?
This flow—Collect, Visualize, Alert—is the fundamental pattern we will explore today.
2. Core Concepts: Metrics, Logs, and Alarms
Amazon CloudWatch is a suite of tools, and it's essential to understand its core components. One of the best ways to start is by grasping the key terminology and the distinction between monitoring and observability, a common topic in DevOps interviews.
This blog post provides an excellent introduction to the core components of CloudWatch.
Please read the first part of the article, from the beginning down to the start of the "Lab Architecture" section. Focus on the definitions of Core Components and the explanation of the difference between these two crucial concepts.
To build on this, it's also helpful to understand how CloudWatch organizes data. Data is structured hierarchically using Namespaces, which group metrics from a specific service (e.g., AWS/EC2), Metrics, which are the time-series data points themselves (e.g., CPUUtilization), and Dimensions, which are key-value pairs that uniquely identify a metric (e.g., InstanceId=i-1234567890abcdef0).
You can explore a brief, clear explanation of this structure in the video below.
Master CloudWatch, CloudTrail & Config on AWS | Complete Hands On Tutorial with Diagrams | #aws
This video provides a concise overview of CloudWatch's foundational concepts.
Watch the segment from Metrics, Namespaces, and Dimensions to understand how CloudWatch organizes data.
3. Visualizing Performance with Metrics and Dashboards
The first pillar of observability is metrics. Many AWS services, including EC2, automatically publish metrics to CloudWatch. These are typically high-level indicators that the underlying AWS hypervisor can observe, such as CPU utilization, network traffic, and disk I/O.
However, for a complete picture, you often need metrics from inside the operating system, such as memory usage or disk space percentage. The AWS hypervisor cannot see these for privacy and security reasons. To collect these, you must install the CloudWatch Agent on your EC2 instances. Your experience with Ansible will make the task of automating this agent's installation across a fleet of servers quite intuitive.
The article "AWS CloudWatch Monitoring on EC2" clearly explains why this agent is necessary and how to install it.
This reading will clarify the role of the CloudWatch agent.
First, read the section about installing the agent and creating the necessary IAM role. Then, jump to the section titled "Why CloudWatch Agent Matters" and read the explanation and table comparing metrics available with and without the agent.
Once metrics are flowing into CloudWatch, you need a way to visualize them. Dashboards provide a customizable view of your most important metrics, allowing you to spot trends and correlate events across different resources.
Creating a dashboard involves selecting metrics and choosing how to display them. The following video demonstrates this process.
Master CloudWatch, CloudTrail & Config on AWS | Complete Hands On Tutorial with Diagrams | #aws
This segment shows how to navigate the metrics explorer and add a metric to a dashboard.
Watch from exploring metrics, where the presenter navigates through namespaces and visualizes the CPUUtilization metric for an EC2 instance, then adds it to a dashboard.
4. Automated Alerting with CloudWatch Alarms
Visualizing data is useful for manual inspection, but the real power of monitoring comes from automation. CloudWatch Alarms watch a single metric over a specified time period and perform one or more automated actions when the metric's value breaches a threshold.
An alarm has three possible states:
- OK: The metric is within the defined threshold.
- ALARM: The metric has breached the threshold.
- INSUFFICIENT_DATA: Not enough data is available to determine the alarm state. This is common when an alarm is first created or if the associated resource is stopped.
Configuring an alarm can be tricky, especially the relationship between "Evaluation Periods" and "Datapoints to Alarm." These settings determine how tolerant your alarm is to brief spikes, helping you avoid "flapping" alarms that switch states too frequently.
The following video provides an exceptionally clear blackboard explanation of this crucial concept.
AWS Cloudwatch Alarm Setup Tutorial | Step by Step
This tutorial from "Be A Better Dev" is excellent for understanding alarm configuration.
Focus on the blackboard explanation from Datapoints to Alarm. It walks through a concrete example of how a 3 out of 5 configuration works, which is a common and robust setup for production alarms.
Now that you understand the theory, let's see how to create an alarm, connect it to an SNS topic for email notifications, and trigger it.
This part of the hands-on lab walks you through the entire alerting workflow.
Read through the steps starting from Step 9 to Step 15. This demonstrates how to stress an instance to generate data, create a HighCPUAlarm, confirm the SNS subscription, and receive the resulting email alert. This is the exact workflow you would use in a real-world scenario.
5. Centralized Logging with CloudWatch Logs
The final pillar is logs. While metrics tell you that something is wrong (e.g., high CPU), logs help you understand why. CloudWatch Logs allows you to centralize logs from all of your systems, applications, and AWS services in a single, highly available location.
Key concepts for CloudWatch Logs include:
- Log Group: A container for logs, typically representing an application or service (e.g.,
/var/log/nginx/access.logor/aws/lambda/my-function). - Log Stream: A sequence of log events that share the same source. For EC2, this might be the instance ID; for Lambda, it's a specific function version.
- Log Retention: A setting on a log group that defines how long to keep log events. This is crucial for managing costs.
The following practical demo explains these concepts and shows how to put them into practice.
Learning AWS the Practical Way — Part 5: Monitoring and ...
This article provides a practical demonstration of setting up a logging structure for an application.
Read the demo section starting from Step 1 through Step 5. Pay attention to the consistent naming conventions for log groups and the practice of setting a log retention policy to control costs.
Conclusion
In this lesson, we've laid the groundwork for operating reliable systems on AWS. You now understand how to use Amazon CloudWatch to gain visibility into your resources, moving from passive observation to proactive, automated alerting.
Key Takeaways:
- CloudWatch consists of three main pillars: Metrics (time-series data), Logs (text-based events), and Alarms (automated actions).
- Dashboards are essential for visualizing key metrics and understanding system health at a glance.
- The CloudWatch Agent is required to collect system-level metrics like memory and disk space usage from your EC2 instances.
- Alarms are the core of automated monitoring. Understanding how to configure
evaluation periodsanddatapoints to alarmis critical for creating stable, meaningful alerts. - Log Groups and Streams provide a centralized and structured way to collect and manage logs, with retention policies being a key tool for cost management.
With this lesson, we conclude the "AWS Core Infrastructure" module. You can now provision, secure, and monitor the fundamental building blocks of a cloud environment. In our next lesson, we will begin a new module, "Scalable & Automated AWS Services," starting with how to deploy and manage a relational database using Amazon RDS. The monitoring skills you've acquired today will be immediately applicable as we learn to watch database performance metrics like CPUUtilization, DatabaseConnections, and Read/WriteIOPS.