PlayCloudLabs
Sign in
  1. Learn
  2. AWS
  3. Application integration
  4. SQS
AWSGCP laterAzure later

SQSAmazon Simple Queue Service

Application integrationCore service · full depthFree while we build the libraryChecked against AWS docs · 15 Sept 2026

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

  1. I know the problem it solves
  2. I can picture it
  3. I know how it scales
  4. I know how it fails
  5. I know when to choose it
  6. I can use it in a design
  7. I can answer an exam question

What & why

The problem it exists for

Some 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 kitchen

Waiters 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.

The railthe queueQueue
Clipping a ticketthe producer sendingSendMessage
A cook takes onea consumer pollingReceiveMessage
Hidden while cookinginvisible to everyone elseVisibilityTimeout
Ticket in the bindone, removedDeleteMessage
Sent to the managerthe dead-letter queuemaxReceiveCount

How it works

One message, start to finish
  1. SendMessageThe producer adds a message. SQS stores it in several Availability Zones before it says yes.
  2. ReceiveMessageA consumer polls. The message stays in the queue but turns invisible to everyone else for the visibility timeout.
  3. ProcessYour code does the work. It has to finish, or extend the timeout with ChangeMessageVisibility, before the timeout runs out.
  4. 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 pipeline

Architecture

Every order takes the same path: checkout to the API, into the queue, out to a worker, into the database. The dead-letter queue and the backlog alarm matter when something fails or the load changes.

Every order takes the same path: checkout to the API, into the queue, out to a worker, into the database. The dead-letter queue and the backlog alarm matter when something fails or the load changes.

The 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 queue

Each worker finishes 20 orders a second. One step of the chart is one second.

In the queue0
Oldest waiting0 s
Capacity80/s
50 waiting

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.

Target tracking on backlog
backlog per instance = ApproximateNumberOfMessages ÷ instances in service
target = longest acceptable wait ÷ time to process one message
e.g. 10 s ÷ 0.1 s = 100 messages per instance

Failure simulation

Crash a worker mid-message

In the queue

order-101received 0×
order-102received 0×
order-103received 0×
order-104received 0×

Being worked on

Done

Dead-letter queue

Visibility timeout 30 s, sped up to 6 s here. maxReceiveCount is 3.

  1. 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 encrypted

Access. 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 today

You 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
ServiceHow it deliversWho gets a messageKeeps messagesChoose it when
SQSConsumers pullOne consumer per messageUp to 14 daysWork must happen once, at the back end's pace
SNSPushes to subscribersEvery subscriber gets a copyNo. Retries, then discards it unless a dead-letter queue is attachedOne event, many independent receivers
EventBridgeRoutes by rules on the event's contentEvery target whose rule matchesOnly in an archive you create, which can replay themRouting AWS, SaaS and your own events, or running on a schedule
Kinesis Data StreamsConsumers read an ordered log per shardEvery consumer reads everything24 hours by default, up to 365 daysOrdered, replayable data read by several consumers
Amazon MQAn ActiveMQ or RabbitMQ brokerDepends on queue or topicYes, on the brokerExisting JMS, NMS, AMQP, STOMP or MQTT code, unchanged

SAA traps

The phrase in the question, and what it means
must 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 answer

A 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 work

Image 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?

Web clientLambda· Upload APIPick a service belowLambda· ResizeS3

Quick revision

The night before the exam
Visibility timeout
30 s by default, up to 12 h. Shorter than the work means duplicates.
Retention
4 days by default, from 1 min to 14 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 s per receive. Fewer empty responses, a lower bill.
Dead-letter queue
maxReceiveCount moves 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.

Still there?

You have been away for a while. We have saved what you were working on in this browser. In 60 seconds you will be signed out to keep your account safe.