SNS vs SQS vs EventBridge: 4x Message Size Gap [2026]

September 2, 2026

21 min read

Every AWS architect eventually hits the same wall: a service needs to talk to another service, and there are three native ways to make that happen. Amazon SQS queues a message and waits for a worker to pick it up. Amazon SNS fans a single message out to dozens of subscribers at once. Amazon EventBridge routes structured events across an entire application estate, including software-as-a-service partners outside AWS. All three ship as fully managed, pay-per-use primitives, and all three show up in nearly identical serverless architecture diagrams, which is exactly why teams keep asking which one actually fits their workload. This comparison breaks down the pricing, the hard technical limits, the benchmarks, and the migration paths between SNS, SQS, and EventBridge as they stand in September 2026, using AWS’s own documented quotas and current published pricing.

The short version: SQS is a queue, SNS is a broadcast topic, and EventBridge is an event router with built-in filtering and SaaS integrations. But the short version glosses over pricing gaps that can swing a monthly bill by thousands of dollars, message size limits that differ by 4x between services, and throughput ceilings that determine whether a design survives a traffic spike. Below is the full breakdown, including a 12-row specs table, real per-million pricing, five-plus production architecture patterns, a step-by-step migration guide, and a data-backed verdict.

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Are SNS, SQS, and EventBridge, Really?

All three services sit in the same “AWS messaging and eventing” family, but they solve different plumbing problems. Confusing them is the single most common mistake in serverless architecture reviews, according to the AWS decision guide that AWS itself publishes to help teams pick the right one. All three are serverless in the sense that there is no broker to patch, no cluster to size, and no capacity to pre-provision, which is a large part of why they replaced self-managed message brokers in so many AWS-native architectures over the past several years.

Amazon SQS: the queue

SQS (Simple Queue Service) is a point-to-point message queue. A producer sends a message, the message sits in the queue, and exactly one consumer picks it up and processes it before deleting it. It is the buffer that decouples a fast-moving producer from a slower or less reliable consumer. SQS comes in two flavors: Standard queues, which offer nearly unlimited throughput with at-least-once delivery and best-effort ordering, and FIFO queues, which guarantee strict ordering and exactly-once processing at a lower throughput ceiling and a 25% price premium, according to AWS’s own SQS pricing documentation.

Amazon SNS: the broadcast topic

SNS (Simple Notification Service) is a publish-subscribe topic. A publisher sends one message to a topic, and SNS pushes a copy to every subscriber attached to that topic, whether that subscriber is an SQS queue, a Lambda function, an HTTP endpoint, a mobile push token, an email address, or an SMS number. It is the fan-out layer: one event in, many parallel deliveries out. SNS does not hold messages for later retrieval the way a queue does. It pushes and moves on.

Amazon EventBridge: the event router

EventBridge is a serverless event bus that ingests structured JSON events from AWS services, custom applications, and SaaS partners, then routes them to targets based on pattern-matching rules. It is the newest of the three and the most feature-rich, with add-ons like EventBridge Pipes for point-to-point integration with filtering and transformation, EventBridge Scheduler for cron-style invocations, and API Destinations for calling external HTTP APIs with built-in auth handling, all covered in AWS’s EventBridge pricing documentation. Where SNS fans a message out to whoever is subscribed, EventBridge decides where an event goes based on the content of the event itself.

SNS vs SQS vs EventBridge: Specs at a Glance

The table below pulls directly from AWS’s published quotas documentation and 2026 pricing pages. These are hard technical ceilings, not marketing round numbers, and they matter more than most teams expect once traffic scales past a proof of concept.

