What Is Amazon SQS? AWS's Managed Message Queue Service

Definition

Amazon Simple Queue Service (Amazon SQS) is AWS's fully managed message queue service. One component of your system (a producer) writes a message to a queue; another component (a consumer) polls the queue, processes the message, and deletes it. Neither has to know the other exists, be online at the same time, or run at the same speed.

That indirection is the whole point. SQS stores every message redundantly across multiple Availability Zones, absorbs traffic spikes by buffering them, and lets each side scale independently — so a slow database or a crashed worker slows the queue down instead of taking the front end down with it. There are no brokers, clusters, or capacity to manage: you create a queue and start sending.

SQS comes in two flavours — Standard queues (near-unlimited throughput, at-least-once delivery, best-effort ordering) and FIFO queues (strict ordering and exactly-once processing at lower throughput). The rest of this page covers how messages flow, the quotas that actually bite in production, what it costs, and how SQS differs from SNS, EventBridge, and Kinesis.

How It Works

A message lifecycle:

1. SendMessage — the producer posts a message (up to 1 MiB of body text + attributes) to the queue via the SQS API.
2. ReceiveMessage — a consumer long-polls the queue. SQS hands out messages and sets a visibility timeout during which the message is hidden from other consumers.
3. DeleteMessage — after successful processing, the consumer deletes the message by its receipt handle. If the visibility timeout elapses without a delete, the message becomes visible again and can be re-processed.
4. Dead-letter queue (DLQ) — after maxReceiveCount attempts, unprocessable messages can be routed to a DLQ for manual inspection.

SQS does not push to consumers — it's poll-based. For push/pub-sub semantics, pair SQS with Amazon SNS or Amazon EventBridge.

Queue Types

Standard queue

• Nearly unlimited throughput — no practical upper limit on messages per second.
• At-least-once delivery — messages may occasionally be delivered more than once.
• Best-effort ordering — messages usually arrive in send order, but not guaranteed.
• Default choice unless you need strict ordering or exactly-once semantics.

FIFO queue

• Strict ordering within a message group — messages with the same MessageGroupId are processed in order.
• Exactly-once processing — 5-minute deduplication window removes duplicates.
• Throughput: 300 transactions/second per API action per partition (3,000 messages/s with 10-message batching). High-throughput mode raises this substantially — up to 70,000 TPS (700,000 messages/s batched) in US East (N. Virginia), US West (Oregon), and Europe (Ireland), with lower ceilings in other Regions.
• Identified by the .fifo suffix on the queue name.

SQS Quotas and Limits

These are the numbers that actually shape a design. All are per-queue unless noted.

| Quota | Value | | --- | --- | | Maximum message size | 1 MiB (1,048,576 bytes) | | Minimum message size | 1 byte | | Message attributes | 10 per message | | Messages per batch request | 10 | | Message retention | 60 seconds – 14 days (default 4 days) | | Visibility timeout | 0 seconds – 12 hours (default 30 seconds) | | Long polling wait time | up to 20 seconds | | Delay queues / message timers | up to 15 minutes | | Standard queue throughput | Near-unlimited API calls per second | | FIFO throughput (standard mode) | 300 TPS per action; 3,000 messages/s batched | | FIFO throughput (high-throughput mode) | Up to 70,000 TPS / 700,000 messages/s batched, Region-dependent | | Queue policy | 8,192 bytes, 20 statements, 50 principals |

The 1 MiB message size is a relatively recent increase — SQS was capped at 256 KB for most of its life, and a lot of older material (and a lot of application code) still assumes that. For payloads beyond 1 MiB, store the body in Amazon S3 and send a pointer using the SQS Extended Client Library, which supports payloads up to 2 GB.

Other capabilities worth knowing:

• Dead-letter queues: redirect unprocessable messages after N receive attempts.
• Batch operations: SendMessageBatch / DeleteMessageBatch / ChangeMessageVisibilityBatch reduce API call cost 10×.
• Server-side encryption: via SQS-managed keys (SSE-SQS) or KMS (SSE-KMS).
• Integrations: Lambda event source mapping (auto-polls the queue), Step Functions send_message, EventBridge Pipes, ECS, EC2.
• Redrive: move messages from a DLQ back to the source queue after fixing the bug.
• Fair queues: on Standard queues, supplying a MessageGroupId lets SQS spread delivery across groups so one noisy tenant can't starve the others.

Common Use Cases

