Introducing AWS CloudWatch Events
Amazon recently announced changes to the way customers can monitor their AWS resources. The service, known as CloudWatch Events, allows customers to consume a near real-time stream of events as changes to their AWS environment take place. These event changes can subsequently trigger notifications, or other actions, through the use of rules.
Traditionally, customers had to rely upon writing their own scripts and tools that would call management APIs, in an inefficient polling fashion, in order to understand the current health of their services. Customers would then compare this current information against historical information in order to determine a change in state. In order to reduce the amount of time customers spend building these types of tools, Amazon has released CloudWatch Events.
CloudWatch Events can monitor actions such as an EC2 instance being launched or shut down and detecting when an auto-scale event occurs. CloudWatch Events can also detect when services are provisioned, or terminated, including Amazon DynamoDB tables, Amazon SNS topic or Amazon SQS.
CloudWatch Events get triggered through the use of rule policies. Rules can be setup in minutes and allow administrators to route CloudWatch Events to one or more other AWS services including AWS Lambda functions, Amazon Kinesis streams, Amazon SNS topics.
Jeff Barr, chief evangelist at AWS, positions the service as a centralized orchestrator: “You can think of CloudWatch Events as the central nervous system for your AWS environment. It is wired in to every nook and cranny of the supported services, and becomes aware of operational changes as they happen. Then, driven by your rules, it activates functions and sends messages (activating muscles, if you will) to respond to the environment, making changes, capturing state information, or taking corrective action.”
There are three main components that make up CloudWatch Events:
- Events which are represented as small JSON blobs and can be generated in four different ways:
- When a service changes state, such as a service moving from a pending to running state.
- Through API calls or console sign-ins that reach CloudWatch Events from CloudTrail.
- Custom code can publish application specific events to CloudWatch Events.
- Through a scheduled Cron-like job.
- Rules evaluate incoming events to determine if a threshold or out-of-bounds scenario exists. If true, the event will then be routed to a target for processing.
- Targets process the events that have been passed from a rule. A rule may invoke multiple targets and the JSON representing the event can also be manipulated prior to it being passed off to the target. At launch, Amazon will support four different types of targets:
- Built in (out-of-box)
- Lambda functions
- Kinesis streams
- SNS topics
From a pricing perspective, customers will have options in how they deploy CloudWatch Events. There is a free tier which Amazon claims “many applications should be able to operate within these free tier limits.” The free tier will allow new and existing customers to receive 3 dashboards and up to 50 metrics per month at no additional charge. Basic monitoring, at five minute intervals, will also be available for Amazon EC2 instances free of charge. For more details on what is included in the free tier and additional pricing for more coverage, please visit the Amazon pricing page.
It is reasonable that if developers opt to attach other services to their events that those will be metered differently.