Attribute	Amazon SQS	Amazon SNS	Amazon EventBridge
Messaging pattern	Point-to-point queue	Publish/subscribe fan-out	Content-based event routing
Max message/event size	1,048,576 bytes (1 MiB)	262,144 bytes (256 KiB)	256 KB per event (default bus)
Message retention	60 sec to 14 days (default 4 days)	Not retained; push-only delivery	Not retained by default; Archive/Replay add-on available
Delivery guarantee	At-least-once (Standard); exactly-once (FIFO)	At-least-once	At-least-once
Ordering	Best-effort (Standard); strict (FIFO)	Best-effort (Standard); strict (FIFO topics)	Not guaranteed across rules
Visibility timeout	0 sec to 12 hours (default 30 sec)	Not applicable	Not applicable
Max delivery delay	900 sec (15 min)	Not applicable	Not applicable
Inflight message cap	120,000 (Standard); 20,000 (FIFO)	Not applicable	Not applicable
Subscribers/targets	Single consumer group per queue	Up to 12,500,000 subscriptions per Standard topic; 100 per FIFO topic	Up to 5 targets per rule (soft limit)
Topics/buses per account	Not applicable (queue-based)	100,000 topics per account (default)	100 event buses per Region (default)
Typical latency	Sub-second, not formally published	Sub-second, not formally published	About half a second, per AWS’s EventBridge FAQ
Native SaaS partner ingestion	No	No	Yes, via partner event sources

Two numbers in that table are worth pausing on. The message size gap between SQS (1 MiB) and SNS (256 KiB) is exactly 4x, and it is not a rounding difference: if a payload legitimately needs to carry more than 256 KB of data, SNS alone cannot deliver it and the payload has to be trimmed, compressed, or replaced with a reference to an object in S3. And EventBridge’s 5-targets-per-rule soft limit, confirmed in AWS’s own best-practices guide for defining rules, means that a single event source that needs to reach a dozen downstream systems will need more than one rule or an SNS/SQS layer in between.

Amazon SQS Explained: Standard vs FIFO Queues

SQS is the oldest of the three services and remains the default choice whenever a workload needs a durable buffer between a producer and a consumer that might be slower, might fail, or might need to retry. A Standard queue supports what AWS’s own quotas page calls “a very high, nearly unlimited number of API calls per second” per action, which in practice means SendMessage, ReceiveMessage, and DeleteMessage calls scale with almost no ceiling a typical application will ever hit. The tradeoff is that Standard queues deliver messages at least once and in best-effort order, so duplicate processing and out-of-order delivery are both possible and need to be handled at the consumer level, usually with idempotency keys.

FIFO queues close that gap by guaranteeing exactly-once processing and strict first-in-first-out ordering within a message group, which matters for use cases like financial transaction logs, inventory adjustments, or any workflow where processing message B before message A would corrupt state. That guarantee costs a documented 25% pricing premium over Standard queues and caps the inflight message count at 20,000, a lower ceiling than the 120,000 that applies to Standard queues, according to AWS’s SQS message quotas documentation. The visibility timeout, which controls how long a message stays hidden from other consumers after being picked up, ranges from 0 seconds to 12 hours with a 30-second default, giving teams room to tune for slow-processing workers without over-provisioning retries.

One quota that trips up teams building high-throughput pipelines: the maximum delivery delay on any single message is 900 seconds, or 15 minutes. Anything that needs to be scheduled further out than that has to go through a different mechanism entirely, which is one of the reasons EventBridge Scheduler exists as a separate product.

Amazon SNS Explained: Pub/Sub and Multi-Channel Fan-Out

SNS earns its keep the moment a single event needs to reach more than one destination type at once. A single published message can simultaneously land in an SQS queue for asynchronous processing, trigger a Lambda function for a synchronous side effect, hit an HTTP/S webhook, and push a mobile notification, all from one publish call. According to AWS’s SNS FAQ, deliveries to SQS queues and Lambda functions carry no additional SNS-side delivery charge beyond the publish request itself, which makes SNS a cost-efficient fan-out layer in front of queue-based workers. Topic and subscription quotas are documented separately in AWS’s SNS endpoints and quotas reference, which is the authoritative source for the subscriber ceilings listed in the specs table above.

Delivery pricing diverges sharply by protocol once messages leave the AWS-to-AWS path. HTTP/S endpoint deliveries run $0.60 per million notifications, mobile push runs $0.50 per million after the first 1,000 free per month, and email runs $2.00 per 100,000 notifications after the first 1,000 free, per AWS’s current SNS pricing guide. That spread means a notification architecture that leans heavily on email delivery will cost meaningfully more per message than one that routes through SQS or Lambda, a detail that often gets missed until the first real invoice arrives.

