Amazon SQS, Amazon SNS, and Amazon EventBridge are all used to move work between systems, but they solve different integration problems. SQS stores messages for consumers that pull and process work. SNS publishes messages to subscribed endpoints and is strong for fanout. EventBridge routes events by matching structured event data against rules and can connect many producers and consumers through buses, Pipes, and schedules. Good architecture starts by identifying the relationship between producer and consumer rather than by choosing the newest service.<\/p>\n
For AWS Certified Solutions Architect \u2013 Associate (SAA-C03)<\/a> workloads, the core decision is how much coupling, buffering, routing intelligence, ordering, and replay behavior the system needs. These services can also be combined. A topic can fan out to queues, an EventBridge bus can route to an SQS queue, and Pipes can move records from a source through optional enrichment to one target. The architecture becomes clearer when each component has one explicit responsibility.<\/p>\n Ask whether the consumer should receive every event, one share of a workload, or only events matching a rule. Also decide whether producers can tolerate consumers being offline. If work must wait safely until a consumer is ready, a queue is a natural boundary. If one publication should reach several independent subscribers, publish-subscribe fits better. If producers emit business events and consumers want different subsets based on event content, a rule-driven event bus can reduce producer knowledge of downstream systems.<\/p>\n Do not use service names as architecture labels. \u201cEvent-driven\u201d does not automatically mean EventBridge, and \u201casynchronous\u201d does not automatically mean SQS. The familiar comparison in SNS versus SQS<\/a> is useful because fanout and buffering are different concerns. A resilient design may use both: SNS distributes a publication, while each subscriber receives its own SQS queue so it can process at an independent rate.<\/p>\n A useful whiteboard exercise is to draw arrows from producers to consumers and label each arrow with whether work may be delayed, duplicated, reordered, or dropped. Those four properties often identify the right AWS primitive immediately. If consumers can be offline and catch up later, buffering matters. If every subscriber must receive a copy, fanout matters. If different consumers need different subsets, routing matters. Making these requirements explicit prevents one integration service from being stretched into responsibilities it was not designed to own.<\/p>\n SQS is valuable when the producer and consumer should run at different speeds. Producers send messages quickly, queues absorb bursts, and consumers scale according to queue depth and processing capacity. The visibility timeout prevents a received message from being immediately offered to another consumer while work is in progress. It should be longer than normal processing time or extended dynamically, but not so long that a failed consumer leaves work invisible for an excessive period.<\/p>\n Standard queues provide very high throughput with at-least-once delivery semantics and best-effort ordering, so consumers should be idempotent. FIFO queues add ordering and deduplication capabilities for use cases that genuinely need ordered message groups. Dead-letter queues isolate repeatedly failing messages, but they are not a substitute for diagnosis. Monitor age of oldest message, receive counts, DLQ growth, and consumer errors so backpressure is visible before it becomes a customer-facing delay.<\/p>\n Queue depth is an operational signal as well as a transport detail. A growing backlog can mean demand increased, consumers slowed, a downstream dependency is throttling, or messages are repeatedly failing. Autoscaling consumers directly from queue depth can help, but include per-message processing cost and downstream quotas. Scaling from ten workers to one thousand is not useful if every worker immediately exhausts the same database connection pool. Backpressure should protect the system end to end, not merely move the bottleneck downstream.<\/p>\n SNS topics allow publishers to send a message once and have the service deliver it to multiple subscriptions. That makes SNS a strong choice for fanout to SQS queues, Lambda functions, HTTP\/S endpoints, mobile push systems, or other supported destinations. Each subscriber can own its downstream processing behavior instead of forcing the publisher to call multiple services directly. This reduces producer coupling and allows new consumers to be added without changing the publishing application.<\/p>\n Subscription filter policies can reduce unnecessary deliveries by evaluating message attributes or JSON message-body properties. Filtering belongs in the subscription when different consumers need different subsets of the same publication stream. Keep the event contract stable and avoid hiding business logic in a maze of overlapping filters. When reliable processing matters, SNS-to-SQS fanout is often stronger than direct delivery to an ephemeral consumer because the queue gives each subscriber independent buffering, retries, and operational visibility.<\/p>\n SNS fanout becomes easier to operate when each durable subscriber owns its own queue and dead-letter policy. One slow analytics consumer should not delay a billing consumer, and one subscriber’s retry storm should not affect another subscriber’s processing rate. Filter policies can reduce irrelevant deliveries, but keep the original topic contract understandable so a new subscriber can reason about what the topic represents without reverse-engineering every existing subscription filter.<\/p>\n EventBridge event buses receive events from AWS services, custom applications, and supported software providers, then evaluate them against rules. A rule can match fields such as source, detail type, resource identifiers, or values inside the detail object and can send a matching event to multiple targets. This is different from a queue: the bus makes a routing decision and delivers the event onward rather than storing it as a shared work backlog for consumers to poll.<\/p>\n EventBridge is especially useful for organization-wide event integration because producers can publish domain events without knowing each target. Consumers subscribe through rules that express their interest. Pipes handle a different shape: one source to one target with optional filtering, transformation, and enrichment. Keeping buses for many-to-many routing and Pipes for point-to-point flows makes the integration model easier to understand and avoids using a general event bus for every simple stream-to-target connection.<\/p>\n EventBridge rules should be reviewed for ownership and overlap. Two rules can both match the same event and intentionally invoke different targets, but accidental overlap can create duplicate business effects. Include sample events and expected target lists in tests. For organization-wide buses, use naming conventions for sources and detail types so patterns remain stable. An event contract that says order.shipped is more durable than a consumer matching arbitrary text inside a log-like payload.<\/p>\n Distributed messaging systems must assume that delivery can be retried. A consumer that charges a card, provisions a resource, or updates an external system should not perform the irreversible action twice simply because a message or event was redelivered. Use stable event identifiers, conditional writes, deduplication records, or domain-specific idempotency keys so replaying the same logical request is safe. This is an application responsibility even when the AWS service provides delivery guarantees.<\/p>\n Configure dead-letter handling intentionally. SQS has DLQs for messages that exceed a receive threshold. EventBridge targets can use retry policies and DLQs when target delivery fails. SNS also supports delivery policies for certain endpoints and can pair with SQS for durable fanout. The DOP-C02<\/a> view is operational: failure paths, retries, alarms, and remediation are part of the system, not error cases to think about after the happy path is deployed.<\/p>\n Retry design should include poison messages. A consumer that deterministically fails on malformed input will not recover by receiving the same message again. After a bounded retry count, move the work to a DLQ with enough context to diagnose the cause. Operators need a controlled redrive process that can fix or discard the bad message safely. Automatic infinite retry can turn one invalid payload into a permanent source of cost and noise.<\/p>\n Many teams ask for global ordering when the real requirement is narrower. An order’s own state changes may need sequence, while events for unrelated orders can be processed independently. SQS FIFO message groups are useful when ordering is required within a key, but global serialization can reduce throughput and create unnecessary coupling. EventBridge and SNS architectures should similarly avoid assuming delivery order will define business truth unless the specific service and integration explicitly provide that guarantee.<\/p>\n Design consumers to tolerate delayed events, duplicates, and events that arrive after newer state is already visible. Include timestamps, versions, or sequence information where the domain needs them, and query authoritative state when an event only signals that something changed. This prevents the event transport from becoming the system of record. Asynchronous architecture works best when messages describe facts or commands clearly and consumers can validate whether the requested state transition is still appropriate.<\/p>\n Ordering also interacts with failure recovery. A FIFO message group can block later messages for the same group while an earlier item repeatedly fails, which preserves order but may increase business latency. Decide whether strict ordering is worth that coupling. Sometimes version checks allow consumers to accept out-of-order events safely, while other domains such as financial state transitions require sequence. The transport should implement only the ordering guarantee the domain genuinely needs.<\/p>\n Queues, topics, and event buses are resources with policies that can accept or reject principals from other accounts. In multi-account AWS organizations, central event buses can collect selected events while application accounts retain ownership of their producers and consumers. Resource policies should name trusted accounts or organizations precisely, and execution roles used by targets should receive only the permissions required for that target action.<\/p>\n Encryption, sensitive payloads, and secrets also influence the design. Avoid placing credentials or regulated data in events unless consumers truly need them. KMS encryption can protect supported messaging resources, but key policies must allow the publishing and consuming paths. The broader security expectations covered by AWS Security Specialty<\/a> apply here too: least privilege, traceability, and separation of duties should survive as the event topology grows across accounts.<\/p>\n Cross-account messaging is often a good point to separate platform and application ownership. A central platform can provide event buses or topics with organization-level policies, while application accounts retain their queues and consumers. Resource policies should be reviewed like network firewall rules because they define who can inject events into trusted workflows. Add source attributes or signing context where consumers need to distinguish platform events from application-originated messages.<\/p>\n A common robust pattern is EventBridge for business-event routing followed by SQS for consumer-specific buffering. The event bus decides which consumer is interested, while the queue protects that consumer from bursts and outages. Another pattern is SNS fanout to multiple SQS queues when every subscriber should receive the same publication but process independently. The services are complementary because routing, fanout, and buffering are different responsibilities.<\/p>\n Avoid chains that add services without adding a capability. SNS to EventBridge to SNS to SQS may be technically possible but difficult to operate if each hop exists only because a template recommended it. Every component should answer a concrete question: who routes, who retains, who fans out, who retries, and who transforms? The AWS Well-Architected Framework<\/a> encourages this kind of explicit tradeoff because operational complexity is itself an architectural cost.<\/p>\n Combining EventBridge with SQS also improves maintenance. A consumer can be paused for deployment while events continue arriving on its queue, then resume and drain the backlog. Without that buffer, an EventBridge target outage may rely only on delivery retries and DLQ behavior. The extra queue is justified when independent consumer recovery is valuable; it is not required for every target. This is exactly the kind of architectural tradeoff that should be tied to failure behavior rather than to a fixed pattern catalogue.<\/p>\nChoose the interaction model before choosing the service<\/h3>\n
Use SQS to create a durable buffer and control backpressure<\/h3>\n
Use SNS when one publication must fan out to many subscribers<\/h3>\n
Use EventBridge when routing depends on structured event meaning<\/h3>\n
Design delivery semantics around retries and idempotency<\/h3>\n
Separate ordering requirements from business correctness<\/h3>\n
Use cross-account and security boundaries deliberately<\/h3>\n
Combine services to isolate failures instead of building one giant bus<\/h3>\n
Instrument the event path and plan for replay<\/h3>\n