Summary:
- AWS SNS and SQS serve fundamentally different messaging paradigms. SNS pushes messages to multiple subscribers simultaneously, while SQS stores messages for consumers to pull at their own pace.
- FIFO variants of both services now support high-throughput modes with updated 2024-2025 quotas, including 30,000 messages per second per account for SNS FIFO topics and up to 700,000 batched messages per second for SQS FIFO queues.
- Cost structures diverge significantly at scale, with SNS charges varying by endpoint type and topic type, and SQS pricing based on request volume and message retention.
- Combining SNS and SQS in fan-out architectures delivers the best of both worlds with broadcast capability and durable, decoupled consumption.
When your distributed system needs to move millions of messages between microservices, the choice between AWS SNS and SQS can determine whether your architecture scales gracefully or collapses under load. These two services sit at the heart of event-driven design on AWS, yet engineers frequently conflate their purposes or underestimate the nuanced trade-offs between them. Understanding AWS SNS vs SQS differences directly impacts your system’s reliability, cost profile, and operational complexity. This guide dissects both services with the technical depth required for production-grade decisions, incorporating the latest 2024-2025 quota updates and architectural patterns that separate junior implementations from staff-level designs.
The following diagram illustrates the fundamental architectural difference between push-based and pull-based messaging models.
What are Amazon SNS and Amazon SQS
Amazon Simple Notification Service (SNS) operates as a fully managed publish-subscribe messaging service that pushes messages to multiple subscribers simultaneously. When a publisher sends a message to an SNS topic, the service immediately delivers that message to all subscribed endpoints. These endpoints can be AWS Lambda functions, SQS queues, HTTP webhooks, email addresses, or mobile push notifications. This push-based model excels when you need real-time fan-out to multiple consumers without the publisher needing to know anything about downstream systems.
Amazon Simple Queue Service (SQS) implements a pull-based message queuing model where producers send messages to a queue and consumers retrieve them at their own pace. Messages persist in the queue until a consumer explicitly deletes them after successful processing. This provides natural buffering against traffic spikes and consumer failures. SQS decouples producers from consumers temporally, meaning your upstream services can continue operating even when downstream processors are offline or overwhelmed.
The core architectural distinction comes down to delivery semantics. SNS implements a fire-and-forget push model where message delivery happens immediately and the service does not retain messages after delivery attempts complete. SQS implements a store-and-forward model where messages remain available for up to 14 days, allowing consumers to process at variable rates. This fundamental difference shapes every downstream decision about reliability, ordering, and failure handling.
With these foundational concepts established, examining the specific modes each service offers reveals deeper technical trade-offs.
Standard versus FIFO modes for SNS and SQS
Both SNS and SQS offer two operational modes that dramatically affect throughput, ordering guarantees, and deduplication behavior. Choosing the wrong mode can either leave you with insufficient throughput or unnecessary complexity and cost. The standard mode prioritizes maximum throughput with best-effort ordering, while FIFO mode guarantees strict message ordering and exactly-once processing at the cost of lower baseline throughput.
Standard mode characteristics
Standard SNS topics and SQS queues optimize for maximum throughput with nearly unlimited scalability. AWS does not impose hard limits on messages per second for standard resources, making them suitable for high-volume workloads where occasional duplicate delivery or out-of-order processing is acceptable. Standard SQS queues guarantee at-least-once delivery, meaning your consumers must be idempotent to handle the rare duplicate message.
Key characteristics of standard mode include:
- Throughput: Virtually unlimited for both SNS topics and SQS queues
- Ordering: Best-effort only, and messages may arrive out of sequence
- Delivery: At-least-once for SQS, and SNS retries based on endpoint type
- Deduplication: Not provided, so applications must handle duplicates
FIFO mode and high-throughput configurations
FIFO (First-In-First-Out) variants guarantee strict message ordering within message groups and provide exactly-once processing through content-based or explicit deduplication. AWS significantly enhanced FIFO capabilities in 2024-2025, introducing high-throughput modes that close the performance gap with standard resources. In January 2025, AWS introduced high-throughput mode for SNS FIFO topics, increasing the limit up to 30,000 messages per second (MPS) per account in supported regions (compared to the standard 3,000 MPS topic limit).
SQS FIFO queues received equally significant updates. The in-flight message limit, which previously capped at 20,000 messages, now supports up to 120,000 in-flight messages with high-throughput FIFO queues. Furthermore, SQS FIFO high-throughput mode now supports up to 70,000 API transactions per second (translating to a staggering 700,000 messages per second with batching) in top-tier regions like US-East-1. This increase addresses a critical bottleneck that previously forced architects to shard across multiple queues for high-volume ordered workloads. Message group IDs remain central to FIFO behavior, as ordering guarantees apply only within a single message group.
The following diagram shows how message group IDs partition ordering guarantees within FIFO resources.
Understanding these mode differences sets the stage for examining the specific quotas and limits that govern production deployments.
Current quotas and technical limits
Production architectures require precise knowledge of service limits to avoid runtime failures and capacity planning errors. AWS updated several critical quotas in 2024-2025, and many competitors’ guides still reference outdated figures. The following table consolidates current limits for both services across standard and FIFO configurations.
| Resource | Standard mode | FIFO mode (default) | FIFO high-throughput |
|---|---|---|---|
| SNS publish rate | Soft limit varies by region | 300 MPS per message group (3,000/topic) | 30,000 MPS per account |
| SNS subscriptions per topic | 12,500,000 | 100 | 100 |
| SQS messages per second | Unlimited (soft) | 300 MPS per queue | 70,000 TPS (up to 700k batched) |
| SQS in-flight messages | 120,000 | 20,000 | 120,000 |
| SQS message retention | 1 minute to 14 days | 1 minute to 14 days | 1 minute to 14 days |
| SQS visibility timeout | 0 seconds to 12 hours | 0 seconds to 12 hours | 0 seconds to 12 hours |
| Message size | 256 KB (both services) | 256 KB | 256 KB |
Regional variations exist for soft limits, and AWS allows quota increase requests through Service Quotas for most parameters. The in-flight message limit deserves particular attention for SQS consumers. This limit counts messages that have been received by a consumer but not yet deleted. Slow consumers or long visibility timeouts can exhaust this quota even at moderate message rates.
Cost comparison at scale
Pricing models for SNS and SQS differ substantially, and the cost implications compound at high message volumes. SNS charges based on the number of publishes and the type of delivery endpoint, while SQS charges per request regardless of message destination. Understanding these models prevents budget surprises when scaling from development to production workloads.
SNS pricing structure
SNS pricing varies dramatically by endpoint type and topic type. Publishing to a Standard topic costs $0.50 per million requests, while publishing to a FIFO topic costs $0.30 per million requests plus $0.017 per GB of payload data. Delivery charges depend on where messages go. Delivering to SQS queues or Lambda functions incurs no additional charge beyond the publish cost. However, SMS delivery ranges from $0.00645 to $0.75 per message depending on destination country, and HTTP/S endpoint deliveries cost $0.60 per million.
Consider a workload publishing 100 million messages monthly with fan-out to three SQS queues:
- Publish requests: 100M × $0.50/M = $50
- SQS deliveries: Free (no additional SNS charge)
- Total SNS cost: $50
The same workload fanning out to three HTTP endpoints instead:
- Publish requests: 100M × $0.50/M = $50
- HTTP deliveries: 300M × $0.60/M = $180
- Total SNS cost: $230
SQS pricing structure
After the first 1 million free requests each month, SQS charges $0.40 per million requests for standard queues and $0.50 per million for FIFO queues. Each API call counts as a request, including SendMessage, ReceiveMessage, and DeleteMessage. A single message lifecycle typically involves at least three requests: one send, one receive, and one delete. Batch operations reduce costs by allowing up to 10 messages per request.
| Workload scenario | SNS cost | SQS cost | Combined (fan-out) |
|---|---|---|---|
| 100M messages, single consumer | $50 (publish only) | $120 (3 requests each) | N/A |
| 100M messages, 3 SQS subscribers | $50 | $360 (3 queues × 3 requests) | $410 |
| 100M messages, FIFO single consumer | $30 (+ data payload) | $150 | N/A |
| 1B messages, 5 SQS subscribers | $500 | $6,000 | $6,500 |
Cost analysis naturally leads to architectural decisions about when and how to combine these services for optimal results.
Architectural patterns and best practices
Production systems rarely use SNS or SQS in isolation. The most resilient architectures combine both services to leverage push-based fan-out with pull-based durability. These patterns address common challenges around reliability, ordering, and failure handling that single-service approaches cannot solve elegantly.
SNS to SQS fan-out pattern
The fan-out pattern subscribes multiple SQS queues to a single SNS topic, enabling one publish operation to reach multiple independent consumer groups. Each SQS queue buffers messages independently, allowing consumers to process at different rates without affecting each other. This pattern is foundational for event-driven architectures where multiple services need to react to the same business events.
The following diagram illustrates a production fan-out architecture with dead-letter queue integration.
Dead-letter queue configuration
Dead-letter queues (DLQs) capture messages that fail processing after a configured number of attempts. For SQS, the redrive policy specifies the maximum receive count before messages move to the DLQ. SNS supports DLQs for failed deliveries to endpoints, capturing messages that exhaust retry policies. Proper DLQ configuration prevents message loss while isolating poison messages that would otherwise block queue processing.
Essential DLQ configuration parameters include:
- maxReceiveCount: Number of processing attempts before redrive (typically 3-5)
- DLQ retention: Set to maximum 14 days to allow investigation time
- Alarms: CloudWatch alarms on DLQ depth for operational visibility
- Redrive allow policy: Restrict which source queues can use the DLQ
Visibility timeout tuning
Visibility timeout determines how long a message remains invisible to other consumers after being received. Setting this value too low causes duplicate processing when consumers take longer than expected. Setting it too high delays reprocessing when consumers fail. The optimal value should exceed your 99th percentile processing time with a safety margin.
For Lambda consumers, AWS automatically extends the visibility timeout during function execution. For EC2 or container-based consumers, implement heartbeat patterns that call ChangeMessageVisibility periodically during long-running processing. This approach prevents timeout expiration while avoiding excessively long default timeouts.
Decision framework for SNS versus SQS
Selecting between SNS and SQS, or combining them, depends on your specific requirements around delivery semantics, consumer patterns, and operational constraints. The following framework provides concrete guidance based on common scenarios.
Choose SNS when your architecture requires:
- Broadcasting events to multiple heterogeneous subscribers
- Real-time push delivery to HTTP endpoints or mobile devices
- Integration with services that cannot poll (email, SMS)
- Minimal latency between publish and delivery
Choose SQS when your architecture requires:
- Buffering between producers and consumers with different throughput rates
- Guaranteed message persistence during consumer outages
- Controlled consumption rate with backpressure handling
- Long-running processing with visibility timeout management
Combine SNS and SQS when you need both fan-out capability and durable consumption. This combination is the default recommendation for most event-driven architectures because it provides maximum flexibility without sacrificing reliability. The AWS documentation on SNS-SQS integration provides additional implementation details.
Conclusion
The distinction between AWS SNS and SQS reflects a fundamental architectural choice between push-based broadcasting and pull-based queuing. SNS excels at real-time fan-out to multiple subscribers with minimal latency, while SQS provides durable message storage with consumer-controlled processing rates. The 2024-2025 updates to FIFO high-throughput modes have significantly expanded the viable use cases for ordered messaging. SNS FIFO topics now support 30,000 messages per second per account, and SQS FIFO queues handle up to 70,000 API operations per second alongside 120,000 in-flight messages.
Cost optimization at scale requires understanding that SNS charges vary by endpoint and topic type, while SQS charges accumulate per API request. The fan-out pattern combining both services remains the gold standard for event-driven architectures, providing broadcast capability with durable, independent consumption. As serverless and event-driven patterns continue dominating cloud architecture, mastery of these messaging primitives becomes essential for engineers designing systems that scale reliably under production load.