SNS also supports FIFO topics for teams that need both fan-out and strict ordering, though the two guarantees come at different price points: FIFO publish and batch-publish requests run $0.30 per million plus $0.017 per GB of payload, while subscription messages from a FIFO topic run $0.01 per million plus $0.001 per GB. Subscription filter policies let a topic route only relevant messages to each subscriber based on message attributes, which is the closest SNS gets to EventBridge-style content-based routing, though it operates on a much simpler attribute-matching model rather than full event pattern rules.

Amazon EventBridge Explained: Buses, Pipes, and Scheduler

EventBridge is built around the idea of a shared event bus that any AWS service, custom application, or SaaS partner can publish to, paired with rules that pattern-match on event content and route matches to one or more targets. The default event bus receives AWS service events, such as an EC2 state change or an S3 object creation, entirely free of ingestion charges. Custom events published by an application, and partner events from SaaS integrations, cost $1.00 per million events ingested, according to AWS’s EventBridge pricing page, with rule evaluation itself listed as free and unlimited.

Three newer EventBridge components extend what the core event bus can do. EventBridge Pipes connects a source, such as an SQS queue, a Kinesis stream, or a DynamoDB stream, directly to a target with built-in filtering and transformation, billed at $0.40 per million requests after filtering is applied, positioning it as a low-code replacement for the custom poller Lambda functions teams used to write by hand. EventBridge Scheduler replaces cron jobs and the older CloudWatch Events scheduling model, billed at $1.00 per million invocations with 14 million invocations included free every month. API Destinations route events to external HTTP APIs outside AWS entirely, with built-in authentication and rate-limiting, billed at $0.20 per million events delivered with no free tier.

Cross-account delivery, where an event bus in one AWS account routes events to a bus in another account, costs $1.00 per million events delivered, while same-account delivery is free. That distinction matters for organizations running multi-account AWS setups for security isolation, since a centralized logging or governance account that ingests events from dozens of workload accounts will see that cross-account line item scale with the size of the organization. AWS’s own EventBridge FAQ states typical latency runs about half a second, the only one of the three services with a formally published latency figure.

Pricing Breakdown: What Each Service Actually Costs in 2026

Sticker pricing on all three services looks deceptively close, clustered between $0.40 and $1.00 per million operations. The real cost divergence shows up in delivery protocols and add-on features, not the headline number. The table below consolidates current 2026 pricing pulled from AWS’s own pricing pages and corroborated by independent AWS cost-analysis guides.

Service / component	Price	Free tier
SQS Standard queue requests	$0.40 per million	First 1M requests/month free
SQS FIFO queue requests	$0.50 per million (25% premium)	First 1M requests/month free
SQS Standard, high volume (100B–200B/mo)	$0.30 per million	Volume-tiered discount
SNS Standard topic publish	$0.50 per million requests	First 1M requests/month free
SNS FIFO topic publish	$0.30 per million + $0.017/GB payload	None documented
SNS delivery: SQS or Lambda	No SNS-side delivery charge	N/A
SNS delivery: HTTP/S	$0.60 per million notifications	None documented
SNS delivery: mobile push	$0.50 per million	First 1,000/month free
SNS delivery: email	$2.00 per 100,000	First 1,000/month free
EventBridge custom/partner event ingestion	$1.00 per million events	AWS service events on default bus: free
EventBridge cross-account delivery	$1.00 per million events delivered	Same-account delivery is free
EventBridge Pipes	$0.40 per million requests (post-filter)	None documented
EventBridge Scheduler	$1.00 per million invocations	First 14M invocations/month free
EventBridge API Destinations	$0.20 per million events delivered	None

Run the numbers on a concrete scenario: a system processing 50 million events a month that fans a copy out to five downstream Lambda targets through SNS Standard would pay roughly $25 for publishing (50M ÷ 1M x $0.50) with zero additional delivery charge, since Lambda deliveries carry no SNS-side fee. Route the same 50 million events through EventBridge custom events instead, and ingestion alone runs $50 (50M ÷ 1M x $1.00), before any Pipes, Scheduler, or API Destination charges are added. SQS, by contrast, is priced per request rather than per fan-out target, so a straightforward one-producer-to-one-consumer queue at that volume runs about $20 on a Standard queue. None of these numbers include the compute cost of the Lambda functions or EC2 instances doing the actual processing, which typically dwarfs the messaging layer’s cost at moderate scale.

Performance, Throughput, and Latency Compared

