Utilizing CloudWatch Alarms for monitoring cost and performance

In my last post, I explored one of the many options in automation to cut costs of operation within AWS by setting up scheduled EC2 shutdowns. As I stated in my last post, my free-tier benefits officially end in August, which lead me to explore ways of cutting costs. One of my favorite ways to monitor and control costs is by utilizing the all-powerful CloudWatch!

CloudWatch is extremely versatile with a well-designed dashboard showing you metrics that include CPU Utilization, disk writes and reads and so much more. This can be an excellent tool to monitor AWS services and when paired with AWS SNS, you can get notifications when critical changes occur.

In my last post I discussed scheduled shutdowns of EC2 instances using CloudWatch events. What if you want to know if the EC2 instances you are using are efficient for the tasks you're running? What if you want alerts set up based on billing costs of those instances or an alert sent if one or more instances unexpectedly has a state change? This is where CloudWatch really shines!

I wanted to try out a few different scenarios for my own personal account to keep an eye on some specific metrics. These are the steps I followed to create alarms for EC2 state change, EC2 billing and a general AWS account billing alarm as well.

1. First off, I created SNS topics for all 3 alarms I wanted to monitor and subscribed to these topics. I used strictly email as my notification of choice but SMS Text could come in handy as well. Be sure to confirm the subscriptions within your own email.
2. For my EC2 instance change alarm, I went into CloudWatch and created an event rule. I selected EC2 as the service name and for event type I chose "EC2 instance State-change notification". Finally for my target, I chose SNS and selected the topic created for EC2 state change. Once I had this completed I had to run a simple test of stopping an EC2 instance and checking to see if I received the alert stating that the change had occurred. Voila! Simple as that, my first alarm has been successfully created.
3. My next alarm to setup in CloudWatch was the EC2 billing metric. With these types of alarms you can set a threshold (in this case, A dollar amount) and once that limit has been surpassed an alarm will be sent out. This is fantastic for monitoring projected costs for specific services. More of the same, select your specific metric to monitor, choose your SNS topic created for the alert and add a brief description of what the alert is for. This will fire off anytime the set threshold (dollar amount) is exceeded.
4. Finally, the most useful alarm (in my opinion) is the account billing alarm, which has its own dashboard built within CloudWatch and can be easily setup in minutes. This will monitor the estimated cost of your account for the month and once the set threshold is surpassed you will be alerted. This has been crucial for me as my free-tier ends. I have already discovered ways of cutting costs and found areas I could save in! Whew!

AWS offers so many different avenues of cost-management and various reports that can demonstrate areas of improvement. Cost Explorer, AWS Budgets and AWS Compute Optimizer are all fantastic as well. For the depth of metrics that can be monitored and versatility of it's performance, I will always be partial to CloudWatch.

Jerry