Amazon SQS: What It Is and When to Use It

Definition

Amazon Simple Queue Service (Amazon SQS) is AWS's fully managed message queuing service that decouples and scales distributed systems and serverless applications. Producers send messages to a queue; consumers pull messages and process them. SQS stores messages durably across multiple Availability Zones, handles back-pressure by buffering, and lets components of your system run and scale independently without being tightly coupled to each other.

How It Works

A message lifecycle:

1. SendMessage — the producer posts a message (up to 256 KB 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 messages/second per API (3,000 with batching); high-throughput mode raises this to 3,000/s (30,000 with batching) when enabled.
• Identified by the .fifo suffix on the queue name.

Key Features and Limits

• Message size: up to 256 KB. For larger payloads, store the body in S3 and send a pointer (via the SQS Extended Client Library).
• Retention: 1 minute to 14 days (default 4 days).
• Visibility timeout: 0 seconds to 12 hours (default 30 seconds). Should be longer than the maximum processing time.
• Long polling: wait up to 20 seconds for messages before returning, reducing empty receives and cost.
• Delay queues: delay the visibility of new messages up to 15 minutes.
• Message timers: per-message delay up to 15 minutes.
• 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.

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.
• 256 KB message size limit — large 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.

Comparison with Alternatives

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

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, but throughput is capped (300 msg/s per API, or 3,000 with batching, or up to 30,000 with batching in high-throughput mode). Use FIFO when ordering or exactly-once semantics matter more than raw scale.

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.

---

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.