Throughput is where the three services separate most clearly, and it is also where AWS’s documentation is least willing to commit to a specific number for two of the three. SQS Standard queues are documented as supporting “a very high, nearly unlimited” rate of API calls per second per action, which in practice scales to what most workloads will ever need without a support ticket. SQS FIFO queues are throughput-limited by message group parallelism rather than a single hard ceiling, and the inflight message cap is 120,000 for Standard queues and 20,000 for FIFO queues, according to AWS’s SQS FAQ documentation.

SNS FIFO topics carry a documented default quota of 3,000 messages per second per topic, per AWS re:Post guidance on SNS FIFO throughput, though actual sustained throughput without message batching can run lower in practice. SNS Standard topics do not publish a fixed messages-per-second ceiling in the same way SQS does, since fan-out delivery speed depends heavily on the number and type of subscribers attached to a topic.

EventBridge is the only one of the three with a formally published end-to-end latency figure: AWS’s own EventBridge FAQ states typical latency runs about half a second from event ingestion to target invocation, with the caveat that “this can vary” depending on rule complexity, target type, and account load. That half-second figure covers the full ingest-match-route-invoke pipeline, not just network transit, which makes it a meaningfully different measurement than a raw queue-to-consumer latency number. Teams building latency-sensitive paths, such as real-time fraud scoring or live chat delivery, generally route around EventBridge’s rule-matching layer entirely and use SNS or direct Lambda invocation instead, reserving EventBridge for workflows where half a second of routing overhead is immaterial next to downstream processing time.

Real-World Architecture Examples

These patterns show up repeatedly across production AWS accounts, and picking the wrong one for a given problem is usually what forces a costly re-architecture eighteen months in.

Order processing with SQS FIFO. An e-commerce checkout service publishes order events to a FIFO queue keyed by customer ID, guaranteeing that a customer’s cancel-then-reorder sequence never gets processed out of order, with exactly-once delivery preventing duplicate charges.
Multi-channel alerting with SNS. A monitoring stack publishes a single CloudWatch alarm to an SNS topic that simultaneously pages on-call engineers via SMS, posts to a Slack webhook via HTTP/S, and writes to an SQS queue for incident-tracking automation, all from one publish call.
Central event bus for a multi-team SaaS product. A platform team stands up a custom EventBridge event bus that every microservice publishes domain events to, letting a dozen independent teams subscribe to only the event types their service cares about without any team needing to know who else is listening.
Stream processing glue with EventBridge Pipes. A team replaces a hand-written Lambda poller that read from a DynamoDB Streams source with an EventBridge Pipe that filters and transforms records before invoking a Step Functions workflow, cutting custom polling code entirely.
Scheduled batch jobs with EventBridge Scheduler. A finance team replaces a fleet of cron-triggered EC2 scripts with EventBridge Scheduler invocations that kick off nightly reconciliation Lambda functions, billed per invocation instead of per always-on server.
Buffered image processing with SQS Standard. A photo-sharing app pushes upload events to a Standard queue that a fleet of worker Lambdas drains at whatever pace matches current capacity, absorbing traffic spikes without dropping uploads.

Several of these patterns combine services rather than picking just one. SNS-to-SQS fan-out, where an SNS topic delivers into multiple SQS queues so that each subscriber gets its own independently-consumable buffer, is common enough that AWS documents it as a first-class pattern in its own architecture guidance rather than a workaround.

When to Use SQS vs SNS vs EventBridge

Reach for SQS when there is exactly one logical consumer group for a stream of work items and that work needs to survive a consumer outage without being lost. Order fulfillment queues, image-processing job queues, and retry buffers in front of flaky third-party APIs are textbook SQS territory. The dead-letter queue pattern, where messages that fail processing after a configured number of retries move to a separate queue for manual inspection, is one of the most widely used reliability patterns in AWS architectures and is native to SQS.

Reach for SNS when one event needs to reach multiple independent consumers of different types at the same time, especially across notification channels like email, SMS, and push alongside programmatic subscribers like Lambda and SQS. If the mental model is “broadcast,” SNS is almost always the right starting point, and its per-request pricing with free SQS/Lambda delivery keeps costs predictable at scale.

