AWS EventBridge — Intro

8 min readOct 26, 2024

A brief introduction to AWS EventBridge

Amazon EventBridge is a serverless, fully managed, and scalable event bus that enables integrations between AWS services, SaaS, and our custom applications.

EventBridge delivers a stream of real-time data from configured sources to targets such as AWS Lambda functions, HTTP invocation endpoints using API destinations, or event buses in other AWS accounts.

Features of EventBridge

Advanced Event Rules Filtering

We can filter events, that are of interest, with rules. We can have multiple rules that match the same event, so different consumers can choose to match events based on specific filters.

Content-based Event Filtering

EventBridge supports declarative content filtering using event patterns. With content filtering, we can write complex event patterns that only match events meeting our consumer expectations.

It supports the following types of pattern matching:

Prefix / Suffix matching

{
  "detail": {
    "createdAt": [{ "prefix": "2024-10-" }]
  }
}

{
  "detail": {
    "filename": [{ "suffix": ".png" }]
  }
}

Anything-but matching.

{
  "detail": {
    "provider": [ { "anything-but": { "prefix": "CREDIT_" } } ]
  }
}

{
  "detail": {
    "provider": [ { "anything-but": { "suffix": "DECLINED" } } ]
  }
}

Numeric matching

{
  "detail": {
    "age": [ { "numeric": [">=": 30, "<=": 39] } ]
  }
}

IP address matching

{
  "detail": {
    "sourceIPAddress": [ { "cidr": "10.0.0.0/24" } ]
  }
}

Exists matching

{
  "detail": {
    "ProductName": [ { "exists": true } ]
  }
}

Complex example with multiple matching.

Message Transformation

EventBridge can transform target inputs. In specific use cases, we might want to customize the text of event fields before passing them to a target so that these fields provide more meaningful information to process them further.

Event → InputPath →InputTemplate →Output

{
    "region": "$.region",
    "detail-type": "$.detail-type",
    "source": "$.source"
}

{
    "source": "<source>",
    "detail-type": "<detail-type>",
    "region": "<region>"
}

Custom Events

We can send custom events from our own applications to an event bus. Other applications can receive events through any of supported AWS target services.

Schema Registry

Schema registries are containers for schemas. EventBridge schema registry stores event schema in a registry that other developers can easily search and access, so we don’t have to find events and their structure manually.

Archive and Replay Events

We can create an archive of events so that we can easily replay (reprocess) them at a later time.

SaaS Apps Integration

EventBridge is natively integrated with SaaS applications from many providers including Datadog, PagerDuty, SugarCRM, Zendesk, and many more.

API Destinations

API destinations are a great feature of Amazon EventBridge, that allows us to forward our events to consumers through HTTP. This allows us to integrate with services outside of AWS using REST API calls. If we have an internal or external API that wants to receive events through EventBridge we can configure a rule and create an API destination to route events to this consumer. It can help decouple applications and produce more extensible, maintainable architectures.

Scheduled events

We can set up scheduled events using the popular Unix cron syntax. Scheduled events are generated on a periodic basis and invoke any of the supported target AWS services.

Many built-in event sources and targets

EventBridge is directly integrated with over 130 event sources and over 35 targets, including Lambda, SQS, SNS, Step Functions, Kinesis, and many more.

Reliable event delivery

EventBridge provides at-least-once event delivery to targets, including retry with exponential backoff for up to 24 hours. Events are stored durably across multiple Availability Zones (AZs).

Global Endpoint

A global endpoint is a managed Amazon Route 53 DNS endpoint. It routes events to the event buses in either Region, depending on the health of the service in the primary Region. Global endpoints provide a simpler and more reliable way for us to improve the availability and reliability of event-driven applications. The feature allows us to fail over event ingestion automatically to a secondary Region during service disruptions. Global endpoints also provide optional managed event replication, simplifying our event bus configuration and reducing the risk of event loss during any service disruption.

Global endpoints can be optionally configured to replicate events across Regions. When enabled, managed rules are created on our primary and secondary event buses that define the event bus in the other Region as the rule target.

Components

When we talk about EventBridge, there are four major components that we need to understand.

Events

An event is a real-time change in a system, data, or environment. This change can be either in our application, or, in an AWS service, or, from a SaaS partner service. Events are JSON messages containing various attributes to define the source and the data required by the target applications or services for further processing.

Event Source

An event source is used to ingest events from a SaaS partner, AWS Services, or our own applications.

Event Bus

An event bus is a broker that receives events. Each AWS Account comes configured with a default event bus, which receives events from all eligible AWS services.

Event Bus Types:

Default event bus: Created by default and receives events from any AWS service.
Custom event bus: Receives events from custom applications we create and must be created manually.
Partner event bus: Receives events from SaaS partner applications and must be created manually.

Event Rule

A rule associated with the event bus matches (based on rule criteria) events as they arrive and sends them to targets for processing. A single rule can send an event to multiple targets, which then run in parallel. Rules are based either on an event pattern or a schedule.

An event pattern defines the event structure and the fields that a rule matches. It supports the following types of pattern matching:

Prefix Matching | Anything-but Matching | Numeric Matching | IP Address Matching | Exists Matching | Complex Example with Multiple Matching

# Filter for AWS Health events
{
  "source": [ 
    "aws.health"
  ],
  "detail-type": [
    "AWS Health Event"
  ]
}
# Filter for AWS Autoscaling events
{
  "source": [ 
    "aws.autoscaling"
  ],
  "detail-type": [
    "EC2 Instance Launch Unsuccessful",
    "EC2 Instance Terminate Unsuccessful",
    "EC2 Auto Scaling Instance Refresh Failed"
  ]
}
# Filter for AWS ECR Image scans
{
  "source": [
    "aws.ecr"
  ],
  "detail-type": [
    "ECR Image Scan"
  ],
  "detail": {
    "scan-status": ["COMPLETE"],
    "finding-severity-counts": {
      "$or": [
        {"CRITICAL": [{"numeric": [">", 0]}]},
        {"HIGH": [{"numeric": [">", 0]}]},
        {"MEDIUM": [{"numeric": [">", 0]}]},
        {"UNDEFINED": [{"numeric": [">", 0]}]}
      ]
    }
  }
}
# Filter for AWS SSM Automation events
{
  "source": [ 
    "aws.ssm"
  ],
  "detail-type": [
    "EC2 Automation Execution Status-change Notification"
  ],
  "detail": {
    "status": [
      "Failed",
      "TimedOut"
    ]
  }
}

Rules that are based on a schedule perform an action at regular intervals.

Event Target

A target (event consumer) is a resource or endpoint that EventBridge sends an event. To deliver event data to a target, EventBridge needs permission to access the target resource. We can define up to five targets for each rule.

An API destination consists of three components:

HTTP Endpoint: The URL of the target system or application.
HTTP Method: The HTTP method to use for the request (e.g., GET, POST, PUT).
Connection: The authorization method and credentials used to authenticate the request (e.g., basic auth, OAuth, API key).

Apart from the four components mentioned above, two new components in EventBridge are worth noting.

Pipes

Pipe allows us to connect event producers (sources) with consumers (targets) through a point-and-click interface, eliminating the need for custom code to filter and transform events. Pipes are used for point-to-point asynchronous communication between specific AWS services. Unlike event buses, pipes are explicitly configured to receive events from a single source. Pipes can also filter and enrich the events with more information before sending them to a defined single target.

Currently, supported event sources in pipes are:

DynamoDB stream
Kinesis stream
Amazon MQ message broker
Amazon MSK topic
Self-managed Kafka stream
Amazon SQS Queue

The pipe allows users to:

Filter: Filtering in EventBridge pipes allows us to process only a subset of events from the source that matches certain criteria. To configure filtering on a pipe, users define an event pattern the pipe uses to determine which events to send to the target.
Enrichment: Users can enhance the data from the source before sending it to the target. For example, users might receive ‘Ticket created’ events that don’t include the full ticket data.

The enrichment is performed in four ways:

Lambda functions
Step functions
API Gateway
API Destinations

One example of a Pipe can be to send the message from SQS to Step Function.

EventBridge Scheduler

EventBridge Scheduler is a serverless scheduling service that allows for the creation, execution, and management of scheduled tasks on a massive scale. It supports invoking various AWS services as targets, providing a centralized management console for all users’ scheduled jobs.

Some numbers to note for EventBridge

It is possible to configure 300 rules on each event bus
Any Rule can forward the events to 5 targets at max.
The maximum size for an event payload is 256 KB
The default retry policy in EventBridge will retry delivery for 24 hours with up to 185 attempts, using exponential back-off and jitter (randomized delays) to avoid overwhelming the system or network.
EventBridge latency is around 500ms. For SNS the latency is around 50ms.
EventBridge also provides a 99.99% availability SLA

Montioring EventBridge

EventBridge exposes the following metrics so that we know the performance of the bus.

TriggeredRules
MatchedEvents
Invocations
FailedInvocations
InvocationsSentToDlq
ThrottledRules

Debugging

We can debug an event bus by sending the event to the CloudWatch log group and then query it using insights.