If you maintain an application on AWS, you may have heard about Amazon CloudWatch already, the monitoring service of AWS. Amazon CloudWatch gathers metrics from your AWS resources such as CPU or memory usage, and your resources emit events to CloudWatch when their states change, such as an auto-scaling launch event.
You can define thresholds on your metrics and trigger alarms if those thresholds are exceeded. Besides, you can take actions on a specific event, for example, by triggering an AWS Lambda function. Hence, both features help you in monitoring the states of your resources and get notified or take proactive or reactive actions to protect the health of your workload.
Whether you are planning to use Amazon CloudWatch for the first time or preparing for an AWS exam these days, you may be wondering what the differences between these two crucial Amazon CloudWatch features are.
By the way, Amazon EventBridge is the new version of Amazon CloudWatch Events, so the topics we will talk about in this post will also be valid when comparing Amazon EventBridge with Amazon CloudWatch Alarms. So, what are the differences between Amazon CloudWatch Alarms and Events?
What is an Amazon CloudWatch alarm?
When we talk about CloudWatch alarms, we need to start with CloudWatch metrics first. As I said in the introduction, Amazon CloudWatch gathers some metrics from your AWS resources and many services provide these free. For example, your EC2 instances provide their CPU usages in specific intervals by default. You can also install and configure the CloudWatch agent on your EC2 instances and send metrics not available by default, such as memory utilization. We call them custom metrics.
Besides, your custom metrics do not have to be technical. You can use AWS SDKs or APIs to send some key performance indicators about your application, such as the number of sales in the last five minutes and this is also recommended to monitor the overall functioning of your system’s health. For instance, if your sales suddenly decrease drastically, this may indicate a problem in your applications which you can elaborate on using other metrics.
A metric data also has an interval, which we call metric resolution. The metric resolution indicates the period that the metric is valid for. It can be 1-sec intervals with detailed monitoring, or you can send metrics with 1 minute, 5 minutes, or 1-hour resolutions. The time CloudWatch keeps these metrics for you depend on their resolutions, too. 1-sec metric data is kept for 3 hours and aggregated to 1-minute resolutions, whereas, 1-minute metrics are kept for 15 days and aggregated to 5-minutes resolutions. As you may guess, those 5-minute resolutions will also be aggregated to 1 hour, etc. Hence, these metrics provide you visibility on the performance of your system.
You have your CloudWatch metrics, then, what is next? You can create a CloudWatch dashboard, and watch those metrics visually by creating awesome graphs there. But you cannot watch them forever, right? So, you would not want to miss when a metric goes above or below a healthy threshold. Hence, you can use CloudWatch alarms for this.
A CloudWatch alarm watches a metric and triggers when they exceed a certain threshold or decrease below some point. You can configure it to send a message to an Amazon SNS topic you subscribed to. So, you can get notified when an alarm is triggered. We will talk about what you can do more while comparing with CloudWatch Events.
What is Amazon CloudWatch Events or Amazon EventBridge?
Amazon CloudWatch Events is the traditional serverless event bus service of AWS. Its latest version produced a separate service: Amazon EventBridge. But both services correspond to the same thing. AWS just renamed the new features of the CloudWatch Events as EventBridge to emphasize and market them. Over time, CloudWatch Events will be named as Amazon EventBridge. Hence, our talk here will also be valid for Amazon EventBridge and you can consider them interchangeable.
Most AWS services emit events to Amazon CloudWatch Events when their states change or a specific event occurs in that service. For example, if a deployment fails on AWS CodeDeploy, it submits an event to CloudWatch Events. You can define an event rule for an event to take an action when that event occurs. You define these actions as targets in an event rule. For example, just like in an alarm action, you can define an SNS topic as the event target and make the event rule send a message to that topic to get notified.
As in CloudWatch metrics, you can generate your custom events and send them to CloudWatch Events. Then, you can define a rule and trigger an AWS Lambda function to do custom processing. You can build event-driven architectures by integrating your applications to EventBridge. An application can submit a custom event and another can respond to that event by doing a different thing. For example, an online shop application may submit an event when an order is created, which may trigger the fulfillment process.
In addition to these, there is another type of CloudWatch Events: schedulled events. As they are named, the schedulled CloudWatch events are triggered according to a schedule, their cron expressions. For example, you can configure a schedulled event running daily and triggering an AWS Lambda function to do some automation.
Some differences to note between CloudWatch events and alarms
So, let’s discuss some of the differences between these two CloudWatch features below.
An event triggers when it is created or according to a schedule, but an alarm needs a threshold reached
So, our first difference between an alarm and an event is how they are triggered. A CloudWatch alarm watches a metric for a specific period and triggers if it exceeds above or decreases below a threshold you define. If you defined an action for the alarm, it is also performed.
However, a standard CloudWatch event is triggered when it is created. If it is a schedulled event, it is triggered according to its schedule. If you have a rule that performs an action for that event, it is also performed, just like an action of an alarm. But CloudWatch Events have more integrations with other services than alarms.
You cannot trigger an AWS Lambda function directly from a CloudWatch Alarm
Amazon CloudWatch Events, or EventBridge, is integrated with dozens of AWS services as event rule targets. For example, you can trigger an AWS Lambda function, use the run command of AWS Systems Manager to run scripts on your EC2 instances, or use an SSM automation document to do a different thing. You can trigger an AWS Step Functions state machine execution to orchestrate multiple actions, in parallel or as a series of steps. As I said above, you can also integrate your third-party applications as event targets on EventBridge, the new version CloudWatch Events.
However, the action types of an Amazon CloudWatch alarm are limited. You can send a message to an SNS topic, perform some EC2 actions such as stopping, terminating, rebooting, or recovering an EC2 instance, or scale an EC2 Auto Scaling group. Or you can use some Systems Manager features, such as creating OpsItems in Systems Manager Ops Center or incidents in AWS Systems Manager Incident Manager. Currently, CloudWatch alarm actions are only limited to these.
Of course, you can subscribe an AWS Lambda function to an SNS topic and use the topic in your CloudWatch alarm actions. But you cannot trigger that AWS Lambda function directly from the CloudWatch alarm. You need to use an SNS topic as the intermediary resource. This knowledge may also be helpful in your AWS Certified DevOps Engineer - Professional exams.
You can use alarms to take proactive measures
If you consider an alarm’s trigger also as an event, you can use both CloudWatch alarms and events to react to an event in near real-time. Actually, you can define event rules for state changes in your CloudWatch alarms as CloudWatch alarms emit state change events to CloudWatch Events, too. Of course, these are very helpful to automate your responses and automatically react to the problems when they arise.
But you can also use CloudWatch alarms as a proactive tool to prevent certain events from occurring. For example, the most common scenario to use CloudWatch alarms is scaling your EC2 auto scaling groups. If the average CPU or number of requests on your EC2 instances exceeds a certain level, you can scale out your auto scaling group by launching a new instance. It does not have to mean that there is a problem and you should respond. Mostly, it is a good thing, your application got more popular for some reason. You do this as a proactive measure to keep your workload online if the load exceeds more. After some time, you can scale in gracefully when the load is decreased below a less ambitious level, such as 40% CPU usage. So, CloudWatch metrics and alarms may also help you in scaling your architecture cost-effectively.
You can use Amazon CloudWatch Events to build event-driven architectures
I metioned this above, but let me restate this. Your events do not have to indicate a problem. They may be a part of your architecture. They may even be a good thing, such as our order example above. Who doesn’t want more sales, right? With CloudWatch Events, your microservices can submit events and those events can trigger other microservices to perform some actions. This is a nice and scalable way of building event-driven architectures on AWS.
Conclusion
Amazon CloudWatch alarms and events both allow you to build an automated architecture to monitor the performance of your workload and take proactive or reactive actions on them. They are serverless, so you do not manage any servers for them. But sometimes, understanding the differences between these two fabulous features may be confusing. I hope this post helps you in that case.
By the way, please check out my online AWS courses. I will be happy to see you there, if you are interested.
Thanks for reading!
References
- Using CloudWatch Alarms
- Using CloudWatch Metrics
- What is CloudWatch Events?
- Alarm events and EventBridge