Reach for EventBridge when routing decisions depend on the content of the event itself, when SaaS partners need to publish events directly into the pipeline, or when the workflow needs scheduling, filtering, or transformation built into the routing layer rather than handled in application code. EventBridge is also the natural choice for organizations standardizing on a single, centrally governed event schema across many independent teams, since its schema registry and pattern-matching rules scale better across dozens of event producers than SNS subscription filters do.

How to Migrate Between SNS, SQS, and EventBridge

Most migrations run in one direction: teams that started with a tangle of SNS topics and SQS queues move toward a centralized EventBridge bus as the number of event producers and consumers grows past what manual topic subscriptions can manage cleanly. Here is the sequence that keeps that migration safe.

Inventory every existing SNS topic and SQS queue, along with every publisher and subscriber attached to each, before touching any infrastructure.
Stand up a new custom EventBridge event bus dedicated to the migrating workload, keeping it separate from the AWS default bus.
Define EventBridge rules that mirror the existing SNS subscription filter logic, using event pattern matching instead of message attributes.
Dual-publish: modify producers to publish to both the legacy SNS topic and the new EventBridge bus simultaneously, without removing the old path yet.
Point one non-critical consumer at the new EventBridge target and validate that event delivery, ordering, and payload shape match the legacy path.
Migrate remaining consumers one at a time, monitoring EventBridge’s CloudWatch metrics for failed invocations and throttling after each cutover.
For any consumer that needs durable buffering rather than direct invocation, route the EventBridge rule to an SQS queue as its target rather than invoking Lambda directly.
Once every consumer is confirmed running on the new path for at least one full traffic cycle, including any weekly or monthly peak, remove the dual-publish step from producers.
Decommission the legacy SNS topic only after confirming zero subscriber traffic in CloudWatch for a minimum of one week.

The EventBridge event pattern below shows the rough shape of a rule that replaces an SNS subscription filter policy matching on an “order-placed” event type with a region attribute of “us-east-1”:

{
  "source": ["custom.orders"],
  "detail-type": ["order-placed"],
  "detail": {
    "region": ["us-east-1"]
  }
}

Migrating from SQS to SNS, by contrast, usually happens when a single-consumer queue needs to add a second or third independent consumer. Rather than fighting one queue to serve multiple logical consumers, the standard move is to place an SNS topic in front of the existing queue and add new SQS queues as additional subscribers, preserving the original queue’s consumer logic entirely while fan-out handles the new destinations.

Pros and Cons of Each Service

Amazon SQS

Pro: nearly unlimited Standard queue throughput with a straightforward, well-understood cost model.
Pro: FIFO queues deliver strict ordering and exactly-once processing when correctness matters more than raw speed.
Pro: built-in dead-letter queue support makes failure handling simple to reason about.
Con: strictly point-to-point, so fanning a queue’s contents out to multiple consumers requires bolting on SNS.
Con: 900-second maximum delivery delay rules out any long-horizon scheduling use case.

Amazon SNS

Pro: true multi-protocol fan-out in one publish call, spanning SQS, Lambda, HTTP/S, email, SMS, and mobile push.
Pro: free delivery to SQS and Lambda keeps programmatic fan-out costs low at scale.
Con: 256 KiB message size cap is a quarter of SQS’s limit, forcing payload trimming for larger events.
Con: no message retention or replay, so a message not delivered at publish time is gone.
Con: subscription filter policies are attribute-based and less expressive than EventBridge’s full event pattern matching.

Amazon EventBridge

Pro: content-based routing with real pattern matching, not just attribute filters.
Pro: native SaaS partner event sources and API Destinations extend the bus outside AWS entirely.
Pro: Scheduler and Pipes fold cron jobs and stream-to-target glue code into the same billing and monitoring surface.
Con: highest per-event ingestion cost of the three at $1.00 per million for custom events.
Con: 5-target-per-rule soft limit means high-fan-out scenarios still need SNS or multiple rules.
Con: no formal ordering guarantee across rules, so strict sequencing needs to happen downstream.

Common Mistakes Teams Make

The most frequent design error is choosing EventBridge by default because it is the newest and most feature-rich option, then paying for filtering and routing capability a simple one-to-one integration never needed. A workload with a single producer and a single consumer rarely benefits from EventBridge’s pattern-matching layer, and a plain SQS queue will be both cheaper and simpler to operate.

