The Value Proposition of EventBridge Pipes

3 min readMar 2

By: Yehuda Cohen

At AWS re:Invent 2022, Werner Vogels announced EventBridge Pipes, a service targeted at simplifying real-time integrations. A plethora of integration patterns already exist in AWS’s tool arsenal, including API gateways, message topics and queues, event buses, orchestration tools, and streams. Understanding yet another communication service’s unique value proposition within AWS’s ecosystem can pose a challenge. This article explores EventBridge Pipes’ position in the AWS integration toolbox and the class of problems it simplifies.

Note that this article does assume some basic knowledge about EventBridge buses, event rule evaluations, and message queue and data stream mechanics.

What is EventBridge Pipes

Since EventBridge Pipes is so new, the prudent place to start might be the documentation’s description of the feature:

Amazon EventBridge Pipes connects sources to targets. It reduces the need for specialized knowledge and integration code when developing event-driven architectures, fostering consistency across your company’s applications. To set up a pipe, you choose the source, add optional filtering, define optional enrichment, and choose the target for the event data.

The documentation also includes the following graphic illustrating the functionality enabled by an EventBridge pipe:

This description of EventBridge Pipes paints the picture of an all-purpose adapter as a service. It would seem that, like the value proposition of EventBridge buses and rules, Pipes help decouple producer and consumer systems.

This seems a little familiar…

Before proceeding, I want to contrast this feature description with one from the EventBridge features page describing event buses:

EventBridge makes it easier for you to build event-driven application architectures. Applications or microservices can publish events to the event bus without awareness of subscribers. Applications or microservices can subscribe to events without awareness of the publisher. This decoupling helps teams work independently, leading to faster development and improved agility.

In other words, the value propositions for traditional EventBridge buses and new EventBridge Pipes are similar.

Both constructs decouple producer systems from consumer systems. Both enable event filtering and payload transformation.

There are some differences…

Notwithstanding the similarities in the value propositions of EventBridge buses and pipes, there are some significant differences that help us decide which EventBridge primitive to use.

Supported Services

The list of supported services for EventBridge Pipe sources tells us a lot about the use cases EventBridge Pipes aims to enable in the AWS communication ecosystem. The six supported Event Sources are:

Integrate more easily with existing services

Prior to the release of EventBridge Pipes, engineers who wished to process events in a stream or queue and leverage EventBridge’s filtering and delivery capabilities needed to write their own stream processor or a queue listener. EventBridge Pipes allows users to leverage EventBridge’s filtering and routing capabilities without writing any additional integration code.

Eventbridge Pipe sources are all pull-based

AWS architects might notice two event sources conspicuously absent from the above list: Amazon SNS topics and EventBridge Buses. Although EventBridge Pipes can deliver events to SNS topics and EventBridge buses, they are not among the supported event sources.

This supported list of event sources highlights important new functionality available in EventBridge, but it is an exhaustive list and therefore highlights some of the limitations of pipes at the same…

Continued on CloudDataInsights.com

The Value Proposition of EventBridge Pipes

What is EventBridge Pipes

Written by RTInsights Team