What is Amazon EventBridge – A short introduction

Introduction

Amazon EventBridge enables developers to decouple applications using a serverless event bus and route messages to different recipients based on various requirements.

The core of EventBridge is the so-called Event Bus, as well as processing rules that control which recipient (known as target) a message is sent to. A single event bus can contain up to 300 rules. A rule in turn can have up to 5 recipients to which the message is distributed. A wide variety of AWS services or SaaS applications can deposit messages on an associated event bus for further processing.

A theoretical setup in EventBridge could look like this:

In the example above, two rules have been assigned to the Default Event Bus.

• Rule 1 sends matching messages to a Lambda-Function
• Rule 2 sends incoming messages to CloudWatch logs

A rule is a simple JSON-Object that validates incoming events based on the required attributes.
For example, a basic rule could have the following content:

{
  "source": ["myapp"],
  "detail-type": ["logs"]
}

All incoming events that have myapp as source and logs in detail-type are sent to the targets associated with that rule. These rules can be arbitrarily complex and can contain numerical comparisons, links (and/or) or the matching of prefixes.

An overview of all filtering options can be found in the docs:

• Content filtering in Amazon EventBridge event patterns

If a message cannot be handed over to the target, EventBridge tries to deliver it for 24 hours (by default). This so-called Retry-Policy can also be customized based on user requirements so that a guaranteed delivery can be ensured.

• Note: If messages are not successfully delivered despite all efforts, a Dead-Letter-Queue (DLQ) can be used to further analyze the failed events.

In addition, EventBridge offers developers the ability to pre-process incoming messages before they are sent to their appropriate recipient. This can be achieved with the so-called Input Transformer, which defines the content of the message that is sent to the target, should the corresponding rule apply. Unnecessary or irrelevant information can thus be deleted from the message before the actual processing.

Example Architecture

In the following application, Amazon EventBridge is used as an intermediary service between API and the related backend services. Incoming requests arrive on the event bus in EventBridge and are forwarded to the associated targets according to the corresponding rules. As in the introductory example, two rules were created on the event bus, which forward matching messages to a Lambda-Function for processing or to CloudWatch Logs for output/analysis. Events with no applicable rule will be automatically discarded.

Practical Implementation

There are numerous tutorials on the Internet for the implementation and use of Amazon EventBridge. Alternatively IaC solutions such as CloudFormation or AWS CDK can be used to create the infrastructure with common programming languages.

Generally speaking, the following resources are needed:

1. Lambda-Function
   If a Lambda-Function is used as a target, it must first be created so that it can be referenced when the corresponding rule is created.
2. EventBridge Bus/Default Event Bus
   Depending on your needs, you can either use the default event bus of EventBridge or create your own.
3. EventBridge Rules & Targets
   Create the corresponding rule with the associated targets on the event bus. The EventPattern (JSON) must be defined on whose basis the incoming messages are validated on. If the event matches the pattern, the message can be sent to the associated recipient. An input transformer can be defined when creating the rule. This allows the message to be forwarded to be reduced to the necessary content according to the developer’s wishes.
4. IAM Policy & Role
   A role with an associated policy is required that allows the storage of events on the default event bus or the self-created event bus.
5. HTTP-API
   The EventBridge integration is possible with both HTTP- and REST API
   (In this example, an HTTP API was used).
   When creating the corresponding route, a POST method is required, which can then be used to select EventBridge via the service integration option.
   Here, the previously created role must be referenced in order to give the API the necessary permissions to store the messages.

Test the Integration

EventBridge Rules

{
  "source": ["http-api"],
  "detail-type": ["invoke-lambda"]
}

The first rule forwards messages to the associated Lambda-Function for processing.

{
  "source": ["http-api"],
  "detail-type": ["log-message"]
}

The second rule sends messages to a CloudWatch Log Group for analysis purposes.

API-Request

Two Requests are sent via Postman to the endpoint associated with EventBridge.

Request 1:

{
    "Source": "http-api",
    "DetailType": "invoke-lambda",
    "Detail": {
        "message": "Hello, world!"
    }
}

Request 2:

{
    "Source": "http-api",
    "DetailType": "log-message",
    "Detail": {
        "message": "Hello, world!"
    }
}

Results

The first request is sent only to the corresponding Lambda-Function according to the associated rule. Here, a simple input transformer was also defined, which only passes a part of the message to the function. The following output can be observed:

{
    source: 'http-api',
    'detail-type': 'invoke-lambda',
    detail: { message: 'Hello, world!' }
}

For the second request, a CloudWatch Log Group was defined as a target to allow a simple output of the request sent through the API.
Here the output looks like this:

{   
    "version": "0", 
    "id": "de4642d4-2ff5-8e38-db82-261ed10c8512", 
    "detail-type": "log-message", 
    "source": "http-api", 
    "account": "XXX", 
    "time": "2022-07-07T10:16:31Z", 
    "region": "eu-central-1", 
    "resources": [], 
    "detail": { "message": "Hello, world!" } 
}

If you compare the two results, you will notice that the content of both differs.
This is due to the previously mentioned input transformer, which has been defined for the rule associated with the Lambda-Function.

Summary

With EventBridge it is possible to granularly control which messages are sent to which recipients of an application. Events are validated based on previously created rules and sent to the corresponding targets. Messages can be filtered with nearly any level of granularity and adjusted via input transformers before delivery so that only necessary information is forwarded. If a message delivery is not successful, the number of repeated deliveries can be defined via the Retry Policy. Thus, the flow of information within an application can be guaranteed and precisely controlled, so that each component receives only the messages it requires.

If you have any further questions about Amazon EventBridge or developing distributed applications on AWS, please feel free to contact me. Also, feedback of any kind on this blog post is welcome.