Cargando...
Cargando...
Stop guessing which service to use — master the decision framework that separates passing from failing on 6 AWS certifications
Same family, radically different jobs — know the difference or fail the exam
| Feature | EventBridge Event router with rules and filtering | SNS Fan-out pub/sub to many subscribers | SQS Durable queue for decoupled processing |
|---|---|---|---|
Primary Pattern The pattern is the most-tested differentiator. EventBridge routes based on content; SNS broadcasts to all; SQS holds messages for one consumer group. | Event-driven routing (many sources → many targets via rules) | Pub/Sub fan-out (one topic → many subscribers simultaneously) | Point-to-point queue (producer → single consumer group) |
Message / Event Filtering EventBridge has the most powerful filtering. SNS filter policies are per-subscription. SQS has no filtering — critical exam trap. | Rich content-based filtering via event patterns (up to 2,048 characters per pattern). Supports prefix, suffix, numeric ranges, IP matching, exists/not-exists conditions. | Subscription filter policies on message attributes or message body. Filters per subscription, not per topic. | No native filtering. Consumer must process and discard unwanted messages. |
Message Retention / Durability SQS is the ONLY service of the three with durable message storage. If the question mentions 'retry later', 'buffer', or 'store until processed' — the answer is SQS. | No message store by default on event buses. Events are delivered or retried; not persisted for later consumption. EventBridge Archive can replay events. | No message persistence. If a subscriber is unavailable, the message is lost (unless an SQS queue is a subscriber). | Messages retained for 1 minute (minimum) to 14 days (maximum, default 4 days). Stored durably across multiple servers. |
Delivery Guarantee Exactly-once processing requires SQS FIFO or SNS FIFO. Standard queues/buses are at-least-once — your consumer must be idempotent. | At-least-once delivery for event buses. Retries with exponential backoff for targets. Dead-letter queues supported. | At-least-once delivery for standard topics. FIFO topics provide exactly-once delivery within a message group. | Standard queues: at-least-once delivery. FIFO queues: exactly-once processing with deduplication. |
Ordering Guarantee If the scenario requires strict ordering, you must use SQS FIFO or SNS FIFO. EventBridge cannot guarantee order. | No strict ordering guarantee on event buses. | Standard topics: no ordering. FIFO topics: strict ordering within a message group. | Standard queues: best-effort ordering. FIFO queues: strict FIFO ordering within a message group. |
Event / Message Sources Only EventBridge natively integrates with third-party SaaS partners and has a built-in scheduler. If the question mentions Zendesk, Shopify, or cron scheduling — think EventBridge. | AWS services (200+), custom applications, SaaS partners (Zendesk, Datadog, Stripe, etc.), scheduled events (cron/rate), EventBridge Pipes (DynamoDB Streams, Kinesis, SQS, etc.) | AWS services, custom applications via SDK/CLI/API, SNS is often a downstream target of other services. | Any application via SDK/CLI/API. Also receives from SNS fan-out, EventBridge, Lambda, etc. |
Targets / Subscribers SNS supports direct human notification (SMS, email, mobile push) — EventBridge and SQS do not. If the scenario involves notifying a person, SNS is involved. | 29+ native targets including Lambda, SQS, SNS, Step Functions, API Gateway, Kinesis, ECS tasks, API destinations (any HTTP endpoint), EventBridge Buses in other accounts/regions. | Lambda, SQS, HTTP/HTTPS endpoints, email, SMS, mobile push, Amazon Data Firehose, third-party service providers (Datadog, Splunk, MongoDB). | Single consumer group. Consumers poll the queue (Lambda event source mapping, EC2, ECS, etc.). |
Fan-out Capability Classic exam pattern: SNS fan-out to multiple SQS queues. Each queue gets its own copy of the message for independent processing. SQS alone cannot fan-out. | Yes — one event bus rule can invoke multiple targets simultaneously. Multiple rules can match one event. | Yes — core capability. One message published to a topic is delivered to ALL subscribers simultaneously. | No — one message is consumed by one consumer (within the consumer group). Use SNS→SQS fan-out pattern for fan-out with queuing. |
Throughput For massive throughput fan-out, SNS Standard is the winner. SQS FIFO and SNS FIFO have the same base throughput limits — a common exam comparison. | Default: invocations throttled per Region (adjustable). Designed for event-driven workloads, not high-throughput streaming. | Standard topics: virtually unlimited throughput. FIFO topics: 300 messages/sec (3,000/sec with batching) per topic. | Standard queues: nearly unlimited throughput. FIFO queues: 300 messages/sec (3,000/sec with batching) without high-throughput mode; high-throughput mode increases this significantly. |
Message Size Limit All three share the 256 KB limit. SQS uniquely supports the Extended Client Library with S3 for payloads up to 2 GB. This is a common exam trap — only SQS has this workaround. | Maximum event size: 256 KB | Maximum message size: 256 KB | Maximum message size: 256 KB. For larger payloads, use the Extended Client Library to store in S3 (up to 2 GB). |
Decoupling / Buffering SQS is the go-to for load leveling and buffering. Classic exam scenario: 'spiky traffic, downstream can only handle X requests/sec' → SQS queue as buffer. | Loose coupling via event routing but no buffering. Producer does not know about consumers. | Decouples publisher from subscriber but no buffering. If subscriber is down, message is lost (unless SQS is subscriber). | Full decoupling AND buffering. Producer and consumer operate at different speeds. Messages persist until consumed. |
Visibility Timeout / In-flight Processing Visibility timeout is SQS-only. It prevents duplicate processing. If a consumer crashes, the message reappears after the timeout expires. This is a frequently tested SQS concept. | Not applicable. Events are pushed to targets; no visibility timeout concept. | Not applicable. Messages are pushed to subscribers immediately. | Visibility timeout: 0 seconds to 12 hours (default 30 seconds). Message is hidden from other consumers while being processed. |
Dead-Letter Queue (DLQ) All three support DLQs, and in all cases the DLQ itself is an SQS queue. The DLQ for EventBridge and SNS is always SQS — never another EventBridge bus or SNS topic. | Yes — configure a DLQ (SQS queue) for failed event deliveries on event buses and Pipes. | Yes — configure a DLQ (SQS queue) for failed deliveries per subscription. | Yes — configure a DLQ (another SQS queue) for messages that exceed the maxReceiveCount. |
Event Replay / Reprocessing EventBridge Archive and Replay is unique to EventBridge. If the scenario mentions 'replay past events' or 'reprocess historical events' — EventBridge is the answer. | Yes — EventBridge Archive and Replay. Archive events for replay at any time. Retention period is configurable. | No native replay capability. | No replay. Once a message is deleted from the queue, it is gone. Use DLQ + redrive for retry. |
Cross-Account / Cross-Region EventBridge is the best choice for multi-account event routing in AWS Organizations. It has native support for event bus policies and global endpoints. | Yes — event buses support cross-account and cross-region event routing natively. Global endpoints for multi-region event buses. | Cross-region delivery to SQS is supported. Cross-account publishing requires topic policy. | Cross-account access via queue policy. No native cross-region delivery. |
Schema Registry Schema Registry is an EventBridge-exclusive feature. Enables auto-discovery of event schemas and generates code bindings — relevant for DevOps and Developer exams. | Yes — EventBridge Schema Registry automatically discovers and catalogs event schemas. Supports code binding generation. | No schema registry. | No schema registry. |
Pricing Model AWS service events to EventBridge default bus are FREE — only custom/partner events cost money. This is a common CLF-C02 and SAA-C03 trap. | Event buses: $1.00 per million events published (custom/partner events; AWS service events are free). Pipes: charged per event processed. Schema Registry: first 5 million schema discovery events/month free. | First 1 million SNS API requests/month free. $0.50 per million requests after. Data transfer charges apply. SMS and email have separate pricing. | First 1 million SQS requests/month free. $0.40 per million requests (Standard). $0.50 per million requests (FIFO). Data transfer charges apply. |
Polling vs Push SQS requires consumers to poll — this is a fundamental architectural difference. Long polling (up to 20 seconds) reduces empty responses and costs. Short polling is the default. | Push-based. EventBridge pushes events to targets when rules match. | Push-based. SNS pushes messages to all subscribers immediately upon publish. | Pull-based. Consumers poll the queue (short polling or long polling). Lambda uses event source mapping (managed polling). |
Use with Lambda SQS + Lambda ESM is the most controllable pattern — you can throttle Lambda invocations via batch size and concurrency. SNS→Lambda has no throttle control. Key for DVA-C02 and DOP-C02. | Lambda is a supported target. EventBridge rule invokes Lambda synchronously. Scales Lambda concurrency per event. | Lambda is a supported subscriber. SNS invokes Lambda synchronously. Lambda scales per message. | Lambda uses event source mapping (ESM) to poll SQS. Supports batch sizes and concurrency controls. FIFO queues process one batch per message group. |
FIFO Support EventBridge does NOT have a FIFO mode. For ordered event processing, you must use SQS FIFO or SNS FIFO. SNS FIFO can only deliver to SQS FIFO queues (not Lambda directly as a subscriber for FIFO). | No FIFO event buses. EventBridge Pipes can source from SQS FIFO queues. | Yes — SNS FIFO topics. Strict ordering, exactly-once delivery, deduplication. | Yes — SQS FIFO queues. Strict ordering, exactly-once processing, deduplication ID and content-based deduplication. |
Number of Targets/Subscribers SNS supports millions of subscribers per topic. EventBridge has a 5-target-per-rule limit but multiple rules can fire. If massive fan-out to millions of endpoints is needed, SNS wins. | Up to 5 targets per rule (default, adjustable). Multiple rules can match the same event, effectively increasing targets. | Up to 12,500,000 subscriptions per topic (standard). Up to 100 subscriptions per FIFO topic. | Not applicable — SQS has consumers, not subscribers. Multiple consumers compete for messages. |
Event Buses (EventBridge-specific) Only EventBridge has the concept of event buses. The default bus receives all AWS service events automatically — you only pay for custom/partner events. | Maximum 100 event buses per account per Region (adjustable). Default bus (AWS services), custom buses, partner buses. | N/A | N/A |
API Destinations EventBridge API Destinations is the go-to for webhook integrations with external SaaS systems. Up to 3,000 destinations per account per Region. | Yes — up to 3,000 API destinations per account per Region (adjustable). Calls any HTTP/HTTPS endpoint with OAuth, API key, or basic auth. | HTTP/HTTPS subscriber endpoints supported but limited auth options. | N/A — SQS does not push to HTTP endpoints. |
Connections (EventBridge) Connections store auth credentials for API Destinations. The 3,000 limit matches the API Destinations limit — both are adjustable. | Maximum 3,000 connections per account per Region (adjustable). Used with API Destinations for auth configuration. | N/A | N/A |
Event Pattern Size The 2,048 character event pattern limit in EventBridge is adjustable via Service Quotas. Don't confuse with the 256 KB event size limit. | Maximum event pattern size: 2,048 characters (adjustable) | Filter policy size limits apply per subscription (separate quota) | N/A — no native filtering |
Summary
Use SQS when you need durable buffering, load leveling, or exactly-once processing with strict ordering (FIFO). Use SNS when you need to fan-out a single message to multiple subscribers simultaneously, especially when human notification (SMS/email/push) is involved. Use EventBridge when you need content-based routing, multi-source event aggregation, SaaS integrations, scheduled events, event replay, or cross-account/cross-region event routing in complex architectures.
🎯 Decision Tree
Need to buffer/store messages until processed? → SQS. Need to fan-out to millions of subscribers at once? → SNS. Need human notifications (SMS/email/push)? → SNS. Need to route events based on content/rules from AWS services or SaaS? → EventBridge. Need strict ordering + exactly-once? → SQS FIFO or SNS FIFO. Need to replay past events? → EventBridge Archive. Need to call an external HTTP webhook? → EventBridge API Destinations. Need to decouple microservices with retry/backoff? → SQS. Need to trigger multiple independent pipelines from one event? → SNS fan-out to multiple SQS queues. Need scheduled jobs (cron)? → EventBridge Scheduler.
SNS fan-out to SQS is the canonical decoupling pattern: publish once to SNS, deliver to multiple SQS queues simultaneously. Each queue gets its own independent copy for parallel processing. This pattern appears on SAA-C03, DVA-C02, and SAP-C02 — if a question mentions 'multiple independent consumers' and 'no message loss', this is almost always the answer.
SQS is the ONLY service of the three that stores/buffers messages. EventBridge and SNS are push-based and do NOT persist messages (except EventBridge Archive for replay). Any scenario involving 'spiky traffic', 'rate limiting a downstream service', 'process later', or 'retry failed processing' points to SQS. Confusing SNS's 'at-least-once' with durability is the #1 exam trap.
EventBridge is the right answer when: (1) the source is a third-party SaaS (Zendesk, Datadog, Stripe), (2) you need content-based routing with complex filter rules, (3) you need cross-account/cross-region event routing, (4) you need to replay historical events (Archive), (5) you need a cron/rate schedule, or (6) you need to call an external HTTP webhook (API Destinations). None of these are possible with SNS or SQS alone.
AWS service events (EC2 state changes, S3 events, CodePipeline state changes, etc.) are delivered to the EventBridge default event bus for FREE. You only pay for custom application events and partner events. This is commonly tested on CLF-C02 and SAA-C03 pricing questions. Do not assume all EventBridge usage costs money.
SQS + Lambda Event Source Mapping (ESM) gives you throttle control over Lambda invocations — set batch size and reserved concurrency to prevent Lambda from overwhelming a downstream database. SNS → Lambda has NO throttle control; SNS will invoke Lambda for every message immediately. This distinction is critical for DVA-C02 and DOP-C02 architecture questions.
Only SQS supports the Extended Client Library for messages larger than 256 KB (up to 2 GB via S3). EventBridge and SNS have the same 256 KB hard limit with no workaround. If a scenario mentions large payloads (images, documents, large JSON), the answer involves SQS + S3.
EventBridge Pipes enables point-to-point integrations with enrichment and transformation — it can source from DynamoDB Streams, Kinesis, SQS, and others, enrich via Lambda/Step Functions, and deliver to a single target. A common pattern is Pipes → EventBridge Bus → multiple targets. Don't confuse Pipes (1:1) with event buses (many:many).
SNS FIFO topics can ONLY deliver to SQS FIFO queues as subscribers — you cannot subscribe Lambda directly to an SNS FIFO topic. This is a specific limitation that appears in DVA-C02 and SAP-C02 questions about ordered processing pipelines.
The #1 exam trap: Candidates assume SNS provides message durability because it has 'at-least-once delivery'. It does NOT. SNS is push-only with no message store — if a subscriber is unavailable, the message is LOST. The correct pattern for durable fan-out is SNS → SQS (the SNS fan-out pattern), where SQS provides the durability. A second major trap: candidates choose EventBridge for simple pub/sub fan-out, not realizing SNS is simpler and cheaper for that use case. EventBridge adds cost and complexity that is only justified when you need content-based routing, SaaS integration, or event replay.
CertAI Tutor · DEA-C01, DOP-C02, CLF-C02, SAA-C03, SAP-C02, DVA-C02 · 2026-02-22
Services
Comparisons
Guides & Patterns