Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 67

CloudWatch Dashboard and CPU Alarm

Recommended resources

Welcome back! In our previous lesson, you successfully established a centralized logging system with AWS CloudWatch. This was a crucial move from treating your deployed application as a "black box" to gaining visibility into its operations. Now, we will build on that foundation, moving from passive observation to proactive monitoring.

This lesson focuses on creating dashboards and alarms in CloudWatch, which directly addresses the "comfortable with... deployment and monitoring" requirement from the Infilect job description. Simply collecting logs isn't enough; production-grade engineers must be able to visualize system health at a glance and be automatically notified when problems arise.

By the end of this lesson, you will be able to set up a basic monitoring dashboard to visualize key performance indicators and create an automated alarm that triggers on critical events, like high CPU utilization. This is the final step in building a scalable, observable system before we integrate all these concepts into your capstone project.

1. From Logs to Metrics: The Essence of Monitoring

In the last lesson, we focused on logs, which are records of discrete events. Monitoring often also involves metrics, which are numerical data points measured over time. Think of CPU utilization, network traffic, or the number of active database connections. AWS CloudWatch automatically collects metrics from most AWS services.

While logs help you answer the question "What happened?", metrics help you answer "How is the system performing right now?". Dashboards and alarms are the primary tools for working with metrics.

The article below provides a great overview of CloudWatch's role and some best practices we will be implementing.

Learning AWS the Practical Way — Part 5: Monitoring and ...

This article explains the core concepts of CloudWatch and its common use cases. It will help you understand the bigger picture of what we're building.

First, read the introductory section What is Amazon CloudWatch to understand how it organizes data into namespaces, metrics, and dimensions. Next, skim the use cases section to see how professionals use this service for infrastructure and application monitoring. Finally, pay close attention to the Best Practices. We will be applying several of these today, such as creating clear dashboards and focusing on key metrics.

2. Visualizing System Health with CloudWatch Dashboards

A CloudWatch Dashboard is a customizable homepage in the CloudWatch console where you can create a "single pane of glass" view of your application's health. Instead of clicking through multiple services to check different metrics, you can assemble them all in one place. A well-designed dashboard allows you to spot trends, correlate events, and identify anomalies quickly.

An example of a CloudWatch dashboard showing various metrics for an application's infrastructure, including EC2, RDS, and an Application Load Balancer. This is what we aim to build a simplified version of.

The following video provides an excellent walkthrough of how to create dashboards and alarms. We will start with the dashboard portion.

AWS CloudWatch Tutorial for Beginners | Metrics, Alarms, Dashboards & Logs Explained

This video tutorial gives a practical demonstration of building a CloudWatch dashboard and adding widgets to it.

Please watch the segments on dashboard creation: First, watch the introduction to dashboards from this section. Then, see how to add widgets to the dashboard from this demonstration. Notice how you can add different types of widgets (line graphs, numbers) for various metrics.

3. Proactive Alerting with CloudWatch Alarms

Dashboards are great for when you are actively looking at your system, but what about when you're not? That's where alarms come in. A CloudWatch Alarm watches a single metric over a time period you specify and performs one or more actions based on the value of the metric relative to a given threshold.

An alarm has three possible states:

  • OK: The metric is within the defined threshold.
  • ALARM: The metric has breached the defined threshold.
  • INSUFFICIENT_DATA: The alarm has just started, the metric is not available, or there is not enough data for the metric to determine the alarm state.
The CloudWatch interface for creating an alarm. You specify a metric (like CPUUtilization), a condition (e.g., Greater than a threshold), and a value (e.g., 80%).

Let's return to the video to see how to create an alarm and, crucially, how to test that it works.

AWS CloudWatch Tutorial for Beginners | Metrics, Alarms, Dashboards & Logs Explained

This video provides a complete walkthrough of creating a CPU utilization alarm, and even shows how to stress-test an EC2 instance to trigger it.

First, watch the conceptual overview of alarms from this section to understand alarm states and actions. Next, watch the step-by-step demonstration of creating the alarm in the AWS console. Finally, and most importantly, watch how the instructor uses a stress-testing tool to trigger the alarm and observe its state change from 'OK' to 'ALARM'. This is a powerful way to validate your monitoring setup.

