Here I'll be setting up an alarm for CPU utilization on an EC2 instance (and taking it down once it worked).
First things first, I go to the EC2 tab in AWS and create an instance (name it, select the default Amazon Linux OS, and the default free t3.micro instance type).
I scroll down a bit and make sure the VPC is set to default, that the "auto-assign IP" is enabled, and that the security group for this EC2 has an obvious name.
For this test, I won't be SSH'ing into the EC2 instance so I won't be needing a keypair.
I launch the instance at this point, wait to see that it launched successfully, then head to my list of EC2 instances.
After a bit I can see that the EC2 instance is running and that it has passed all three status checks.
Now that the EC2 instance is set up and running, I go to CloudWatch and click on "create alarm" and then click on "metric" to find the "EC2" metrics list and the select the "per-instance metrics" category to see all of the metrics for my specific EC2 instances.
I go back to the EC2 instance page to take note of the test EC2 instance that I just created and take note of the instance ID (last for characters: "0fa4")...
... and then find the "CPU Utilization" metric that coincides with this particular EC2 test instance in my CloudWatch tab back under "per-instance metrics" (for the instance ending in "0fa4", of course). I check the box next to the metric and then hit "select metric".
From there, I scroll down to set the metric that I want to test: Static (to monitor a specific, unchanging metric), "greater/equal" to "20" % CPU utilization.
After clicking on next, I go ahead and "remove" the SNS topic option (which would be useful in a production situation, but not needed for testing a CloudWatch alarm).
Click on next again and then name the alarm something that makes sense.
After clicking next again, I am presented with a summary of the metric that I just created, and then click "create alarm" after seeing that everything checks out.
And I can then see that the alarm has been created.
Now that the alarm for this test EC2 instance is in place, I want to test it by causing the EC2 instance to use some compute. In order to do that, I go to the EC2 instance, right click on it, and select "connect", leave everything as default, and click on "connect" again.
This will take us to a new tab where I the the Amazon Linux 2023 CLI. Since I want to test my 20% CPU utilization alarm for my EC2 instance, I download an app called "stress" with the prompt "sudo yum install stress -y" (the "-y" confirming "yes, we want to install it" so we aren't prompted to confirm):
Now that I have "stress" downloaded, I type in "stress --help" to see what my options are for bombarding my EC2 instance with compute. After taking a look at my options, I run the command "stress -c 1 -t 3600" to run the compute through one CPU ("-c 1") for a total of one hour or 3600 seconds ("-t 3600").
Now that I have set the stress test to hit the EC2 instance with compute load, I go back to the alarm in CloudWatch and select it to watch the CPU utilization for the EC2 instance start to tick up...
... and after a few moments I hit "refresh" to see that the compute used by this EC2 instance (thanks to it being bombarded by the stress app) has exceeded 20% and that the alarm that I created has in fact been set off:
Since my test was successful, I go ahead and turn off the stress test by typing "control+C" in the CLI.
And at that point, I go back to my test alarm and see that the compute has dropped below my 20% threshold and that the alarm has shut off:
This confirms that the CloudWatch alarm did in fact function as intended. So at this point, I want to be sure to delete: the CloudWatch Alarm, the EC2 instance, and the EC2 Instance Security Group:
After all has been deleted from the successful test, my AWS account is back to the way it was (and not charging me for services that I don't need to use).
Top comments (0)