Amazon SQS
n/a (managed service, no version)Summary
Fully managed AWS message queue offering standard queues (at-least-once, best- effort ordering, near-unlimited throughput) and FIFO queues (exactly-once processing, strict per-message-group ordering, bounded throughput), with a built-in redrive policy for dead-letter handling and zero broker administration.
Primary Use Case
Work queue distribution and async task processing on AWS where operating a broker (RabbitMQ, Kafka) is not justified by team size or workload volume, and where AWS-native integration (Lambda triggers, SNS fan-out, IAM-scoped access) outweighs the loss of AMQP-style routing flexibility.
Workload Fit
Strengths
Best for
- ·Work queue distribution on AWS without operating a broker
- ·Decoupling Lambda-based or serverless consumers from producers with zero infrastructure management
- ·FIFO processing where strict per-key ordering and exactly-once delivery are required at moderate volume
Excels when
- ·The team wants zero broker operations: no capacity planning, no patching, no HA configuration
- ·AWS-native integration (Lambda event source mapping, IAM-scoped queue access, SNS fan-out) reduces glue code
- ·Message volume fits within FIFO's throughput ceiling, or ordering is not required and standard queues apply
Architectural advantages
- ·Zero operational burden: no broker to patch, scale, or fail over, AWS owns all of it
- ·Built-in redrive policy provides dead-letter handling without consumer-side DLQ-publish logic
- ·Standard queue throughput scales transparently with no partition or shard planning
When to Avoid
Avoid when
- ·Consumers need to replay historical messages: SQS has no offset-based read cursor, a deleted or expired message is gone
- ·Cross-cloud or on-premises portability is required: SQS is AWS-only with no self-hosted or other-cloud equivalent
- ·Throughput needs exceed FIFO's ceiling and strict ordering is still required: no self-hosted tuning knob exists to raise it
Common misuses
- ·Assuming a standard queue delivers each message exactly once: it is at-least-once, and duplicates arrive from visibility-timeout expiry alone
- ·Treating SQS as a replayable event log: it has no offset-based read cursor and messages disappear on delete or retention expiry
- ·Setting visibility timeout equal to average processing time instead of worst-case: causes duplicate delivery under any latency spike
Consistency & Transactions
Scaling
Read scalability
Consumers poll independently; adding consumers scales read throughput linearly for standard queues since there is no partition count to bound parallelism. FIFO queues cap parallelism at the message-group count: consumers processing different groups run concurrently, but a single group is strictly serialized.
Write scalability
Standard queues accept near-unlimited publish throughput with no pre- provisioned partition or shard count. FIFO queues are capped (3,000 messages/second per API call with batching, 300/second without) because ordering and deduplication require per-message-group serialization.
Failure Behavior
Known failure modes
- ·Message received more than once from visibility-timeout expiry alone, even with a healthy consumer, if processing takes longer than the configured timeout
- ·FIFO queue throughput ceiling silently caps producer throughput under load, unlike a self-hosted broker where the operator controls the ceiling
- ·Redrive policy misconfiguration (maxReceiveCount too low) dead-letters transient failures that would have succeeded on the next attempt
- ·Long polling misconfigured as short polling increases empty-receive API cost and latency under low message volume
Bottlenecks
- ·FIFO queue throughput ceiling (3,000 messages/second batched) bounds strictly-ordered workloads well below standard-queue or Kafka throughput
- ·Message size limit (256KB) requires an external claim-check pattern (S3 reference) for larger payloads
Degradation patterns
- ·Visibility timeout expiry under sustained consumer slowness causes duplicate delivery to pile up rather than backlog visibly, unlike a queue depth metric
- ·FIFO message-group hot-keying serializes all messages in that group behind a single slow consumer, since a group cannot be parallelized
Recovery considerations
- ·No consumer-side offset to reset: recovery after a bad deploy relies entirely on the redrive policy and DLQ reprocessing, not log replay
- ·AWS manages queue availability across zones; there is no broker failover procedure for the operator to run
Operational Pitfalls
- ·Not setting visibility timeout longer than the consumer's worst-case processing time: causes duplicate delivery even without any failure
- ·Using a standard queue where the application logic assumes strict ordering: standard queues provide best-effort ordering only
- ·Not configuring a redrive policy at all: a permanently failing message retries indefinitely against the queue's own maxReceiveCount default with no visibility into the failure
Architecture Guidance
Common topology roles
Migration notes
- ·From RabbitMQ to SQS: AMQP exchange/binding routing has no equivalent; routing logic must move to the application or to SNS fan-out in front of SQS
- ·From SQS to Kafka: gaining replay and consumer-group fan-out requires redesigning consumers around an offset-based read cursor, which SQS does not have
Advisor Guidance
When: scenario needs a work queue on AWS without dedicated broker operations
SQS standard queues provide at-least-once delivery with near-unlimited throughput and zero broker administration; use FIFO only if strict per-key ordering is required
When: scenario requires message replay or multiple independent consumer groups reading the same stream
SQS has no offset-based read cursor: use Kafka or Pulsar if replay or fan-out to independent consumer groups is required
Comparison Factors
operational complexity
Lowest of any broker profile: no capacity planning, patching, or HA configuration, AWS owns all of it
throughput
Standard queues effectively unlimited; FIFO queues capped at 3,000 messages/second batched
message replay
None: no offset-based read cursor, deleted or expired messages cannot be replayed
portability
AWS-only, no self-hosted or other-cloud equivalent
Managed Cloud Options
Enables Patterns
Basis
Fully managed AWS service with stable, well-documented behavior; visibility-timeout semantics and redrive policy mechanics are precisely specified in AWS documentation
Sources & Claims
An SQS message becomes temporarily invisible (not deleted) when received; if the consumer does not delete it within the visibility timeout, it becomes visible again and is redelivered, which means a message can be received more than once even without any consumer failure, purely from timeout expiry
pendingofficial documentation · AWS SQS documentation, Visibility Timeout guide
messaging-knowledge-completion batch, added alongside Google Pub/Sub and Pulsar profiles
SQS FIFO queues are capped at 3,000 messages per second with batching (300 per second without), a lower throughput ceiling than standard queues, in exchange for strict per-message-group ordering and exactly-once processing via deduplication ID
pendingofficial documentation · AWS SQS documentation, FIFO queues quotas and limits
messaging-knowledge-completion batch