EventBridge VS Kinesis(Event Stream)

EventBridge and Kinesis Data Streams both carry events between components, but they solve different problems. EventBridge is a router: it inspects each event, decides which rules match, pushes copies to their targets and forgets it. Kinesis Data Streams is a log: it appends records to shards in order, keeps them for a configured retention period, and lets any number of consumers read and re-read them at their own pace.

The full side-by-side comparison of both services, along with SQS and SNS, lives on the section index. This page covers the choice between these two.

flowchart LR subgraph "Amazon EventBridge - routing" src["Event sources<br/>AWS services, SaaS, apps"] --> bus["Event bus"] bus --> rules["Rules<br/>JSON pattern match"] rules --> t1["Target A"] rules --> t2["Target B"] end subgraph "Kinesis Data Streams - ordered log" prod["Producers"] --> stream["Stream"] stream --> s1["Shard 1"] stream --> s2["Shard 2"] s1 --> c1["Consumers<br/>read and re-read in order"] s2 --> c1 end

EventBridge, the event router

• A serverless bus for connecting AWS services, SaaS applications and custom code
• Best where the routing decision depends on the content of the event
• Rich pattern matching and per-target input transformation, with no code to maintain
• Priced per event published; nothing to size in advance
• Throughput is a per-account, per-Region quota on PutEvents: 10,000 per second in US East (N. Virginia), US West (Oregon) and Europe (Ireland), 1,200 in Europe (London), 400 in many other Regions, all adjustable through Service Quotas
• Maximum event size 256 KB; five targets per rule, which is a hard limit
• Push delivery, at least once, with no ordering guarantee
• No retention. Durability comes only from an archive, which can be replayed to the same bus, or from a dead-letter queue on a target

Kinesis Data Streams, the event stream

• Built for continuous, high-volume ingestion: logs, telemetry, clickstreams, IoT
• Records are ordered within a shard, and the partition key decides which shard a record lands on, so all records for one key stay in sequence
• Records are retained for 24 hours by default and up to 365 days, and any consumer can re-read them from any point in that window using a shard iterator — this, not enhanced fan-out, is what makes a stream replayable
• Capacity is either on-demand or provisioned in shards; each shard takes 1 MB/s and 1,000 records per second of writes and serves 2 MB/s of reads
• Up to 10 MiB per record
• Pull delivery through GetRecords, or push to a registered enhanced fan-out consumer that gets its own 2 MB/s per shard
• Stream processing and analytics is a separate service: Amazon Managed Service for Apache Flink. The older SQL-based Kinesis Data Analytics was discontinued — AWS stopped accepting new applications on 15 October 2025 and began deleting existing ones on 27 January 2026

Choosing

1. Routing between services on event content, and integration with AWS or SaaS event sources, points to EventBridge.
2. High-volume sequential processing, and ordering across a key, points to Kinesis.
3. Spiky or unpredictable traffic with no capacity planning points to EventBridge.
4. A need to replay history — after a bug, or to seed a new consumer — points to Kinesis.
5. Several consumers that must each see every record, at their own pace, points to Kinesis; several targets that must each be told about an event points to EventBridge.

The two are frequently used together: an EventBridge rule can put matched events onto a Kinesis stream, which is a common way to give a routed event stream a durable, replayable history.