Amazon SQS

What SQS is

SQS is a durable, fully managed message queue. One component — a producer — drops a message on the queue; the message sits there until another component — a consumer — reads it, processes it, and deletes it. The two never talk directly, so a slow or failing consumer can’t block or crash the producer. It’s the default way to make work asynchronous on AWS.

Design Beaver models SQS as a regional, API-accessed service rather than something that sits inside a VPC subnet, and it validates as you draw which services can use the queue and how each connection has to be set up to be correct.

When to use SQS (and when not to)

Reach for SQS when work can happen asynchronously and you want a durable buffer between two components — so one can fail or scale independently of the other. It fits decoupling a request from slow work (an API enqueues an email job instead of sending it inline), buffering bursty traffic so a downstream consumer processes at its own steady rate, and fanning work out to a pool of workers that poll the queue. It’s for simple point-to-point delivery: one queue, one logical consumer group.

Don’t reach for it when you need pub/sub fan-out to many independent subscribers — a message on a queue is consumed once by one consumer group, so use SNS (often SNS in front of several SQS queues) for that. It’s also the wrong tool when the caller needs a synchronous response in the same request, or when you need event routing and filtering across many event types and targets — EventBridge fits that better.

Variants: standard vs FIFO

SQS has two queue types, and the choice comes down to one question: do you actually need strict ordering? Standard is the default; FIFO trades throughput for ordering and de-duplication.

Option	What it is
Standard queuedefault	Nearly unlimited throughput, at-least-once delivery, best-effort ordering. The default; handles the vast majority of workloads.
FIFO queue	Strict first-in-first-out ordering and exactly-once processing within a message group, at much lower throughput than standard. Use only when ordering or de-duplication is a real requirement.

SQS pricing

You pay per request — every send, receive, and delete is a request, and a single receive can pull up to 10 messages. Long polling and batching are the main levers that cut the request count driving your bill.

Pay per request (each API call — send, receive, delete — is a request; a single receive can return up to 10 messages). FIFO requests are priced higher than standard. Data transfer out is billed separately.

Option	Representative rate
standard	~$0.40 per million requests after the free tier
fifo	~$0.50 per million requests

Free tier

1,000,000 requests per month (Always Free)

Keeping the bill down

Use long polling and batch sends/receives (up to 10 messages per call) to cut the request count that drives the bill

us-east-1 (rates vary by region). Rates as of 2026-07. Verify at the official pricing page before using for real cost estimates — this list is not kept in sync with AWS pricing changes.

How SQS connects to other services

The useful detail on an SQS edge isn’t the arrow — it’s the direction, the IAM, and the requirement that makes the connection actually work. Design Beaver models each connection, so it knows what a queue can talk to and what that connection needs to be correct.

Lambda
An SQS queue triggers a Lambda function through an event source mapping — Lambda long-polls the queue and invokes the function one batch at a time, deleting messages after a batch succeeds
SQS
Dead-letter queue: a second queue that receives messages the source queue's consumer failed to process more than maxReceiveCount times, so poison messages are set aside for inspection instead of being retried forever

What SQS can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS — a queue is consumed, not a database client or an HTTP origin. Design Beaver flags these instead of letting you draw a diagram that can’t be built.

RDS
SQS is a message queue reached through its own API, not a database client — a queue never opens a connection to RDS. Put a consumer (Lambda or an app on EC2) between the queue and the database.
DynamoDB
No direct integration — a queue doesn't read or write a database itself. A consumer polls the queue and then talks to DynamoDB.
S3
S3 can *notify* a queue about object events (S3 → SQS), but a queue never originates a connection to S3 — there's no SQS → S3 relationship to draw.
CloudFront
SQS is not an HTTP content origin — CloudFront caches content from origins like S3, ALB, or API Gateway, never a message queue.
Route 53
A queue has no DNS-addressable hostname a Route 53 record would point at — it's reached through the SQS API, not a domain name.
SNS
A queue is consumed, not a publisher — it doesn't push messages to an SNS topic. The relationship runs the other way: SNS fans out TO a subscribed SQS queue.