1. Decoupling producers and consumers — a web front-end writes jobs to SQS; background workers process them without the front-end waiting.
2. Buffer for bursty workloads — ingest a traffic spike into SQS and let downstream services drain at their own rate.
3. Work distribution — multiple workers pull from one queue for horizontal scaling.
4. Task queues — image resizing, PDF generation, email sending, batch processing.
5. Order-sensitive pipelines — use FIFO queues for financial transactions, per-user event streams, or deployment steps.
6. Retry logic with DLQ — parking messages that repeatedly fail for offline debugging.

Pricing Model

• Standard queue: per million requests. SendMessage / ReceiveMessage / DeleteMessage each count as a request. Long polling up to 20s counts as a single request.
• FIFO queue: per million requests at a higher rate than Standard.
• Batch APIs group up to 10 messages into one billable request — a huge cost optimization at scale.
• Data transfer — standard AWS rates apply for cross-Region or out-of-AWS transfer.
• Payload offloading: S3 storage costs apply when using the Extended Client Library.
• KMS requests: if SSE-KMS is enabled.

The AWS Free Tier includes 1 million requests per month for SQS indefinitely.

Pros and Cons

Pros

• Fully managed, highly durable, automatically scales to any throughput.
• Simple API and model — send, receive, delete.
• Native Lambda integration via event source mapping.
• FIFO queues solve exactly-once and ordering without custom logic.
• Cheap at scale with batching.

Cons

• Pull-based — consumers must poll. For push semantics, use SNS or EventBridge.
• 1 MiB message size limit — larger payloads need offloading to S3.
• No built-in fan-out — a message consumed by one worker is not re-delivered. For fan-out, use SNS → multiple SQS queues.
• FIFO throughput is limited (even in high-throughput mode) vs Standard.
• Standard queues' at-least-once delivery means idempotent consumers are required.

SQS vs SNS vs EventBridge vs Kinesis

AWS has four services people reach for when they need "a queue," and picking the wrong one is the most common design mistake in this space.

| | SQS | SNS | EventBridge | Kinesis Data Streams | | --- | --- | --- | --- | --- | | Pattern | Point-to-point queue | Pub/Sub fan-out | Event bus with filtering | Ordered durable stream | | Delivery | Pull (long-poll) | Push (HTTP, Lambda, SQS, email, SMS) | Push (to rules/targets) | Pull (shard iterator) | | Ordering | Standard: best-effort; FIFO: strict | None | None | Per-shard | | Multiple consumers | One consumer group per queue | Many subscribers | Many rules | Many independent consumers with checkpointing | | Retention | 1 min – 14 days | None (fire-and-forget) | Fire-and-forget (archive optional) | 1 – 365 days | | Best for | Work queues, buffering | One-to-many notifications | Event-driven routing with rich filters | Replay, ordered analytics |

Pattern: SNS → SQS fan-out is the classic way to get both pub/sub and durable buffering. EventBridge is a newer, more flexible alternative when you need content-based routing or SaaS integrations.

Exam Relevance

• Cloud Practitioner (CLF-C02) — what SQS is and that it decouples components.
• Solutions Architect Associate (SAA-C03) — Standard vs FIFO, visibility timeout, DLQ, SNS + SQS fan-out, SQS as Lambda source, when to pick SQS vs SNS vs EventBridge vs Kinesis.
• Developer Associate (DVA-C02) — heavy coverage: long polling, message batching, dead-letter queues, visibility-timeout tuning, KMS encryption, Extended Client Library for large payloads, FIFO deduplication.
• DevOps Professional (DOP-C02) — DLQ redrive, scaling Lambda consumers based on queue depth, at-least-once vs exactly-once trade-offs.

Classic exam trap: SQS Standard is at-least-once — your consumers must be idempotent (safe to process the same message twice). If the scenario demands strict "each order processed exactly once," the answer is either FIFO queue or a deduplication step in the consumer.

Common Pitfalls

• Visibility timeout shorter than processing time. If a job takes 90 seconds but the visibility timeout is the 30-second default, SQS re-delivers the message to another consumer while the first is still working — you get duplicate processing under load. Set the timeout above your worst-case processing time, or extend it mid-flight with ChangeMessageVisibility.
• One poison message re-processing an entire Lambda batch. With a Lambda event source mapping, if any message in a batch fails and you do not enable ReportBatchItemFailures (partial batch response), the whole batch is retried — good messages get re-processed repeatedly. Return the failed message IDs so only they are retried.
• No maxReceiveCount / DLQ. Without a dead-letter queue and a redrive policy, an unprocessable "poison" message loops until it expires (up to 14 days), burning requests and blocking a FIFO message group the entire time.
• Long polling left off. The default short polling returns immediately, so idle consumers hammer the queue with empty receives — more latency and more billable requests. Set ReceiveMessageWaitTimeSeconds to 20.
• FIFO throughput throttled by too few message groups. Ordering is guaranteed per MessageGroupId, and each group is processed serially. Use one constant group ID and you serialize the entire queue; use a high-cardinality key (per-user, per-order) to parallelize while keeping per-entity order.
• Forgetting to delete messages. Receiving is not consuming — if the consumer never calls DeleteMessage, the message reappears after the visibility timeout and is processed forever.

