Amazon EventBridge is a powerful service for Event-Driven Architecture (EDA). Its scalability and serverless nature make it an ideal tool for cloud enterprise projects, working with events generated by applications, integrated Software-as-a-Service (SaaS) applications and other services. The increased adoption of EDA has seen an explosion in event-driven messaging on the back of transformation projects and the embrace of IoT (Internet of Things).
Intelligent Pathways use EventBridge across multiple client applications to orchestrate events in both serverless and more traditional architectures. It is becoming a critical tool in facilitating an organisation’s timely response to their customers’ actions, and how IT proactively manages system performance parameters. Below is a detailed overview of EventBridge applied for one of our client use cases, and an evaluation of its effectiveness in meeting solutions requirements.
Several of the applications we have built for clients use AWS EventBridge as the core mechanism to distribute “Events” between the various components of the solution. At a high level EventBridge consists of the following:
The following are some examples of event rules that have been configured to deliver these events to various Targets:
- Match all events and delivery to a Lambda function to persist all Events to DynamoDB
- Match all Auth0 Events from a central AWS Account to the default Event Bus in application specific AWS Accounts
- Match SendEmail events for a Lambda function to send email (content in the event payload) via SendGrid or SES
- Match specific DynamoDB update events to trigger refresh of permissions used by AWS Quicksight to enable row level permissions (e.g. when a Client record is updated in the application)
EventBridge in Practice
Below is an evaluation of EventBridge as applied for a recent Client, detailing the process of adopting the tool alongside an event-driven approach.
In the early stages of the application, “Event Framework” was just a component of the architecture and a specific technology had not been confirmed. As the solution progressed, the “Event Framework” requirements started to evolve. The following scenarios were considered during this phase:
- How can we proactively respond to application users who lock themselves out of their Auth0 account?
- How can we capture the time an application user first logs into the platform and updates their profile?
- How can we respond to changes in user/product/client data asynchronously without embedding all the logic in the core Amplify application?
- How can we add additional logic to this processing without requiring a redeployment of the Amplify application?
- How can we implement this Events framework with minimal changes to the existing serverless architecture?
- How can business events generated in one component trigger other events or processes in the platform without tight coupling between the components?
A small set of example events that are published by components within the Application include:
- Auth0 Logins – received from Auth0 via EventBridge partner integration
- User Accepted Terms and Conditions – sent from Lambda function invoked from API Gateway
- Candidate Updates (new/old values generated from DynamoDB Streams)
- Request Email sending – sent from Lambda function (Appsync custom resolver)
Event Framework Non-Functional Requirements (NFRs)
Non-functional requirements (NFRs) were key to helping ensure a successful implementation and reduce the risks to the application that was already in production. The following were some of the core non-functional requirements that were considered during the design of the Events Framework:
- Ease of operation – the Application team did not have the capacity or skills to manage a complex solution that would require a custom installation and high overhead of management.
- Serverless – the entire Application platform was designed to be 100% serverless, so ideally the event platform would integrate into this existing platform design.
- Low cost of entry and ongoing operation – due to the initial budget and predicted client rollout the cost of the solution needed to scale inline with the expected usage.
- Ease of deployment – the entire Application platform was managed by Infrastructure as Code and the events framework needed to follow suit.
- Scalability – the initial rollout of the Application platform would start with low usage but the expectation was for a large update and high usage.
- Security – due to the sensitivity of the platform/user data any solution would need to integrate tightly with the existing platform security.
- Ease of integration with existing components – publishing and receiving events from existing AWS components (e.g. Lambda functions) must be straightforward
- Ease of development – publishing events needed to be straight forward and use an SDK/library familiar to the developers.
How EventBridge Addressed the NFRs
EventBridge in Production
EventBridge has been deployed to the application:
- 4 Partner event sources (App services AWS Account) – one for each Auth0 tenant
- Each Partner event source has two Rules associated with that EventBus
- 3 EventBuses in the Application Production account. One for each environment: Production + Demo + Training
- Each EventBus has 10 Rules configured
- 12 EventBuses in the Application Non-Production account. One for each main environment (dev + test + staging + rc) and one for each member of the development team.
- Development environments now have 11 Rules configured
Amazon EventBridge very effectively meets the goals listed above. Crucially it has been:
- very easy to integrate with existing application components
- operable without involvement from an operations team
- run at a very low cost (less than $1)
Integrating EventBridge with CloudWatch alarms
For another Client, we also use EventBridge with CloudWatch alarms to help orchestrate and manage alarms across multiple applications. This has proved a particularly effective approach, as the increased customisation and filtering capabilities promote decoupling, reduce unnecessary costs on lambdas triggered for irrelevant alarms, and ensures the right alarms are sent to the right places. See the architecture of this solution below.