EventBridge vs. SQS: Event Buses, Queues, and When to Use Both
Published on · Updated on
Rewrote the comparison for current Custom and Classic EventBridge buses, SQS delivery semantics, retry boundaries, quotas, and pricing.
Choose Amazon EventBridge when events need to reach independently configured consumers based on their content. Choose Amazon SQS when workers need a durable queue of work they can receive, process, and delete at their own pace. Use both when you need routing across services and an explicit work queue for each consumer.
The comparison changed in September 2026. The new EventBridge Custom event bus adds retained events, consumer-owned subscribers, and configurable ordered delivery. The default bus and Custom event bus – Classic remain available with rules and targets. Claims that EventBridge never retains events or cannot deliver them in order are no longer accurate without specifying the bus type.
EventBridge vs. SQS at a glance
| Question | EventBridge Custom bus | EventBridge default / Classic bus | Amazon SQS |
|---|---|---|---|
| Primary job | Route retained events to subscribers | Route arriving events through rules | Buffer messages for workers |
| Routing | Each subscriber filters and delivers to one target | Each rule matches an event pattern and invokes its targets | No built-in content router across queues |
| Delivery | Push to each subscriber's target | Push to rule targets | Consumers receive and delete messages |
| History | One day by default; configurable from 1 to 365 days | Optional archive with configured retention | Four days by default; configurable up to 14 days |
| Order | FIFO subscribers deliver in order within event groups | No ordering guarantee | FIFO queues order within message groups; Standard queues use best-effort ordering |
| Failure handling | Subscriber retries and an on-failure destination | Target retries and an optional SQS DLQ | Visibility timeout, repeated receives, and a redrive policy to a DLQ |
| Fan-out | Each has its own subscriber | Each has a matching rule/target path | Use a separate queue for each consumer that must receive a copy |
The key difference is what a consumer acknowledges. An EventBridge target accepts an invocation or delivery. An SQS worker removes a message after its work succeeds. Neither acknowledgment alone proves that every downstream business operation has completed.
Understand what each service actually provides
EventBridge: route events to independent consumers
On a default or Classic bus, rules evaluate event patterns as events arrive. An event can match several rules or none. Matching targets receive copies, optionally transformed before delivery. Treat consumers as independent: failure in one path does not coordinate or roll back another consumer's work.
Classic buses support optional archives and replay. Archive retention is configurable and defaults to indefinite storage. Archive replay is different from retrying one failed target delivery, and it does not guarantee original event order. Archive retention, the target retry window, and the delay in archive statistics are separate settings.
On the new Custom bus, each subscriber selects events, can transform them, and delivers to one target. The bus retains accepted events so subscribers can read from a past position or pause and resume within the retention window. Configure that window according to the recovery time you need and the storage cost you can accept. See the Custom bus retention settings.
New Custom buses can be shared through AWS RAM so consumer accounts create their own subscribers. Default and Classic buses use their existing resource-policy and forwarding model. Check the bus model and regional availability before applying a tutorial or infrastructure template written for the other version.
SQS: buffer work and let consumers control processing
An SQS queue holds messages until they are deleted or expire. A worker receives a message, processes it, and deletes it using its receipt handle. During processing, a visibility timeout temporarily hides the message from other receives. If the worker crashes or does not delete it in time, it becomes available again. See SQS visibility timeout behavior.
Standard queues provide at-least-once delivery and best-effort ordering. FIFO queues add ordering within each MessageGroupId and deduplicate sends within a five-minute window. Choose the group to match the business sequence, such as one account or order; different groups can run in parallel.
SQS message attributes are metadata, not a subscription filter. SQS does not inspect them to route messages to different queues. Put a router such as EventBridge or SNS upstream when different consumers need different subsets. Multiple workers polling one queue share its work; they are not independent subscribers that each receive every message.
Ordering, duplicates, and retries need precise boundaries
FIFO does not make database side effects happen exactly once
SQS FIFO send deduplication suppresses repeated sends with the same deduplication identity within its window. It cannot make a payment API call and a queue deletion one atomic transaction. If a worker charges a card and crashes before deleting the message, processing can repeat. Make the operation idempotent: use a durable operation identifier so a retry returns the earlier result rather than applying the side effect twice.
The new Custom bus also has publish-time deduplication and FIFO subscribers. Ordering applies within an event group belonging to the publishing account. A FIFO subscriber delivering asynchronously to Lambda preserves order up to Lambda's queue, not necessarily the function's completion order; use the documented request-response invocation mode for ordered processing. Preserve the required semantics at every hop, including any downstream SQS queue and the application itself.
Separate delivery failures from processing failures
Classic EventBridge retries retryable target failures for up to 24 hours and 185 retries by default. Configure a target DLQ to retain events that could not be delivered. New Custom subscribers default to five attempts within 300 seconds and use OnFailureConfiguration. Their failure queue stores records identifying the failed events, rather than the event payloads; recovery replays those events from the bus while they remain within its retention window. Check the Classic retry policy and the Custom subscriber retry policy rather than carrying over defaults.
After EventBridge successfully sends a message to SQS, processing belongs to the queue's consumers. Configure the SQS redrive policy's maxReceiveCount and a consumer DLQ separately. The SQS DLQ guide also warns that removing a failed message from a FIFO sequence can break the application's intended order. Decide how to repair that sequence before redriving messages.
An EventBridge delivery DLQ and an SQS consumer DLQ solve different failures. Monitor both, and test whether the failure destination itself has permission to receive messages.
Choose from the workload's needs
- Route one business event to several teams: use an EventBridge bus with separate subscriber or rule paths. Each consumer can select the events it needs.
- Run background jobs with competing workers: start with SQS. Workers control concurrency, can accumulate a backlog, and delete jobs after successful processing.
- Recover historical events or initialize a new consumer: compare new Custom bus retention with Classic archives. A queue whose messages have already been deleted is not a replayable event history.
- Process a sequence in order: consider SQS FIFO or a FIFO Custom bus subscriber, then verify grouping, target invocation mode, retries, and downstream processing. Classic bus routing provides no such ordering guarantee.
- Route events and absorb slow consumers: send from EventBridge to one SQS queue per independent consumer. A consumer can add several workers to its queue without changing the routing contract.
For example, OrderCreated can be routed independently to fulfillment and analytics queues. Fulfillment workers process and acknowledge jobs from their queue, while analytics processes its own copy at a different rate. No routing service makes those two outcomes a single transaction. Our enterprise integration patterns guide explains routing, work queues, orchestration, and consistency together.
Check payloads, capacity, cost, and access
Measure the complete path
Do not use a single events-per-second number as EventBridge's universal capacity. Classic publishing quotas count API requests, vary by Region, and are separate from target invocation quotas. SQS FIFO throughput depends on mode, Region, batching, and message-group distribution. Check the quotas for the actual bus version and Region you use, rather than applying Classic limits to the new Custom bus. The EventBridge quota reference and SQS message and throughput quotas are starting points for checking the complete path.
Validate payload size after transformation and against every target's limit. For large business records, a reference to controlled object storage may be more useful than copying the full record through every hop. Compare latency from publishing to successful business completion, including polling, batching, retries, and consumer saturation; a blanket claim that one service is always faster is not a reliable design input.
Estimate the workflow, not just the first hop
SQS charges for requests, with payload sizing and batching affecting the bill. Include sends, receives, deletes, empty polling, retries, KMS, data transfer, and consumer compute. Classic EventBridge pricing depends on the event category and delivery path, with additional archive and replay charges where used. The new Custom bus has separate data-volume pricing for publishing and subscriber deliveries, plus retention and optional operations. Fan-out increases total deliveries.
Use the current SQS pricing and EventBridge pricing with your payload sizes, consumer count, retention, and retry volume. Neither service is universally cheaper.
Make the boundaries observable
Restrict publishers, routing configuration, target delivery roles, queue consumers, and encryption keys separately. Monitor delivery failures and DLQs alongside queue age, backlog, and the consumer's actual outcomes. A publish success is not an end-to-end health signal. Our EventBridge security guide covers IAM, encryption, private connectivity, and auditing for each bus model.
Frequently asked questions
Can EventBridge replace SQS?
It can remove a separate queue when a subscriber's delivery and retained-event model meets the consumer's needs. Keep SQS when the application needs its receive/delete contract, competing workers, visibility controls, or existing queue integrations. Built-in bus retention does not make those interfaces interchangeable.
Where do EventBridge Pipes fit?
EventBridge Pipes connects one supported source, such as an SQS queue, to one target, with optional filtering, enrichment, and transformation. A pipe is a point-to-point integration, separate from bus fan-out. Filtering a pipe's input does not turn an SQS queue into a multi-subscriber router.
Choose the consumption model before the service name
Start by deciding who needs a copy, whether work must accumulate for competing workers, how long recovery must remain possible, and what must stay ordered. Then evaluate the relevant EventBridge bus type, SQS queue type, or their combination against those needs. Verify duplicate handling and failure recovery with the real consumers before relying on delivery guarantees.