Amazon recently announced EventBridge to much fanfare. Although, in truth, it’s a rebranding of the existing CloudWatch Events service, along with some new features. But rebranding might be exactly what this old dog needs!
You see, CloudWatch Events is a powerful service that had been badly marketed by AWS. Its primary function is to deliver system and user events in real-time. You know, like an event bus. For some reason, it was marketed with the CloudWatch “brand”. A brand that is mainly associated with service monitoring. As such, most AWS users only know CloudWatch Events for simple cron jobs. Even though it is capable of capturing user-published events as well as system events from other AWS services, and delivering them in real-time to a vast array of targets. For large enterprises that prefer to centralize their application governance, CloudWatch Events can also deliver events across AWS accounts. This allows you to monitor activities in all your AWS accounts from a single place.
All of these capabilities are still there for EventBridge. But they have been extended to support custom events from AWS’s partners such as DataDog, OneLogin and PagerDuty. This opens up an entirely new way to integrate with these SaaS platforms.
Previously, you would have to rely on webhooks. Which involves all the usual overhead of building, running and maintaining APIs. Now all that becomes somebody else’s problem! AWS is going to look after the plumbing around ingesting these partner events. You can handle these events using Lambda functions, or forward them to one of the other supported targets.
You can have multiple targets for the same event. For example, when DataDog sends an alert event to EventBridge you might wish to handle the event with a Lambda function and execute auto-remediation pipelines and runbooks. At the same time, you can also send the event to a Firehose delivery stream so you can query these events with Athena later.
You can also augment these partner events with custom user events from your application. Following the previous example, the Lambda function can also publish custom events to EventBridge. These events might describe the auto-remediation steps that were taken. Since all these events can be forwarded to a Firehose delivery stream, you can build up a complete audit trail of everything that happened. What alerts were triggered? What did the function do in response? And what was the result of these actions (in the form of other system events such as EC2 instance terminations, etc.)?
In recent times, the Function-as-a-Service (FaaS) paradigm has opened up new ways of integrating with SaaS platforms using functions. Auth0 Extend is a prime example of that, allowing customers to handle events by shipping their own code to Auth0. However, these functions often need to communicate back to the customer’s home base, that is, their own application running in AWS.
EventBridge takes things a step further and brings the partner events closer to your application. AWS takes care of the event ingestion so you can focus on the things that will add value to your business.