Amazon Simple Queue Service
SQS
You need to decouple application components by passing messages asynchronously between them without losing data.
Reach for it when
- Buffering incoming user order requests before passing them to a downstream processing microservice.
- Smoothing out traffic spikes by queueing background jobs for worker instances to process at their own pace.
- Retrying failed API integration calls by holding the requests in a dead-letter queue for later inspection.
Do not reach for it when
- Streaming real-time data feeds that need to be read multiple times by different consumer groups — use Kinesis instead.
- Broadcasting a single message to multiple independent subscriber systems simultaneously — use SNS instead.
- Managing complex multi-step workflows that require conditional branching and state tracking — use Step Functions instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| SNS | Choose it when you want to publish a message once and have it delivered to multiple endpoints immediately. |
| Kinesis | Choose it when you need to ingest high-volume streaming data that multiple consumers can replay. |
How you pay
- The model
- Pay per million message transactions, with one transaction representing a single request up to 64KB.
- The line item that surprises people
- Frequent short polling requests from idle consumers will accumulate millions of API calls, driving up the bill.
What trips people up
- The visibility timeout must be longer than the message processing time, or other consumers will pull and process duplicates.
- Standard SQS queues guarantee at-least-once delivery; your application consumers must be designed to be idempotent.
- FIFO queues guarantee order but cap throughput at 300 messages per second unless batching and high-throughput modes are enabled.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.