Anti-patterns Design Beaver catches

These are the SQS mistakes that pass a diagram review but bite later — the ones the validation engine flags as you draw.

Using an SQS queue with no dead-letter queue configured

Why it breaksA message that always fails to process is retried until it expires, wasting consumer invocations and hiding the failure — there's nowhere to inspect what went wrong

Do this insteadAttach a dead-letter queue with a redrive policy (maxReceiveCount ~5) so repeatedly-failing messages are set aside for debugging

Reaching for a FIFO queue by default

Why it breaksFIFO trades most of standard's throughput for strict ordering and de-duplication that many workloads don't actually need

Do this insteadUse a standard queue unless ordering or exactly-once within a message group is a genuine requirement

Using SQS to fan one event out to several independent subscribers

Why it breaksA message on a queue is consumed once by one consumer group — a second subscriber can't also read it

Do this insteadPublish to SNS (or EventBridge) and subscribe multiple SQS queues/consumers to it for fan-out

Gotchas that bite in production

No dead-letter queue is the classic mistake. A message that always fails is retried until it expires — wasting consumer invocations and hiding the failure, with nowhere to inspect what went wrong. Attach a dead-letter queue with a redrive policy (maxReceiveCount around 5), in the same account and Region as the source queue.
Visibility timeout vs consumer runtime. While a consumer holds a message it’s hidden for the visibility timeout. If that timeout is shorter than how long processing takes, the message reappears and gets processed twice. Set the timeout comfortably above the consumer’s max runtime.
Standard queues can deliver twice. At-least-once delivery means duplicates happen — make consumers idempotent rather than assuming exactly-once.
FIFO is not a free upgrade. It caps throughput hard compared to standard. Only pay that cost when you actually need ordering or de-duplication.

Frequently asked questions

When should you use Amazon SQS?

Use SQS when work can happen asynchronously — the caller doesn't need the result in the same request — and you want a durable buffer between two components so one can fail or scale independently of the other. It's a good fit for decoupling a request from slow work, buffering bursty traffic, and fanning work out to a pool of workers. It's the wrong tool when you need pub/sub fan-out to many independent subscribers (that's SNS), a synchronous response in the same request, or event routing across many event types and targets (that's EventBridge).

How does SQS connect to Lambda?

An SQS queue triggers a Lambda function through an event source mapping — Lambda long-polls the queue and invokes your function one batch at a time, deleting messages after a batch succeeds. Configure a dead-letter queue with a redrive policy (maxReceiveCount around 5) so repeatedly-failing messages are set aside, and set the queue's visibility timeout comfortably above the function's timeout so a slow invocation doesn't let the same message get processed twice.

What is the difference between a standard and a FIFO SQS queue?

A standard queue gives you nearly unlimited throughput with at-least-once delivery and best-effort ordering — it's the default and fits the large majority of workloads, though you should make consumers idempotent since a message can occasionally arrive twice. A FIFO queue gives strict first-in-first-out order and exactly-once processing within a message group, at much lower throughput. Reach for FIFO only when ordering or de-duplication is a genuine requirement.

Can an SQS queue connect to a database like RDS or DynamoDB?

No. SQS is a message queue reached through its own API, not a database client — a queue never opens a connection to RDS or DynamoDB. Put a consumer (a Lambda or an app on EC2) between the queue and the database; the consumer polls the queue and then talks to the database. Design Beaver flags a direct SQS → RDS or SQS → DynamoDB edge as invalid.

How much does Amazon SQS cost?

SQS bills per request — every send, receive, and delete API call is a request, and a single receive can return up to 10 messages. FIFO requests cost more than standard, and there's an always-free request tier each month. Long polling and batching (up to 10 messages per call) are the main levers that cut the request count driving your bill. Verify the current figures and rates on the official pricing page before estimating a real bill.