Amazon EventBridge vs Apache Kafka
EventBridge and Apache Kafka are often put side by side because both sit in the middle of an event-driven architecture, but they are different kinds of component. EventBridge routes an event to whoever should hear about it. Kafka is a durable, partitioned log that consumers read at their own pace and can re-read from any offset.
What EventBridge gives an application
Section titled “What EventBridge gives an application”- Integration with AWS services needs configuration, not code — a rule and a target
- Retries and dead-letter queues are built in, so failure handling is not application code
- Filtering and per-target transformation happen in the service, keeping event-handling code clean
- Schema discovery and versioning are available through the schema registry
- JSON event patterns keep routing logic declarative and reviewable
- Nothing to size, patch or scale
What Kafka gives an application
Section titled “What Kafka gives an application”- Replay from any offset, which makes recovery and debugging tractable
- Strict ordering within a partition
- Consumer groups: horizontal scaling by adding consumers, and independent consumption of the same topic by unrelated applications
- Serialisation formats other than JSON — Avro and Protobuf, with a schema registry
- Backpressure as a protocol feature, so a slow consumer slows itself rather than losing data
- Fine-grained control over delivery semantics, up to transactional exactly-once
The differences that decide it
Section titled “The differences that decide it”| Amazon EventBridge | Apache Kafka | |
|---|---|---|
| Operations | Fully managed | Self-managed, or Amazon MSK / Confluent |
| Throughput | A per-Region PutEvents quota (10,000/s in the largest Regions, 400/s in many others), adjustable | Bounded by the cluster; millions of events per second is achievable |
| Retention | None by default. An archive retains events and can replay them to the source bus; a failed delivery is retried for up to 24 hours and then dead-lettered or dropped | Configurable per topic, up to indefinite |
| Ordering | Attempted, not guaranteed | Strict within a partition |
| Replay | From an archive, back onto the same bus | From any offset, by any consumer |
| Consumer model | Push to at most five targets per rule | Pull, with consumer groups and independent offsets |
| Message size | 256 KB | Configurable, 1 MB by default |
| Filtering | Rich patterns evaluated in the service | Client-side, or in a stream processor |
| Cost model | Per event published | Infrastructure, storage and data transfer |
The retention row is the one most often got wrong. EventBridge’s widely quoted “24 hours” is the retry window for a failed delivery, not a retention period: an event that has been delivered is gone, and an event that never matched a rule was never stored at all. If events must be recoverable, that has to be designed in — an archive, a dead-letter queue, or a target that persists them.
Partitions and ordering
Section titled “Partitions and ordering”EventBridge has no equivalent of a Kafka partition. Its concepts are:
- Event buses, which collect events but have no internal partitioning
- Rules, which decide where events go but carry no ordering guarantee
EventBridge processes events at least once, so a target may see the same event twice, and while it attempts to deliver events in order it does not guarantee it. EventBridge Pipes provides ordered delivery within a pipe, but a pipe is a point-to-point path from one source to one target — not a partitioned log with independent consumers.
If the design depends on partitioned ordering, replay from an offset, or consumer groups, the AWS equivalents are Kinesis Data Streams (shards and shard iterators) or Amazon MSK, which is Kafka itself.