A Worked Pricing Example

Consider a Standard queue handling 50 million messages/month. SQS bills per API request (first 1 million/month free, then ~$0.40 per million):

• Naive — one message per call: SendMessage + ReceiveMessage + DeleteMessage = 3 × 50M = 150M requests. Minus 1M Free Tier → 149M × $0.40/million ≈ $59.60/month.
• Batched — 10 messages per call + long polling: ~5M + 5M + 5M = 15M requests. Minus 1M → 14M × $0.40/million ≈ $5.60/month.

Identical work, ~10× cheaper. Batching (SendMessageBatch / DeleteMessageBatch, and receiving up to 10 messages per poll) plus long polling are by far the biggest SQS cost levers — far more impactful than any architectural change.

Frequently Asked Questions

Q: What is the difference between SQS Standard and FIFO queues?

A: Standard queues offer nearly unlimited throughput with at-least-once delivery and best-effort ordering — occasional duplicates and out-of-order messages are possible, so consumers must be idempotent. FIFO queues guarantee strict ordering within a message group and exactly-once processing via a 5-minute deduplication window, at 300 transactions/second per API action (3,000 messages/s with batching). Enabling high-throughput mode lifts that ceiling dramatically — to 70,000 TPS in the largest Regions — so "FIFO is slow" is much less true than it used to be. Use FIFO when ordering or exactly-once semantics matter more than operational simplicity.

Q: What is a visibility timeout and how should I set it?

A: When a consumer receives a message, SQS hides it for the visibility timeout (default 30 seconds; up to 12 hours). If the consumer deletes the message within that window, it's gone; if not, it reappears. Set the timeout longer than your maximum processing time — too short and you'll re-process messages while the original consumer is still working; too long and failed processing delays redelivery. You can also call ChangeMessageVisibility to extend mid-processing for long jobs.

Q: When should I use SNS + SQS fan-out instead of just SQS?

A: Use SNS + SQS when you need a single event to reach multiple independent consumers (fan-out). The producer publishes to an SNS topic; multiple SQS queues subscribe, each dedicated to one consumer team. Each consumer gets its own durable queue and can process at its own pace. Pure SQS is for point-to-point — one producer, one logical consumer group.

Q: How big can an SQS message be?

A: Up to 1 MiB (1,048,576 bytes) for the message body plus attributes combined. This is an increase over the 256 KB limit that applied for most of the service's history, so treat any source quoting 256 KB — including your own older code and its validation logic — with suspicion. If you need to move more than 1 MiB, use the SQS Extended Client Library: it stores the payload in an S3 bucket and puts a pointer in the message, supporting payloads up to 2 GB.

Q: Is Amazon SQS a push or a pull service?

A: Pull. Consumers call ReceiveMessage to fetch work — SQS never pushes to an endpoint you own. The exception that confuses people is the Lambda event source mapping: Lambda looks push-based, but under the hood the Lambda service polls the queue on your behalf and invokes your function with the batch. If you genuinely need push delivery to arbitrary HTTP endpoints, that is Amazon SNS or EventBridge, not SQS.

Q: How do I stop one bad message from blocking my SQS queue?

A: Attach a dead-letter queue (DLQ) with a redrive policy and set maxReceiveCount (for example 5). After that many failed receive attempts, SQS moves the poison message to the DLQ so the main queue keeps flowing, and you can inspect or replay it later. If a Lambda function consumes the queue, also enable ReportBatchItemFailures so only the failing messages in a batch are retried rather than the whole batch.

Q: How do I reduce Amazon SQS costs?

A: SQS bills per API request, so the two biggest levers are batching and long polling. Send and delete messages in batches of up to 10 (SendMessageBatch / DeleteMessageBatch) and receive up to 10 per poll to cut request counts by roughly 10x. Enable long polling (ReceiveMessageWaitTimeSeconds = 20) to eliminate billable empty receives from idle consumers. Together these often cut a queue's bill by an order of magnitude versus naive one-message-per-call usage.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon SQS documentation before making production decisions.