The second most common mistake is underestimating SNS’s 256 KiB message ceiling during design, only to discover in testing that a real-world payload, such as an image metadata blob or a nested JSON order object, occasionally exceeds it. The standard fix is the claim-check pattern: store the full payload in S3 and publish only a reference and summary through SNS, which also keeps per-message costs down since SNS and EventBridge pricing scales with request count, not payload size, apart from SNS FIFO’s per-GB payload charge.

A third mistake is treating SQS’s 120,000 inflight message quota as a soft guideline rather than a hard ceiling. Once a queue’s inflight count hits that limit, further ReceiveMessage calls return fewer messages or none at all until consumers catch up, which shows up in production as a mysterious throughput plateau that has nothing to do with consumer capacity and everything to do with an unprocessed backlog exceeding the quota.

Security and IAM Considerations

All three services authenticate and authorize through standard AWS IAM policies, but the practical security posture differs once a topic, queue, or event bus needs to accept traffic from outside its own AWS account. SQS queues use resource-based policies to control which principals can send or receive messages, and because a queue has no concept of subscribers, the security surface is limited to who can call SendMessage, ReceiveMessage, and DeleteMessage on that one resource. That narrow surface is part of why SQS is often the safest default for internal-only pipelines that never need to accept traffic from outside the account.

SNS topics add a second layer: topic policies control who can publish, while individual subscriptions control who can receive, and cross-account subscriptions are common enough that misconfigured topic policies are a recurring source of accidental public exposure in AWS security audits. Encryption at rest is available on both SQS and SNS through AWS KMS, and enabling it is a one-line resource attribute rather than a structural change, so there is rarely a good reason to leave it off for anything carrying customer data.

EventBridge inherits the most complex permission model of the three, since a single event bus can have rules that route to Lambda, SQS, Step Functions, API Destinations, and cross-account buses simultaneously, each requiring its own resource-based policy or IAM role. Cross-account event delivery specifically requires a resource policy on the receiving bus that allow-lists the sending account, and getting that policy wrong is one of the most common causes of silently dropped events reported in AWS support cases, since a failed cross-account send does not always surface as an obvious error to the publisher.

Monitoring and Observability

All three services publish metrics to CloudWatch by default, but the metrics that matter differ by service. For SQS, the two numbers worth alerting on are ApproximateNumberOfMessagesVisible, which signals a growing backlog that consumers cannot keep up with, and ApproximateAgeOfOldestMessage, which catches stuck messages before they age out of the retention window entirely. Since the inflight message cap sits at 120,000 for both Standard and FIFO queues, teams running high-throughput pipelines typically alert well before that ceiling to avoid the silent throughput plateau that shows up once the cap is hit.

SNS exposes NumberOfNotificationsFailed and NumberOfNotificationsFilteredOut as the primary health signals, the second of which is easy to overlook but essential for catching a subscription filter policy that has silently started dropping messages it should be delivering. EventBridge’s most useful metric is FailedInvocations combined with ThrottledRules, since a rule that is being throttled will not always show up as an outright failure in application-level logging, only as a gap in expected downstream activity. Because EventBridge’s own FAQ documents typical routing latency at around half a second, teams building latency dashboards for EventBridge-based pipelines generally baseline against that figure rather than the sub-millisecond expectations that make sense for a direct Lambda invocation.

Cost Optimization Tips for High-Volume Messaging

Batching is the single biggest lever across all three services. SQS SendMessageBatch, SNS PublishBatch, and EventBridge PutEvents all accept multiple messages per API call, and since every one of these services prices per request rather than per message within a batch, combining ten small messages into one batched call can cut the request-count portion of a bill roughly tenfold. Teams processing high-frequency, low-value events, such as IoT telemetry or clickstream data, see the largest savings from batching because the request-count charge dominates the bill at that volume relative to any per-GB payload fees.

The second lever is choosing Standard over FIFO wherever ordering and exactly-once processing are not actually required by the business logic, since FIFO carries a documented 25% premium on SQS and a different, generally higher, cost structure on SNS once payload size is factored in. It is common to see FIFO queues provisioned by default during initial development because the guarantees sound safer, then quietly downgraded to Standard once a team confirms the workload tolerates at-least-once delivery with idempotent consumers, which is cheaper and has a much higher throughput ceiling.

