Many AWS customers also make great use of SaaS (Software as a Service) applications. For example, they use Zendesk to manage customer service & support tickets, PagerDuty to handle incident response, and SignalFx for real-time monitoring. While these applications are quite powerful on their own, they are even more so when integrated into a customer’s own systems, databases, and workflows.
New Amazon EventBridge
In order to support this increasingly common use case, we are launching Amazon EventBridge today. Building on the powerful event processing model that forms the basis for CloudWatch Events, EventBridge makes it easy for our customers to integrate their own AWS applications with SaaS applications. The SaaS applications can be hosted anywhere, and simply publish events to an event bus that is specific to each AWS customer. The asynchronous, event-based model is fast, clean, and easy to use. The publisher (SaaS application) and the consumer (code running on AWS) are completely decoupled, and are not dependent on a shared communication protocol, runtime environment, or programming language. You can use simple Lambda functions to handle events that come from a SaaS application, and you can also route events to a wide variety of other AWS targets. You can store incident or ticket data in Amazon Redshift, train a machine learning model on customer support queries, and much more.
Everything that you already know (and hopefully love) about CloudWatch Events continues to apply, with one important change. In addition to the existing default event bus that accepts events from AWS services, calls to
PutEvents, and from other authorized accounts, each partner application that you subscribe to will also create an event source that you can then associate with an event bus in your AWS account. You can select any of your event buses, create EventBridge Rules, and select Targets to invoke when an incoming event matches a rule.
As part of today’s launch we are also opening up a partner program. The integration process is simple and straightforward, and generally requires less than one week of developer time.
All About Amazon EventBridge
Here are some terms that you need to know in order to understand how to use Amazon EventBridge:
Partner – An organization that has integrated their SaaS application with EventBridge.
Customer – An organization that uses AWS, and that has subscribed to a partner’s SaaS application.
Partner Name – A unique name that identifies an Amazon EventBridge partner.
Partner Event Bus – An Event Bus that is used to deliver events from a partner to AWS.
EventBridge can be accessed from the AWS Management Console, AWS Command Line Interface (CLI), or via the AWS SDKs. There are distinct commands and APIs for partners and for customers. Here are some of the most important ones:
Amazon EventBridge for Partners & Customers
As I noted earlier, the integration process is simple and straightforward. You need to allow your customers to enter an AWS account number and to select an AWS region. With that information in hand, you call
CreatePartnerEventSource in the desired region, inform the customer of the event source name and tell them that they can accept the invitation to connect, and wait for the status of the event source to change to ACTIVE. Then, each time an event of interest to the customer occurs, you call
PutPartnerEvents and reference the event source.
The process is just as simple on the customer side. You accept the invitation to connect by calling
CreateEventBus to create an event bus associated with the event source. You add rules and targets to the event bus, and prepare your Lambda functions to process the events. Associating the event source with an event bus also activates the source and starts the flow of events. You can use
ActivateEventSource to control the flow.
Here’s the overall flow (diagram created using SequenceDiagram):
Each partner has the freedom to choose the events that are relevant to their application, and to define the data elements that are included with each event.
Starting from the EventBridge Console, I click Partner event sources, find the partner of interest, and click it to learn more:
Each partner page contains additional information about the integration. I read the info, and click Set up to proceed:
The page provides me with a simple, three-step procedure to set up my event source:
After the partner creates the event source, I return to Partner event sources and I can see that the Zendesk event source is Pending:
I click the pending event source, review the details, and then click Associate with event bus:
I have the option to allow other AWS accounts, my Organization, or another Organization to access events on the event bus that I am about to create. After I have confirmed that I trust the origin and have added any additional permissions, I click Associate:
My new event bus is now available, and is listed as a Custom event bus:
I click Rules, select the event bus, and see the rules (none so far) associated with it. Then I click Create rule to make my first rule:
I enter a name and a description for my first rule:
Then I define a pattern, choosing Zendesk as the Service name:
Next, I select a Lambda function as my target:
I can also choose from many other targets:
After I create my rule, it will be activated in response to activities that occur within my Zendesk account. The initial set of events includes
StatusChanged. Each event includes a rich set of properties; you’ll need to consult the documentation to learn more.
Partner Event Sources
We are launching with ten partner event sources, with more to come:
If you have a SaaS application and you are ready to integrate, read more about EventBridge Partner Integration.
Amazon EventBridge is available now and you can start using it today in all public AWS regions in the aws partition. Support for the AWS regions in China, and for the Asia Pacific (Osaka) Local Region, is in the works.
Pricing is based on the number of events published to the event buses in your account, billed at $1 for every million events. There is no charge for events published by AWS services.
PS – As you can see from this post, we are paying even more attention to the overall AWS event model, and have a lot of interesting goodies on the drawing board. With this launch, CloudWatch Events has effectively earned a promotion to a top-level service, and I’ll have a lot more to say about that in the future!
Originally posted on AWS News Blog
Author: Jeff Barr