SQSAmazon Simple Queue Service
A queue between the part of your system that creates work and the part that does it, so a slow or broken consumer never costs you the work.
Where SQS takes you7 steps, all open
- I know the problem it solves
- I can picture it
- I know how it scales
- I know how it fails
- I know when to choose it
- I can use it in a design
- I can answer an exam question
What & why
The problem it exists forSome parts of a system make work faster than other parts can finish it. In a flash sale a shop takes orders far quicker than its warehouse system can book them. Wire the two together directly and the slow side sets the pace of the fast side, or drops orders when it falls over.
SQS sits between them. The producer sends a message and moves on. Consumers take messages when they are ready. If every consumer is down for an hour, the orders wait in the queue instead of disappearing: a message is kept for 4 days by default, and for up to 14.
Reach for it when
- the work can finish after the request has been answered
- a spike must not overwhelm the back end
- consumers can fail and the work has to survive them
- you want to add workers as the backlog grows
It is the wrong tool when
- the caller needs the result now, in the same request
- several systems each need their own copy: that is SNS or EventBridge
- consumers must replay history: that is Kinesis
- existing code speaks JMS or AMQP: that is Amazon MQ
Mental model
The order rail in a restaurant kitchenWaiters clip tickets onto a rail and walk away. A cook takes one, and while it is being cooked nobody else can see it. The plate goes out and the ticket goes in the bin. If the cook walks out halfway through, the ticket goes back on the rail after a while for someone else. A ticket that has come back three times goes to the manager, because something about that order is wrong.
QueueSendMessageReceiveMessageVisibilityTimeoutDeleteMessagemaxReceiveCountHow it works
One message, start to finish- SendMessageThe producer adds a message. SQS stores it in several Availability Zones before it says yes.
- ReceiveMessageA consumer polls. The message stays in the queue but turns invisible to everyone else for the visibility timeout.
- ProcessYour code does the work. It has to finish, or extend the timeout with
ChangeMessageVisibility, before the timeout runs out. - DeleteMessageOnly a delete removes it. Forget to delete and the message comes back.
- Visibility timeout
- 30 sdefault · 0 s to 12 h
- Retention
- 4 daysdefault · 1 min to 14 days
- Long-poll wait
- ≤ 20 sper receive call
- Delivery delay
- 0 – 15 minper queue or message
- Batch
- ≤ 10messages per call
- Message size
- ≤ 1 MiBbigger payloads go through S3
Standard queue
- At-least-once delivery: the same message can arrive twice, so consumers must be idempotent
- Best-effort order: messages can arrive out of order
- A nearly unlimited number of calls a second
FIFO queue
- The queue name ends in
.fifo - Exactly-once processing: a send retried within the 5-minute deduplication interval adds no duplicate
- Strict order within each message group
- 300 calls a second per action, or 3,000 messages a second in batches of 10; high-throughput mode raises it a long way, depending on the Region
Architecture
The flash-sale order pipelineThe API answers the customer the moment the order is in the queue. Workers in an Auto Scaling group long-poll the queue and write to the database at the pace it can take. A message that is received three times without being deleted moves to the dead-letter queue, where it waits for a person instead of being retried forever. CloudWatch watches the backlog, and the workers scale with it. When a worker is replaced, whatever it had not finished becomes visible again for another worker.
Traffic simulation
Run a flash sale through the queueEach worker finishes 20 orders a second. One step of the chart is one second.
The workers keep up. Nothing waits.
Scaling
The queue scales itself. You scale the consumers.A Standard queue has no capacity to provision. What runs out is the consumers, and how you add them depends on what they run on.
Lambda scales for you. The event source mapping starts with five batches at once and adds up to 300 more concurrent invocations a minute while messages keep coming. To stop the functions overwhelming a database behind them, set maximum concurrency on the event source mapping, and keep the function's reserved concurrency at least that high, or Lambda throttles the messages.
Workers in an Auto Scaling group should scale on backlog per instance, not on CPU. A worker waiting on a slow database shows low CPU while the queue grows, so a CPU alarm may never fire.
FIFO gets its parallelism from message groups. Messages in one group are handled in order, one at a time, so more groups means more workers can run at once.
Failure simulation
Crash a worker mid-messageIn the queue
Being worked on
Done
Dead-letter queue
Visibility timeout 30 s, sped up to 6 s here. maxReceiveCount is 3.
- 4 messages are waiting. The worker has nothing yet.
maxReceiveCount is how many times a message can be received before it moves to the dead-letter queue. Set it high enough to allow real retries: at 1, a single failure sends a message aside.
Give the dead-letter queue a longer retention than the source queue. A Standard queue's message keeps its original enqueue time when it moves, so in a short-lived dead-letter queue it can expire before anyone looks at it. The dead-letter queue must be in the same account and Region as the source.
Security
Who can send, who can read, and what is encryptedAccess. IAM policies on your roles say what they may do. A queue policy on the queue itself is what lets another account, or a service such as SNS or S3, send to it.
At rest. SSE-SQS uses keys SQS manages. SSE-KMS uses a key in KMS. When an AWS service such as SNS, S3 or EventBridge sends to a queue encrypted with SSE-KMS, the key must be a customer managed key whose key policy lets that service call kms:GenerateDataKey and kms:Decrypt. The AWS managed key for SQS will not do: its key policy cannot be changed. Get this wrong and the messages never arrive.
In transit. A queue policy condition on aws:SecureTransport refuses any request that is not made over HTTPS.
Private access. A VPC endpoint lets workers in private subnets reach SQS without crossing the internet, and a queue policy can refuse requests that do not come through it.
Cost
How you are charged, not what it costs todayYou pay per request. Every SQS action is a request, and each 64 KB chunk of a payload is billed as one: a 200 KB message costs four requests to send.
Batch. Sending, receiving and deleting up to 10 small messages per call cuts the request count by up to ten.
Long-poll. An empty receive is a request too. Long polling waits up to 20 seconds for messages to arrive instead of asking again and again.
FIFO requests are charged at their own, higher rate. Every account gets 1 million requests a month free.
Data transfer between SQS and your resources in the same Region is free. Across Regions, or to and from the internet, it is billed at the usual AWS rates.
Prices change, so none are printed here. Check the SQS pricing page on aws.amazon.com.
Comparison
The services a question will offer you instead| Service | How it delivers | Who gets a message | Keeps messages | Choose it when |
|---|---|---|---|---|
| SQS | Consumers pull | One consumer per message | Up to 14 days | Work must happen once, at the back end's pace |
| SNS | Pushes to subscribers | Every subscriber gets a copy | No. Retries, then discards it unless a dead-letter queue is attached | One event, many independent receivers |
| EventBridge | Routes by rules on the event's content | Every target whose rule matches | Only in an archive you create, which can replay them | Routing AWS, SaaS and your own events, or running on a schedule |
| Kinesis Data Streams | Consumers read an ordered log per shard | Every consumer reads everything | 24 hours by default, up to 365 days | Ordered, replayable data read by several consumers |
| Amazon MQ | An ActiveMQ or RabbitMQ broker | Depends on queue or topic | Yes, on the broker | Existing JMS, NMS, AMQP, STOMP or MQTT code, unchanged |
SAA traps
The phrase in the question, and what it meansmust be processed exactly once, in the order receivedA FIFO queue
A Standard queue can deliver a message twice, and out of order.
some messages are processed more than onceRaise the visibility timeout
The work takes longer than the timeout, so the message reappears while the first worker is still on it. Or extend it as you go with ChangeMessageVisibility.
reduce the number of empty responsesLong polling
Set the receive wait time, up to 20 seconds.
each order must reach billing, shipping and analyticsSNS fanning out to one queue each
A single queue hands each message to only one of them.
migrate an application that uses JMS without changing codeAmazon MQ
SQS has its own API. MQ speaks the protocols the application already uses.
one malformed message keeps failingA dead-letter queue
Set maxReceiveCount so it is moved aside for a person to look at.
the payloads are larger than SQS allowsPayload in S3, pointer in the message
The Extended Client Library does this for you, for payloads up to 2 GB. SQS itself takes up to 1 MiB.
scale the EC2 workers that process the queueTarget tracking on backlog per instance
Not CPU. A worker stuck waiting shows low CPU while the queue grows.
Scenario
Exam style, marked when you answerA retailer's checkout API sends orders straight to a fulfilment service running on EC2. In a flash sale, orders arrive at ten times the usual rate, the fulfilment service falls behind, and some orders are lost when its instances are replaced. The order in which orders are fulfilled does not matter, but none may be lost, and checkout must keep answering customers in under a second. What should a solutions architect do?
Practice
Fill the gap, the way the challenges workImage uploads arrive in bursts. Each job must be handled by exactly one worker, and a job must survive the worker crashing halfway through. What goes in the gap?
Quick revision
The night before the exam- Visibility timeout
30 sby default, up to12 h. Shorter than the work means duplicates.- Retention
4 daysby default, from1 minto14 days.- Standard or FIFO
- At-least-once and best-effort order, or no duplicates and strict order per message group.
- Long polling
- Wait up to
20 sper receive. Fewer empty responses, a lower bill. - Dead-letter queue
maxReceiveCountmoves a message that keeps failing out of the way, for a person to look at.- Message size
- Up to
1 MiB. Anything bigger goes in S3, with a pointer in the message. - Scaling workers
- On backlog per instance. Never on CPU.
This whole page is free right now.The AWS library is still being written, so every page of it is open to everyone while that lasts. It becomes a paid bundle later; what you read today costs you nothing.
Checked against
Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.
- Amazon SQS standard queues
- Amazon SQS message quotas
- Amazon SQS FIFO queue quotas
- Amazon SQS visibility timeout
- Exactly-once processing in Amazon SQS
- Using dead-letter queues in Amazon SQS
- Managing large Amazon SQS messages using Amazon S3
- Amazon SQS key management
- Amazon SQS security best practices
- Amazon SQS pricing
- Scaling behaviour for SQS event source mappings (AWS Lambda)
- Scaling policy based on Amazon SQS (EC2 Auto Scaling)
- Amazon SNS message delivery retries
- Archiving and replaying events in Amazon EventBridge
- Changing the data retention period (Kinesis Data Streams)
- Amazon MQ FAQs