funkyfrogstock - Fotolia
Event-driven architectures provide a framework to orchestrate behavior around the production, detection and consumption of a change in state, also known as an "event." Amazon EventBridge expands the ways developers can build event-driven architectures on AWS through third-party SaaS integrations and more diverse serverless capabilities.
The main principle of an event-driven architecture is the ability to automatically trigger actions in response to events in components that are part of an application's workflow. Due to the cloud's API-driven nature and the availability of messaging platforms that facilitate interactions among loosely coupled distributed systems, an event-driven architecture is a particularly popular framework for the cloud.
In this article we'll review the capabilities and potential use cases for EventBridge. We'll also see how it compares to its primary predecessor for building and deploying event-driven architectures in AWS.
Amazon CloudWatch Events vs. EventBridge
AWS first began providing tools for event-driven architectures through its monitoring service, Amazon CloudWatch. In early 2016, AWS introduced Amazon CloudWatch Events, which became the foundation for deploying event-driven architectures in its cloud.
CloudWatch Events detects changes in state for AWS components, such as when an EC2 instance is terminated or a task is launched in ECS. IT teams can set the service to trigger a number of actions in response to an event by invoking a specific AWS API in response to a supported AWS event or a configured schedule. For example, users can set up a CloudWatch rule to stop an EC2 instance every evening at 5:01 p.m. to avoid being charged for unused resources after employees sign off for the day. With CloudWatch Events, users can also submit their own events and configure actions in response to those custom events.
Amazon EventBridge, a serverless event bus, expands AWS' functionality for event-driven architectures. While CloudWatch Events is mainly geared to detect changes in state for AWS components, EventBridge supports a number of external SaaS systems, too.
IT teams also have more flexibility in managing custom events with EventBridge. CloudWatch Events works with a single, default event bus, but EventBridge users can create multiple event buses and configure which AWS accounts or organizations can publish events to a particular event bus. These users can develop multiple event-driven applications and manage them in an isolated way, if needed.
EventBridge offers SaaS compatibility
With EventBridge, IT teams can incorporate event sources from prominent third-party SaaS vendors such as Datadog, PagerDuty, Zendesk and Symantec. They configure a partner integration in both AWS and the SaaS platform, which enables actions in AWS to be triggered by any of the supported SaaS products. Data from these external systems can easily be ingested into applications deployed on AWS, which expands what developers can build with event-driven architectures on AWS. EventBridge has third-party integrations that support a range of application needs, including customer support, operations, application monitoring, CRM, online payments, cyber security, CI/CD pipelines and calendars.
This combination of external event sources and multiple event buses opens the door to a range of use cases. For example, you could have EventBridge trigger the execution of workflows managed by Step Functions. Incoming data could be retained in Amazon S3, or any of the other AWS data storage services, for further analysis. You could also set EventBridge to forward events to Amazon Kinesis Data Stream to capture data that is then processed by downstream applications. Additionally, machine learning models could be applied to incoming data for sentiment analysis or to calculate predictions, and business Intelligence dashboards could be built with incoming data from these external systems.
Let's dive in a little deeper and explain how a few of these SaaS integrations work with EventBridge. For example, a user login with a partner app such as Auth0 or OneLogin can trigger an event that can be persisted in S3 for future analysis and auditing. That login could also trigger a custom action in Lambda, such as presenting users with customized app content. A metric event triggered by apps such as New Relic, SignalFx, Epsagon or Datadog can result in custom remediation actions implemented in Lambda. More complex remediation tasks can also be orchestrated using Step Functions. This is also a good extension of your default CloudWatch metrics, since some SaaS partners offer detailed metrics at the infrastructure and application level, which are not available in CloudWatch by default.
Another strong EventBridge use case is with Zendesk, a customer service software company. Customer support events published by this SaaS product can be processed using AWS machine learning to provide sentiment analysis. These can also be converted into CloudWatch metrics, which can be correlated to system health metrics. Events from this app can also be persisted in S3, where they can be further analyzed using tools such as Amazon Athena and visualized using Amazon QuickSight.
The list of partner SaaS integrations is expected to grow, which will expand the number of use cases available to AWS users who operate serverless architecture.
AWS event-driven architecture pricing and availability
In terms of cost, CloudWatch Events and EventBridge have the same pricing model. Events generated by AWS resources are free and custom events are charged at $1 per million events. For EventBridge, this pricing includes third-party SaaS events.
Amazon CloudWatch Events is expected to remain functional and will not be deprecated in favor of EventBridge. However, AWS users are advised to use the EventBridge AWS SDK libraries instead of CloudWatch Events for new event-driven applications. This will ensure applications can use the wider range of features and SaaS integrations that EventBridge offers and be safe from any potential deprecation in the future. But for now, users shouldn't migrate applications built using CloudWatch Events to EventBridge, as that move can be complex and CloudWatch Events will continue to work.