LAB 18 - CloudWatch Alarms for EC2 CPU Usage and S3 Bucket size Part 1

Amazon CloudWatch is a service for monitoring and observing AWS cloud resources and applications. It lets you collect and track metrics, monitor log files, set alarms, and automatically respond to changes in your AWS environment. It gives you insights into how well your AWS infrastructure and applications are performing and their operational health. CloudWatch Alarms are a feature of Amazon CloudWatch that lets you monitor metrics and trigger actions when those metrics exceed a threshold you set. These actions can include sending notifications, like emails or SMS messages, or triggering other AWS resources, such as auto-scaling instances. In the first of two lab exercises, I will demonstrate how to set an alarm for CPU Utilization for an Amazon Linux EC2 instance. This will involve setting an alarm to trigger when EC2 CPU usage reaches 80% utilization, sending an SNS notification to a specified email address.

The following suffice for the demonstration; Step 1 : Launch an EC2 Instance - The first step is to launch an Amazon EC2 instance with the necessary configuration to allow access to the instance later. Launching an instance on AWS management console is quick and easy. I have called it “My CW Instance”.

In order to have a seamless access of the instance, I ensured that it was set up in a subnet that allowed public ipv4 address. So I was able to connect without needing ssh.

Step 2 : Set up CloudWatch Alarms - From the CloudWatch console, we navigate to Alarms and then click on “Create Alarms”.

The next stage would be to select the necessary metrics. So we click on “Select metric” which enables the careful choosing of the following; Namespace —> AWS/EC2, Metric —> CPUUtilization, Dimension —> InstanceId(this corresponds to the instance we have already launched). Next, the set conditions are selected and these include the type(static), period(5 minutes) and Threshold(Greater than 80%).

The next step would be to configure the necessary action and this actually translates to configuring the SNS topic with the email address endpoint. AWS CloudWatch requires the user to create an SNS topic with a name and this will send the alarm details to a designated email address once triggered.

The graphic above shows that the notification will happen when it is in the “In alarm” state.

Finally, the alarm can be created!

Step 3 : Testing the Alarm - To test if our alarm is working, I had to trigger the CPU utilization on the running EC2 instance to go beyond the threshold of 80%. To do this, we have to log in to the instance, install a load generator and then run a stress test for a period of 5 minutes.

Running the stress test - Installing the load generator and running it on our instance requires just two steps as follow sudo yum install stress -y stress --cpu 4 --timeout 300

The command instructs the stress tool to create 4 worker threads that will put a load on the CPU, and it should run for 300 seconds (or 5 minutes).

After about 5 minutes, the CPU utilization increases, and our CloudWatch alarm will notify us through the email address we provided during sign-up.

From the dashboard, one can see that alarm is in “In alarm” state.

Next is to confirm if there is alert to my email address as expected;

So, we can safely conclude that our CloudWatch alarm works. It is triggered by CPU utilization, activating at the 80% level after a stress load lasting 5 minutes.. You can confirm this from the management console or a designated email address.

This concludes the first CloudWatch lab, which focuses on EC2. The second and final part will focus on Amazon S3. Thank you for reading, and see you in the next one.