This chapter provides a comprehensive comparison of Amazon SQS, SNS, and EventBridge — three core messaging and eventing services on AWS. For the DVA-C02 exam, understanding when to use each service and how they differ is critical, as questions on this topic appear in roughly 8-12% of the exam. We will cover their internal mechanisms, key configurations, default values, and common exam traps so you can confidently choose the right service for any scenario.
Jump to a section
Imagine an office with three communication systems. SQS is like a mailroom with a stack of individual mail slots. A sender drops a letter into any slot, and the recipient comes by later to pick it up. The mailroom keeps the letter until it is retrieved and explicitly deleted. If the recipient is busy, the letter waits. If the recipient fails to process it, the letter goes back to the slot for retry. This is point-to-point, pull-based, and guarantees at-least-once delivery. SNS is like a company-wide pager system. A sender broadcasts a message to a topic (e.g., 'fire drill'), and the system instantly pages every employee subscribed to that topic. It does not wait for acknowledgment; it pushes the message to all subscribers (email, SMS, Lambda, etc.). This is pub/sub, push-based, and does not store messages. EventBridge is like an event coordinator who reads a company-wide calendar of events (e.g., 'new hire onboarded', 'server patch completed'). When an event is posted, the coordinator checks a rulebook to see which actions to trigger (e.g., send welcome email, update database). The coordinator can also filter events, transform them, and route to multiple targets. This is a centralized event bus with schema registry and advanced routing, suitable for decoupling microservices with complex event-driven architectures.
What They Are and Why They Exist
Amazon Simple Queue Service (SQS) is a fully managed message queue service for decoupling application components. It enables asynchronous communication between producers and consumers by storing messages in a queue until they are processed. SQS is pull-based: consumers poll the queue to retrieve messages. It supports at-least-once delivery and exactly-once processing via FIFO queues.
Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service. It allows publishers to send messages to a topic, which then pushes those messages to all subscribed endpoints (e.g., Lambda, SQS, HTTP, email, SMS). SNS is push-based and provides fan-out delivery.
Amazon EventBridge (formerly CloudWatch Events) is a serverless event bus that ingests events from AWS services, SaaS partners, and custom applications. It uses rules to match events and route them to targets (e.g., Lambda, SQS, SNS, Step Functions). EventBridge provides schema discovery, event filtering, and transformation.
How They Work Internally
SQS: Messages are stored redundantly across multiple Availability Zones (AZs). When a producer sends a message via SendMessage, SQS assigns a unique message ID and stores it. The message remains in the queue until a consumer calls ReceiveMessage. Upon receiving, the message becomes invisible to other consumers for the duration of the visibility timeout (default 30 seconds). The consumer must delete the message via DeleteMessage within that timeout; otherwise, the message becomes visible again for reprocessing. SQS supports two queue types: Standard (high throughput, best-effort ordering, at-least-once delivery) and FIFO (first-in-first-out, exactly-once processing, limited to 300 transactions per second without batching).
SNS: When a publisher calls Publish on a topic, SNS immediately pushes the message to all subscribers. Subscribers can be Lambda functions, SQS queues, HTTP/HTTPS endpoints, email, SMS, or platform application endpoints (mobile push). SNS uses a push delivery model; it does not poll. For HTTP subscribers, SNS sends a POST request with the message body. If the endpoint is unavailable, SNS retries according to a retry policy (default: 3 retries with exponential backoff). SNS does not store messages; if delivery fails after retries, the message is lost (unless configured with a dead-letter queue).
EventBridge: EventBridge ingests events from various sources. An event is a JSON object with fields like source, detail-type, detail, and resources. When an event arrives, EventBridge evaluates it against all rules. Each rule has an event pattern that matches events based on these fields. If a match occurs, EventBridge routes the event to the rule's targets. EventBridge can also transform the event before delivery using input transformers. It supports event replay (replaying archived events) and schema registry (discovering and downloading schemas). EventBridge is region-specific but can be used cross-account via event buses.
Key Components, Values, Defaults, and Timers
SQS:
Queue types: Standard (unlimited throughput) and FIFO (300 TPS without batching, 3,000 TPS with batching).
Message retention period: 1 minute to 14 days (default 4 days).
Visibility timeout: 0 seconds to 12 hours (default 30 seconds).
Maximum message size: 256 KB (can use S3 for larger payloads via extended client library).
Dead-letter queue (DLQ) redrive: set maxReceiveCount (default 0, meaning no DLQ).
Delay queue: delay seconds from 0 to 900 (15 minutes) — for Standard queues only.
Long polling: ReceiveMessageWaitTimeSeconds from 1 to 20 seconds (default 0, short polling).
Encryption: SSE-SQS (AWS managed) or SSE-KMS (customer managed CMK).
SNS:
Topic types: Standard and FIFO (for SQS FIFO subscribers).
Message size: up to 256 KB (for Amazon SQS, Lambda, HTTP, email-JSON); SMS messages are limited to 140 bytes.
Delivery retry policy: HTTP endpoints — 3 retries with exponential backoff (can be customized via delivery policy).
Dead-letter queue: can be configured for failed deliveries.
Message filtering: subscribers can set filter policies based on message attributes to receive only relevant messages.
Raw message delivery: for SQS subscribers, SNS can deliver the raw message body without SNS envelope (reduces size).
EventBridge:
Event size: up to 256 KB.
Event bus: default bus (receives AWS service events), custom bus (for custom applications), partner bus (from SaaS partners).
Rules: up to 100 rules per event bus.
Targets: up to 5 targets per rule.
Event pattern: JSON-based pattern matching on source, detail-type, detail, resources.
Input transformer: can transform event payload before sending to target.
Archive and replay: up to 90 days of event retention (configurable).
Schema registry: discover schemas for events on the bus; can generate code bindings.
Configuration and Verification Commands
SQS:
# Create a Standard queue
aws sqs create-queue --queue-name MyQueue --region us-east-1
# Create a FIFO queue
aws sqs create-queue --queue-name MyQueue.fifo --attributes FifoQueue=true,ContentBasedDeduplication=true
# Send a message
aws sqs send-message --queue-url <url> --message-body "Hello"
# Receive messages (long poll)
aws sqs receive-message --queue-url <url> --wait-time-seconds 20
# Delete a message
aws sqs delete-message --queue-url <url> --receipt-handle <handle>SNS:
# Create a topic
aws sns create-topic --name MyTopic
# Subscribe an SQS queue to topic
aws sns subscribe --topic-arn <topic-arn> --protocol sqs --notification-endpoint <queue-arn>
# Publish a message
aws sns publish --topic-arn <topic-arn> --message "Hello"
# Set a subscription filter policy
aws sns set-subscription-attributes --subscription-arn <sub-arn> --attribute-name FilterPolicy --attribute-value '{"event": ["order_placed"]}'EventBridge:
# Create a rule
aws events put-rule --name MyRule --event-pattern '{"source":["aws.s3"],"detail-type":["Object Created"]}'
# Add a target (e.g., Lambda)
aws events put-targets --rule MyRule --targets 'Id=1,Arn=<lambda-arn>'
# Send a custom event
aws events put-events --entries '{"Source":"my.app","DetailType":"UserSignUp","Detail":"{\"user\":\"john\"}"}'
# List rules
aws events list-rulesHow They Interact with Related Technologies
SQS, SNS, and EventBridge often work together. A common pattern is: SNS topic fans out messages to multiple SQS queues, each serving a different consumer group. EventBridge can also send events to SQS or SNS as targets. SQS can trigger Lambda via event source mapping (polling). SNS can invoke Lambda directly (push). EventBridge can invoke Lambda, Step Functions, and more.
For exam purposes, remember:
Use SQS when you need a buffer between producer and consumer, or when you need to decouple components with asynchronous processing.
Use SNS when you need to broadcast messages to multiple subscribers (fan-out).
Use EventBridge when you need to integrate AWS services with custom events, apply complex filtering, or use schema registry.
SQS + SNS combination: SNS topic with SQS subscription provides fan-out with durable storage.
EventBridge can replace SNS in some scenarios (e.g., custom event bus) but SNS is simpler for push notifications to humans.
SQS Message Lifecycle
1. Producer calls SendMessage API. SQS stores the message redundantly across multiple AZs and returns a message ID. The message is in 'available' state. 2. Consumer calls ReceiveMessage. SQS marks the message as 'in flight' and starts the visibility timeout (default 30 seconds). It returns the message body and a receipt handle. 3. Consumer processes the message. If successful, it calls DeleteMessage with the receipt handle. SQS deletes the message. 4. If consumer does not delete within visibility timeout, the message becomes visible again (re-enters 'available' state) for other consumers. 5. If the message is received more times than maxReceiveCount (if DLQ configured), it is moved to the dead-letter queue. This ensures at-least-once delivery and allows handling of poison pills.
SNS Fan-Out Pattern
1. Publisher creates an SNS topic and configures attributes (e.g., display name for SMS). 2. Subscribers subscribe to the topic using protocols (SQS, Lambda, HTTP, email, SMS). For SQS, the subscription requires the queue ARN and the queue policy must allow SNS to send messages. 3. When a publisher calls Publish, SNS immediately pushes the message to all subscribers in parallel. For SQS, SNS sends a message to the queue. For Lambda, SNS invokes the function asynchronously. 4. If delivery fails (e.g., HTTP 4xx/5xx), SNS retries based on the delivery policy. After exhausting retries, the message is discarded unless a DLQ is configured. 5. Subscribers can set filter policies to receive only messages with matching attributes, reducing noise.
EventBridge Event Processing
1. An event source (AWS service, custom app, SaaS) emits an event to an event bus. For AWS services, events go to the default bus automatically. Custom apps use PutEvents API. 2. EventBridge evaluates the event against all rules on that bus. Each rule has an event pattern (JSON match) and optional input transformer. 3. If a rule matches, EventBridge sends the event to all targets of that rule. Targets can be Lambda, SQS, SNS, Step Functions, Kinesis, etc. 4. If a target is unavailable, EventBridge retries for up to 24 hours (configurable) and can send failed events to a DLQ. 5. EventBridge can archive events to an archive for replay within a retention period (up to 90 days). This allows reprocessing of past events.
Choosing Between Services
1. Identify the communication pattern: point-to-point (queue) vs pub/sub (topic) vs event bus (EventBridge). 2. If you need a buffer for decoupling and asynchronous processing, use SQS. If you need to broadcast to multiple consumers, use SNS. If you need to integrate with multiple AWS services and custom apps with filtering and transformation, use EventBridge. 3. Consider durability: SQS stores messages up to 14 days; SNS does not store messages; EventBridge can archive events. 4. Consider ordering: SQS FIFO provides strict ordering; SNS FIFO topic with SQS FIFO subscriber maintains order; EventBridge does not guarantee order. 5. Consider throughput: SQS Standard has unlimited TPS; FIFO up to 300 TPS (3,000 with batching); SNS Standard has high throughput; EventBridge has soft limits (default 10,000 events/second per account per region).
Exam Scenario: Decouple with DLQ
1. A microservice sends order data to an SQS queue for processing. 2. A Lambda function polls the queue. If processing fails, the function does not delete the message; it becomes visible again after visibility timeout. 3. To avoid infinite retries, configure a dead-letter queue on the source queue with maxReceiveCount = 3. After 3 failed attempts, the message moves to the DLQ. 4. Set a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric to alert on failures. 5. For exam, remember that DLQ is a standard SQS queue, and the source queue can be either standard or FIFO. The DLQ must be of the same type (standard DLQ for standard source, FIFO DLQ for FIFO source).
Scenario 1: E-commerce Order Processing Pipeline
An e-commerce platform processes millions of orders daily. The frontend service sends order details to an SQS queue. A fleet of EC2 instances (or Lambda functions) polls the queue and processes orders (payment, inventory, shipping). This decouples the frontend from backend processing, allowing the frontend to respond quickly even during traffic spikes. The queue acts as a buffer. If a processing instance fails, the message remains in the queue for another instance to pick up. For critical orders, a dead-letter queue catches messages that fail repeatedly, triggering an alert. The team uses long polling (20 seconds) to reduce empty responses and costs. They set visibility timeout to 5 minutes to allow processing time. If a message is not deleted within 5 minutes, it becomes visible again. This pattern handles 10,000 messages per second using Standard queue.
Scenario 2: Multi-Service Notification System
A SaaS company needs to send notifications to customers via email, SMS, and mobile push. They use an SNS topic. When a new notification is generated (e.g., invoice ready), a microservice publishes to the topic. Subscribers include an email endpoint (via SES), an SMS subscription, and a Lambda function that sends push notifications via Amazon Pinpoint. The team uses filter policies: for example, SMS subscriptions only receive urgent notifications (attribute 'priority' = high). This reduces SMS costs. They also subscribe an SQS queue to the topic for audit logging. If email delivery fails, SNS retries 3 times then discards the message (no DLQ configured for simplicity). The system handles 500 publishes per second.
Scenario 3: Event-Driven Microservices with EventBridge
A financial services company uses EventBridge to orchestrate microservices. When a user creates an account (event: 'UserCreated' from custom app), EventBridge routes to a Lambda function that sends a welcome email, updates a DynamoDB table, and publishes a 'AccountSetup' event. Another rule matches 'AccountSetup' and triggers a Step Functions workflow for compliance checks. The team uses schema registry to generate TypeScript types for events, ensuring type safety. They archive events for 30 days for replay during debugging. EventBridge replaces a complex SNS+SQS fan-out pattern, providing better filtering and transformation. The system handles 2,000 events per second. Common misconfiguration: forgetting that EventBridge events are limited to 256 KB, so large payloads must be stored in S3 with the event containing the S3 reference.
Exactly What DVA-C02 Tests
The exam objective '1.5 Develop code to decouple application components' explicitly tests your ability to choose between SQS, SNS, and EventBridge. Expect scenario-based questions where you must select the correct service based on requirements like: ordering, durability, throughput, fan-out, filtering, and integration with other AWS services.
Common Wrong Answers and Why
Choosing SNS when SQS is needed: Candidates see 'asynchronous' and pick SNS, forgetting that SNS is push-based and does not store messages. If the requirement is to buffer messages and process at a later time, SQS is correct. SNS without SQS subscription loses messages if consumer is down.
Choosing SQS when fan-out is needed: Candidates pick SQS because it stores messages, but SQS is a queue, not a topic. For broadcasting to multiple consumers, SNS or EventBridge is needed. SQS alone cannot push to multiple endpoints.
Choosing EventBridge when simple pub/sub is needed: EventBridge is more complex than SNS. If the requirement is just to send notifications to email/SMS, SNS is simpler. EventBridge is for event-driven architectures with complex routing.
Confusing FIFO and Standard capabilities: Candidates think FIFO queues have unlimited throughput. In reality, FIFO queues are limited to 300 TPS (3,000 with batching). Standard queues have unlimited throughput but no ordering guarantee.
Specific Numbers and Terms That Appear on the Exam
SQS default visibility timeout: 30 seconds.
SQS maximum message retention: 14 days.
SQS maximum message size: 256 KB.
SQS FIFO throughput: 300 messages per second (without batching), 3,000 with batching.
SNS message size: 256 KB (except SMS: 140 bytes).
EventBridge event size: 256 KB.
EventBridge default events per second: 10,000 (soft limit).
DLQ: must be same type (Standard or FIFO) as source queue.
Long polling: set ReceiveMessageWaitTimeSeconds to 1-20 seconds.
Edge Cases and Exceptions
SQS FIFO with SNS FIFO: To maintain ordering across multiple consumers, you must use an SNS FIFO topic with an SQS FIFO subscriber. The combination ensures exactly-once delivery and order.
EventBridge doesn't guarantee order: Events from the same source may be processed out of order. If ordering is critical, use Kinesis or SQS FIFO.
SNS delivery policy: For HTTP endpoints, you can customize retry policy (max retries, backoff function). Default is 3 retries.
EventBridge input transformer: Can extract parts of the event and create a new JSON for the target. Useful for reducing payload size.
How to Eliminate Wrong Answers
If the scenario mentions 'decouple' and 'asynchronous processing', lean toward SQS.
If it mentions 'broadcast' or 'notify multiple subscribers', lean toward SNS or EventBridge.
If it mentions 'event-driven architecture', 'filtering', 'transformation', or 'integration with multiple AWS services', lean toward EventBridge.
If the scenario requires ordering and exactly-once processing, look for FIFO queues.
If the scenario requires high throughput without ordering, Standard SQS is correct.
SQS is pull-based, stores messages, and is used for decoupling with buffering.
SNS is push-based, does not store messages, and is used for fan-out notifications.
EventBridge is a serverless event bus with filtering, transformation, and archiving.
SQS FIFO queues provide exactly-once processing and ordering, limited to 300 TPS (3,000 with batching).
SNS can subscribe SQS queues for durable fan-out.
EventBridge can replace SNS in complex event-driven architectures.
Always configure a dead-letter queue for critical SQS and SNS workflows.
Long polling reduces empty responses and costs for SQS.
EventBridge events are limited to 256 KB; use S3 for larger payloads.
For ordering across multiple consumers, use SNS FIFO topic with SQS FIFO subscriber.
These come up on the exam all the time. Here's how to tell them apart.
SQS
Pull-based: consumers poll for messages.
Stores messages up to 14 days.
Point-to-point: one queue per consumer group.
Supports Standard (unlimited throughput) and FIFO (ordered).
Use for decoupling with buffering.
SNS
Push-based: SNS pushes messages to subscribers.
Does not store messages (no persistence).
Pub/sub: one topic can have many subscribers.
Supports Standard and FIFO topics (FIFO requires FIFO subscriber).
Use for fan-out notifications.
SNS
Simpler pub/sub model.
No built-in filtering (requires subscriber-side filter policy).
No event archiving or replay.
No schema registry.
Best for human notifications (email, SMS).
EventBridge
Event bus with advanced routing.
Built-in event pattern filtering.
Supports archiving and replay of events.
Schema registry for discovery and code generation.
Best for event-driven microservices integration.
Mistake
SNS stores messages until they are delivered.
Correct
SNS does not store messages. It pushes messages to subscribers immediately. If delivery fails after retries, the message is lost unless a dead-letter queue is configured. For durable storage, subscribe an SQS queue to the SNS topic.
Mistake
SQS guarantees exactly-once delivery by default.
Correct
Standard SQS provides at-least-once delivery, meaning a message may be delivered more than once. Exactly-once processing is only available with FIFO queues, which use message deduplication IDs.
Mistake
EventBridge is just a replacement for SNS.
Correct
EventBridge is more than pub/sub. It provides schema registry, event archiving/replay, advanced filtering, and integration with AWS services. SNS is simpler for push notifications to humans. Choose based on complexity needs.
Mistake
You can use any SQS queue type as a dead-letter queue for any source queue.
Correct
The DLQ must be of the same type as the source queue: Standard DLQ for Standard source, FIFO DLQ for FIFO source. Mixing types is not allowed.
Mistake
SQS FIFO queues have the same throughput as Standard queues.
Correct
FIFO queues are limited to 300 transactions per second (without batching) or 3,000 with batching. Standard queues have virtually unlimited throughput. FIFO is for scenarios requiring strict ordering.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Use SQS when you need a durable queue for decoupling producers and consumers, especially if you need buffering and at-least-once delivery. Use SNS when you need to broadcast messages to multiple subscribers (fan-out) and don't need persistence. Use EventBridge when you need to integrate multiple AWS services with custom events, apply complex filtering, transform events, or use schema registry. The exam often tests this distinction.
Yes. A common pattern is to subscribe an SQS queue to an SNS topic. This gives you both fan-out (SNS) and durable storage (SQS). The SNS topic pushes messages to the SQS queue, and consumers poll the queue. This ensures messages are not lost even if consumers are temporarily unavailable.
EventBridge is the evolution of CloudWatch Events. It adds schema registry, event archiving/replay, and support for custom and partner event buses. CloudWatch Events only had default event bus for AWS services. For the exam, assume EventBridge is the modern service; CloudWatch Events is legacy.
Use an SQS FIFO queue. FIFO queues guarantee first-in-first-out delivery and exactly-once processing. Note that FIFO queues are limited to 300 TPS (3,000 with batching). If you need ordering across multiple consumers, use an SNS FIFO topic with an SQS FIFO subscriber.
A DLQ is a separate SQS queue that receives messages that failed to be processed after a specified number of attempts (maxReceiveCount). Use a DLQ to isolate problematic messages (poison pills) so they don't block the main queue. Configure CloudWatch alarms on the DLQ to alert on failures.
EventBridge invokes Lambda asynchronously by default. If you need synchronous invocation, use a different trigger (e.g., API Gateway). For exam, remember that EventBridge uses async invocation for Lambda targets.
Long polling reduces empty responses by allowing the consumer to wait for messages to arrive. Set ReceiveMessageWaitTimeSeconds to a value between 1 and 20 seconds. This decreases the number of API calls and reduces cost. Short polling (default 0 seconds) returns immediately even if no messages.
You've just covered SQS vs SNS vs EventBridge Comparison — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?