CloudWatch - infrastructure monitoring
Start course
1h 5m

Please note: this course has now been removed from our content library. If you want to study for the SysOps Administrator Associate Level Certification, we recommend you take our dedicated learning path for that certification that you can find here.


The AWS Certified SysOps Administrator (associate) certification requires its candidates to be comfortable deploying and managing full production operations on AWS. The certification demands familiarity with the whole range of Amazon cloud services, and the ability to choose from among them the most appropriate and cost-effective combination that best fits a given project.

In this exclusive Cloud Academy course, IT Solutions Specialist Eric Magalhães will guide you through an imaginary but realistic scenario that closely reflects many real-world pressures and demands. You'll learn to leverage Amazon's elasticity to effectively and reliably respond to a quickly changing business environment.

The SysOps certification is built on solid competence in pretty much all AWS services. Therefore, before attempting the SysOps exam, you should make sure that, besides this course, you have also worked through the material covered by our three AWS Solutions Architect Associate level courses.

If you have thoughts or suggestions for this course, please contact Cloud Academy at


Hi and welcome to our seventh lecture. In this lecture, we will take a look at Cloud Watch and explore its main features. We will also work with one of the best features of Cloud Watch, the custom metrics, where we can upload any data we want and monitor it from AWS.

First, we need to go to the Cloud Watch dashboard. Here, we can see the two alarms that we created in the last lecture. The low CPU utilization alarm is sending emails to the Cloud Motors admins topic.

We don't want that, as this information is not critical for us. So let's remove this notification and adjust the alarm, because after a while, we noticed that it was removing instances too soon. In the same way, let's modify the high CPU utilization alarm, because it was also adding instances to auto scaling too soon. If you explore enough, you will notice that we could use the same alarm to trigger the increase and decrease policies that we specified in auto scaling. Let's check the metrics. Here, we can see a list of all available metrics that we can query. We can see graphics, combine graphics with multiple metrics, or set alarms for the metrics that we see here. Depending on what you have in your environment, you could have more or less metrics to view.

If we select one metric, we can see a graphic with the metrics value over the time. We can also combine the current graphic with more than one metric. That way, we could, for instance, see what happens with the instance IO when the CPU utilization is high, or how the RDS database reacts when there is too much network traffic at the instances on the auto scaling group, or how many requests are being processed by ELB during the working hours. There are many possible choices. It's up to you to combine the data and explore the possibilities. You could select the metrics that you want, build a graphic and share it. You just need to click on Copy URL and share the link.

You can select the exact time frame that you want to see on the graphic. But besides AWS services, Cloud Watch can also monitor how much you're going to pay for the current month. You can also set alarms for that. You just need to go to the North Virginia region and view the billing metrics. Here you could, for instance, create a billing alarm in case you have a defined budget for your project. Since we want to save money, let's create an alarm that will send an email to the one who's responsible for the bills. Whenever the estimated cost is more than zero, it will trigger the alarm. In other words, we don't want to pay anything. To really have billing alarms, you would need to first go on the billing and cost management console, click on preferences, and then select the receive billing alerts. I can't do this since I'm not using the route account, and my IAM user doesn't have permissions for that. Now, we are done.

For me, the best feature of Cloud Watch is the custom metrics that we can send and monitor as we do with any other metric.

I've written a simple script that's available in the GitHub repository in the scripts folder. Before running, you need to have the AWS command line interface configured on your machine. Since I have it already, I will skip that part and show you the script.

You just need to change the end point variable and allow ping on the ELS' security group to allow it to work properly. The ping will get the latency and curl will count the time that the welcome page is taking to load. I'm running this script as we speak, and it's sending data already.

Let's check the data. And here we have our custom metrics. And we can compare them on the same graphic over a time frame as we already saw. We can also export the graphic URL as any other graphic. I strongly recommend you take some time and explore everything that Cloud Watch can provide.




About the Author

Eric Magalhães has a strong background as a Systems Engineer for both Windows and Linux systems and, currently, work as a DevOps Consultant for Embratel. Lazy by nature, he is passionate about automation and anything that can make his job painless, thus his interest in topics like coding, configuration management, containers, CI/CD and cloud computing went from a hobby to an obsession. Currently, he holds multiple AWS certifications and, as a DevOps Consultant, helps clients to understand and implement the DevOps culture in their environments, besides that, he play a key role in the company developing pieces of automation using tools such as Ansible, Chef, Packer, Jenkins and Docker.