AWS CloudWatch Deep Dive: Architecture, Metrics, Alarms & EC2 CPU Alerting Demo

AWS CloudWatch serves as the foundational observability and monitoring service within the AWS ecosystem. It acts as a digital gatekeeper, tracking operational health, aggregating infrastructure logs, computing performance metrics, and orchestrating automated responses when thresholds are breached.

1. Why Do We Need AWS CloudWatch? (The Problem Statement)

In modern cloud environments running distributed applications, virtual machines, and managed infrastructure, manual inspection is impossible. When scale increases, engineering teams face critical operational blind spots:

• Silent Failures: Virtual machines or backend processes can experience memory leaks or runaway CPU consumption without developers noticing until users report downtime.
• Fragmented Logs: When builds or application deployments fail inside isolated services (like AWS CodeBuild or EC2 instances), debugging errors requires centralized log aggregation.
• Reaction Latency: Relying on human operators to constantly monitor infrastructure graphs leads to slow incident response times and degraded Service Level Agreements (SLAs).

CloudWatch solves these challenges by providing continuous, automated monitoring, proactive alerting, centralized logging, and integrated metrics collection across all AWS accounts.

2. Core Mental Model: CloudWatch as the Cloud Gatekeeper

Real-Life Analogy: Think of AWS CloudWatch as a 24/7 Watchman or Security Gatekeeper stationed at the entrance of a secure estate.

Just as a gatekeeper tracks every visitor entering the property, logs their arrival times, and sounds an alarm if an unauthorized vehicle breaches the perimeter, CloudWatch monitors every API interaction, tracks resource creation, watches performance metrics (like CPU and memory), and triggers emergency notifications when anomalies occur—even when engineers are offline.

3. The Four Pillars of AWS CloudWatch

CloudWatch is built on four core functional pillars that cover complete operational observability:

4. Default Metrics vs. Custom Metrics

CloudWatch collects thousands of out-of-the-box metrics across AWS services, but understanding the distinction between default and custom metrics is crucial for deep application monitoring.

• Default Metrics: Automatically tracked by AWS services without manual configuration. For example, Amazon EC2 exposes over 1,000 default metrics, including CPUUtilization, NetworkIn, NetworkOut, and DiskReadOps.
• Custom Metrics: Metrics outside the default AWS scope (such as memory consumption, disk space usage, or application-specific request latency). Because CloudWatch does not track memory utilization by default, developers must write custom metric scripts or agents to push these values into CloudWatch.

5. Step-by-Step Practical Setup: EC2 CPU Alerting via SNS

To demonstrate real-world monitoring and alerting, this workflow provisions an Ubuntu EC2 instance, configures detailed monitoring, deploys a Python CPU-spiking utility, establishes a CloudWatch alarm, and links it to an Amazon SNS email notification topic.

Step A: Launch an EC2 Instance

1. Navigate to the EC2 Console and click Launch Instance.
2. Name the instance CloudWatch-Demo-Instance.
3. Select Ubuntu (AMI) and instance type t2.micro.
4. Configure key pairs and ensure public IP assignment is enabled. Launch the instance.

Step B: Enable Detailed Monitoring

By default, EC2 sends standard metrics to CloudWatch every 5 minutes. To enable real-time 1-minute metric granularity:

1. Select the newly created EC2 instance in the console.
2. Go to the Monitoring tab.
3. Click Manage detailed monitoring and enable it.

Step C: Deploy the Python CPU Spiker Script

SSH into the EC2 instance and create a Python script to simulate high CPU utilization:

ssh -i "your-key.pem" ubuntu@<your-ec2-public-ip>
nano cpu_spike.py

Paste the following CPU-spiking simulation code:

import time
import os

def spike_cpu():
    print("Simulating CPU Spike at ~80%")
    end_time = time.time() + 60  # Run for 60 seconds
    while time.time() < end_time:
        # Perform intensive mathematical calculations to consume CPU cycles
        [x**2 for x in range(1000000)]
        time.sleep(0.01)

if __name__ == "__main__":
    while True:
        spike_cpu()
        time.sleep(5)

Save and exit the file (Ctrl+O, Enter, Ctrl+X), then execute it:

python3 cpu_spike.py

6. Configuring CloudWatch Alarms and SNS Notifications

Step 1: Create an SNS Topic for Email Alerts

1. Search for and open the Simple Notification Service (SNS) console.
2. Create a new Standard Topic named cloudwatch-alert-topic.
3. Create a Subscription on the topic with protocol Email and enter your target email address.
4. Check your inbox (and spam/promotions folders) for the AWS confirmation email and click Confirm Subscription.

Step 2: Create the CloudWatch Alarm

1. Open the CloudWatch Console and select Alarms -> Create Alarm.
2. Click Select metric -> EC2 -> Per-Instance Metrics.
3. Locate your instance ID (84A...) and select CPUUtilization. Click Select metric.
4. Configure the alarm conditions:
   • Statistic: Maximum
   • Period: 1 minute
   • Condition: Greater/Equal ($>=$)
   • Threshold value: 50 (representing 50% CPU utilization).
5. Configure actions:
   • Select In alarm.
   • Choose Use an existing SNS topic and select cloudwatch-alert-topic.
6. Add an alarm name (e.g., Danger-EC2-CPU-Exceeded-50) and a custom message:

   Hey team, this is an automated notification from CloudWatch to let you know that your instance CPU has spiked to 50% or above. Please take necessary action.

7. Complete the wizard and click Create Alarm.

7. Complete Flow Walkthrough: From Spike to Email Alert

Python Script (cpu_spike.py) executes on EC2 Instance
   |
   | consumes 100% CPU cycles
   v
EC2 Instance reports high CPU metric to CloudWatch (every 1 minute)
   |
   | CloudWatch evaluates metric against threshold (>= 50%)
   v
CloudWatch Alarm state changes from [OK] to [ALARM]
   |
   | triggers associated action
   v
Amazon SNS (Simple Notification Service) publishes message
   |
   | delivers formatted email payload
   v
DevOps Engineer receives email notification in inbox / promotions folder

8. Summary and Key Takeaways

• Gatekeeper Role: CloudWatch acts as the core observability and monitoring gatekeeper for AWS accounts, handling monitoring, alerting, reporting, and logging.
• Four Core Pillars: Comprises Metrics (time-series data), Alarms (automated threshold evaluators), Logs (centralized log groups), and Dashboards (visual displays).
• Default vs Custom Metrics: AWS automatically tracks over 1,000 default metrics (such as CPUUtilization), while memory and application metrics require custom instrumentation.
• Granularity Control: Standard EC2 metrics report every 5 minutes, whereas Detailed Monitoring elevates reporting frequency to every 1 minute for near real-time observability.
• Automated Alerting: Alarms evaluate incoming metrics against mathematical thresholds and seamlessly integrate with Amazon SNS to dispatch instant email or Slack alerts.
• Production Safety Caution: CPU-spiking scripts must be run exclusively on dedicated test or demo instances; executing unthrottled loops on production servers can render systems unresponsive.
• Operational Efficiency: Combining CloudWatch metrics with automated alarms and serverless functions (like AWS Lambda) enables automated cost optimization, resource scaling, and proactive incident mitigation.