On EventBridge specifically, routing AWS service events through the free default bus rather than re-publishing them as custom events avoids the $1.00-per-million ingestion charge entirely, since AWS service events remain free regardless of how many rules or targets consume them. And for any workload spanning more than roughly 100 billion SQS requests a month, the tiered volume discounts bring Standard queue pricing down to $0.24 per million and FIFO down to $0.35 per million, a detail easy to miss since AWS’s default pricing calculator often shows only the entry-level rate.

The Verdict: Which Service Should You Choose

There is no single winner here, and any comparison that claims otherwise is oversimplifying three services built to solve different problems. SQS wins on raw cost and throughput for straightforward one-producer-to-one-consumer buffering, at $0.40 per million requests with the highest per-message size ceiling of the three. SNS wins on multi-channel fan-out economics, since Lambda and SQS deliveries carry no additional SNS-side charge beyond the $0.50-per-million publish cost. EventBridge wins on routing sophistication and SaaS connectivity, at the highest per-event price of the three ($1.00 per million for custom events) and with the tightest per-rule fan-out limit (5 targets).

In practice, mature AWS architectures rarely pick just one. A common production pattern uses EventBridge as the central nervous system for cross-team, content-routed events, SNS for multi-protocol alerting and notification fan-out, and SQS as the durable buffer sitting behind both, absorbing traffic spikes in front of whatever compute actually does the work. Start with the simplest service that solves the immediate problem, most often SQS or SNS, and graduate to EventBridge only once routing complexity or SaaS integration needs actually demand it.

Frequently Asked Questions

Can I use SNS and SQS together?

Yes, and it is one of the most common AWS messaging patterns. An SNS topic fans a message out to multiple SQS queues, giving each downstream consumer its own independently durable buffer while still broadcasting from a single publish call.

Is EventBridge replacing SNS and SQS?

No. EventBridge adds a content-based routing layer on top of the same underlying delivery mechanisms, and it frequently uses SQS as a target for buffered delivery. All three services remain actively developed and serve distinct roles in AWS’s messaging lineup.

Which service is cheapest for high-volume messaging?

SQS Standard queues are the cheapest per-request option at $0.40 per million, with volume discounts down to $0.24 per million above 200 billion requests a month. SNS delivery to SQS or Lambda adds no extra cost beyond its $0.50-per-million publish fee, while EventBridge’s $1.00-per-million custom event ingestion is the most expensive of the three on a per-event basis.

What is the maximum message size for each service?

SQS supports messages up to 1,048,576 bytes (1 MiB). SNS caps messages at 262,144 bytes (256 KiB), exactly a quarter of SQS’s limit. EventBridge events on the default bus are limited to 256 KB. Payloads that exceed these limits typically use the claim-check pattern, storing the full payload in S3 and passing a reference.

Does SQS or SNS guarantee message ordering?

Only the FIFO variants of each service do. SQS FIFO queues and SNS FIFO topics both guarantee strict ordering within a message group and exactly-once processing, at a documented cost premium and lower throughput ceiling compared with their Standard counterparts. EventBridge does not guarantee ordering across rules.

How many targets can a single EventBridge rule have?

Up to 5 targets per rule under the default soft limit, per AWS’s EventBridge quotas documentation. Workloads that need to fan an event out to more than five destinations typically split the logic across multiple rules or add an SNS topic as an intermediate fan-out layer.

Can EventBridge receive events from outside AWS?

Yes. EventBridge supports partner event sources from SaaS vendors that publish directly into a customer’s event bus, and API Destinations let EventBridge send events out to external HTTP APIs with built-in authentication, a capability neither SNS nor SQS offers natively.

Related Coverage

Nadia Dubois

AI & Innovation Editor

Nadia Dubois is the AI & Innovation Editor at Tech Insider, where she tracks the rapid evolution of artificial intelligence, from foundation models to real-world enterprise deployment. She previously covered AI and startups for La Tribune and contributed to MIT Technology Review's European coverage. Nadia specializes in generative AI, AI regulation, and the intersection of technology and European industrial policy. She holds a dual degree in Computational Linguistics and Journalism from Sciences Po Paris.

View all articles