For a detailed, step-by-step guide that you can reference during the hands-on task, the official AWS documentation is invaluable.

Create a CPU usage alarm - Amazon CloudWatch

This official AWS documentation provides a precise, step-by-step guide to creating a CPU utilization alarm using the AWS Management Console.

Read through the section Setting up the alarm. This will serve as your primary reference for the alarm creation part of the hands-on task. Pay attention to the definitions of Period, Statistic, and Datapoints to alarm.

4. Hands-On Task: Build Your Monitoring Hub

It's time to apply these concepts to your infilytics project. You will create a dashboard to get a high-level view of your system and an alarm to notify you of potential performance issues.

Your Goal: Create a dashboard showing key metrics from your stack and set up an alarm that would trigger if your EC2 instance is overworked.

Instructions:

Part A: Create the Infilytics-Dashboard

  1. Navigate to the CloudWatch console in your AWS account.
  2. Go to Dashboards and click Create dashboard.
  3. Name your dashboard Infilytics-Dashboard and create it.
  4. You will be prompted to add your first widget. We will add a few key metrics to get a full picture of our application stack.
    • Widget 1: EC2 CPU Utilization
      • Choose Line chart. Select Metrics.
      • Under All metrics, navigate to EC2 > Per-Instance Metrics.
      • Find the metric CPUUtilization for your running EC2 instance and select it.
      • Click Create widget.
    • Widget 2: RDS CPU Utilization
      • Click the Add widget button.
      • Choose Line chart and select Metrics.
      • Navigate to RDS > DBInstanceIdentifier.
      • Select the CPUUtilization metric for your RDS database instance.
      • Create the widget.
    • Widget 3: RDS Database Connections
      • Add another widget.
      • Navigate to RDS > DBInstanceIdentifier again.
      • This time, select the DatabaseConnections metric.
      • Create the widget.
    • Widget 4: Application Load Balancer Request Count
      • Add a final widget.
      • Navigate to ApplicationELB > Per AppELB Metrics.
      • Select the RequestCount metric for your ALB.
      • Create the widget.
  5. Feel free to resize and rearrange the widgets on your dashboard. When you're done, click Save dashboard.

Part B: Create a CPU Utilization Alarm

  1. In the CloudWatch console, navigate to Alarms > All alarms in the left-hand pane.
  2. Click Create alarm.
  3. Click Select metric. Navigate to EC2 > Per-Instance Metrics and select the CPUUtilization metric for your instance.
  4. Configure the conditions:
    • Statistic: Average
    • Period: 5 minutes
    • Threshold type: Static
    • Whenever CPUUtilization is...: Greater > threshold
    • than...: 80 (This means the alarm will trigger if the average CPU is over 80% for 5 minutes).
  5. Click Next.
  6. For the Notification step, you would typically configure an SNS topic to send an email or SMS. For now, you can simply click Remove on the default notification action and proceed without one. We are focused on seeing the alarm state change in the console.
  7. Click Next.
  8. Give your alarm a name, like High-CPU-EC2-Infilytics, and a description.
  9. Click Next, review your configuration, and click Create alarm.

After creation, the alarm will initially be in the INSUFFICIENT_DATA state. After a few minutes, it should transition to the OK state, showing a green checkmark.

Conclusion

Fantastic work! You have now implemented the two core components of proactive monitoring. Your dashboard provides a visual health check for your entire application stack, and your alarm ensures you're aware of critical performance issues even when you're not looking. This completes our module on scalability, load balancing, and monitoring. You've taken your simple deployed application and transformed it into a production-ready system with caching, centralized logging, and now, monitoring and alerting.

Here are the key takeaways:

  • Dashboards provide visibility: They bring key metrics from different services into a single, consolidated view.
  • Alarms enable proactivity: They automate the process of watching metrics and can trigger actions when thresholds are crossed.
  • Monitoring is about metrics and logs: Both are essential for a complete observability picture.

This was the final piece of the infrastructure puzzle. In our next and final module, you will begin the Capstone Project. You will leverage every skill you've learned—from Django and DRF to Celery, Docker, and AWS—to build the "Retail Shelf Intelligence Backend," a project designed to mirror the exact requirements of the Infilect role you're targeting.