Cargando...
Cargando...
Choose the right queue type the first time — throughput vs. order, and everything in between
Maximum throughput vs. guaranteed order — pick your priority
| Feature | SQS Standard Unlimited throughput, best-effort ordering | SQS FIFO Strict order, exactly-once processing |
|---|---|---|
Message Ordering FIFO ordering is scoped to a Message Group ID, not the entire queue. Different groups can be processed in parallel. | Best-effort ordering — messages may arrive out of order | Strict First-In-First-Out ordering guaranteed within a message group |
Delivery Guarantee At-least-once in Standard means your consumers MUST be idempotent. FIFO removes that burden but at a throughput cost. | At-least-once delivery — duplicates are possible | Exactly-once processing — duplicates are eliminated within a 5-minute deduplication window |
Throughput FIFO with batching: 3,000 msg/sec is the ceiling. Standard scales to meet virtually any workload. This is the #1 reason to choose Standard over FIFO. | Nearly unlimited — supports a very high number of API calls per second | 300 API calls/second without batching; up to 3,000 messages/second with batching (10 messages per batch) |
Queue Name Suffix Requirement A queue without .fifo suffix cannot be a FIFO queue — this is a hard requirement, not optional. | No naming constraint | Queue name MUST end with .fifo (e.g., my-orders.fifo) |
Message Deduplication Content-based deduplication uses SHA-256 hash of the message body. If enabled, you don't need to provide a MessageDeduplicationId. | Not supported — consumers must handle duplicates themselves | Supported via Deduplication ID (content-based or explicit); 5-minute deduplication interval |
Message Group ID Using a single Message Group ID = single-threaded processing of the entire queue. Using many groups = parallelism within FIFO. | Not applicable | Required — groups related messages that must be processed in order; enables parallel processing across groups |
Dead Letter Queue (DLQ) Support Mixing queue types for DLQ (e.g., Standard queue as DLQ for a FIFO queue) is NOT allowed. Type must match. | Supported — DLQ must also be a Standard queue | Supported — DLQ must also be a FIFO queue (with .fifo suffix) |
Visibility Timeout Same for both. If processing takes longer than visibility timeout, the message becomes visible again and can be re-processed — a common source of duplicates in Standard queues. | 0 seconds to 12 hours (default: 30 seconds) | 0 seconds to 12 hours (default: 30 seconds) |
Message Retention Period Same for both queue types. Messages not processed within retention period are deleted automatically. | 60 seconds to 14 days (default: 4 days) | 60 seconds to 14 days (default: 4 days) |
Maximum Message Size Use SQS Extended Client Library with S3 for payloads larger than 256 KB — works with both queue types. | Up to 256 KB per message | Up to 256 KB per message |
Long Polling (Receive Wait Time) Long polling (>0 seconds) reduces empty responses and cost. Short polling (0 seconds) is wasteful. Always prefer long polling in production. | 0–20 seconds | 0–20 seconds |
Delay Queue / Message Timers FIFO queues do NOT support per-message delay timers — only queue-level delays. This is a commonly tested gotcha. | Queue-level delay: 0–15 minutes; per-message delay timers supported | Queue-level delay: 0–15 minutes; per-message delay timers NOT supported |
Amazon SNS Fanout Compatibility SNS FIFO → SQS FIFO is supported. SNS Standard → SQS FIFO is NOT. Both topic and queue must be FIFO for ordering guarantees end-to-end. | Fully supported — SNS can fan out to Standard SQS queues | Supported only with SNS FIFO topics — SNS Standard topics cannot deliver to FIFO queues |
Lambda Trigger (Event Source Mapping) With FIFO + Lambda, if one message in a group fails, Lambda stops processing that group until resolved — preserving order but potentially blocking. | Supported — Lambda polls and processes in batches | Supported — Lambda processes one Message Group at a time to preserve order |
Pricing Model FIFO queues cost more per API call. Factor this into high-volume workload cost analysis on exam scenarios. | Pay per API request; first 1 million requests/month free | Pay per API request; approximately 50% more expensive than Standard per request; first 1 million requests/month free |
Supported AWS Regions Standard has broader regional availability. For global architectures, always confirm FIFO availability in target regions. | Available in all AWS regions | Available in most AWS regions — verify availability for specific regions before designing architecture |
Batch Operations Batching is how FIFO achieves its higher throughput ceiling of 3,000 msg/sec. Without batching, FIFO is capped at 300 msg/sec. | Up to 10 messages per batch (Send, Receive, Delete) | Up to 10 messages per batch (Send, Receive, Delete) |
Use Case Fit Exam scenarios will describe the business need — map 'order matters' or 'no duplicates' to FIFO; map 'massive scale' or 'loose coupling' to Standard. | High-throughput workloads, image processing pipelines, log aggregation, decoupling microservices where order isn't critical | Financial transactions, order management systems, inventory updates, any workflow where sequence and exactly-once matter |
Summary
SQS Standard is your go-to for maximum throughput and loose coupling where occasional duplicates or out-of-order delivery are acceptable — your application handles idempotency. SQS FIFO is purpose-built for workflows where message sequence and exactly-once processing are business requirements, accepting a throughput ceiling in exchange for those guarantees. The decision almost always comes down to one question: does the business logic break if messages arrive out of order or more than once?
🎯 Decision Tree
IF order matters OR duplicates are unacceptable → use FIFO | IF throughput > 3,000 msg/sec is required → use Standard (FIFO cannot scale beyond this) | IF cost is a primary constraint at high volume → use Standard | IF integrating with SNS for fanout AND order matters → use SNS FIFO + SQS FIFO | IF per-message delay timers are needed → use Standard | IF neither ordering nor deduplication is required → use Standard for simplicity and scale
FIFO throughput ceiling is 300 API calls/sec (unbatched) or 3,000 messages/sec (batched at 10 msg/batch). If a scenario requires higher throughput AND ordering, there is no native SQS solution — this is a deliberate architectural constraint. Any answer suggesting FIFO can scale beyond 3,000 msg/sec is wrong.
Standard queues guarantee at-least-once delivery — duplicates WILL occur. Your application must be idempotent when using Standard. FIFO queues guarantee exactly-once processing within the 5-minute deduplication window. On any exam question mentioning 'financial transactions,' 'order processing,' or 'no duplicates,' FIFO is almost always the correct answer.
FIFO queues do NOT support per-message delay timers — only queue-level delays. Standard queues support both. If a scenario requires individual messages to have different delay values, Standard is the only option regardless of ordering requirements.
A Dead Letter Queue must be the same type as its source queue. FIFO source → FIFO DLQ (with .fifo suffix). Standard source → Standard DLQ. Mixing types is invalid and will appear as a distractor in architecture questions.
For SNS fanout to SQS FIFO queues, the SNS topic must also be a FIFO topic. You cannot subscribe an SQS FIFO queue to a Standard SNS topic. Exam questions about 'pub/sub with ordering guarantees' require SNS FIFO + SQS FIFO — both layers must be FIFO.
Long polling (ReceiveMessage with WaitTimeSeconds > 0, max 20 seconds) reduces empty responses and API costs. Short polling (WaitTimeSeconds = 0) is the default but wasteful. Exam scenarios about reducing SQS costs or empty receives point to enabling long polling.
You cannot convert an existing Standard queue to FIFO or vice versa. If an architecture needs to migrate from Standard to FIFO, a new queue must be created and the application must be updated. This is a hard AWS constraint — not a permissions issue.
When Lambda is triggered by a FIFO queue, it processes one Message Group ID at a time to preserve order. If processing fails for a message in a group, that group is blocked until resolved. This can cause head-of-line blocking — an important consideration for FIFO + Lambda architectures.
The #1 exam trap: candidates assume FIFO queues can scale to the same throughput as Standard queues given enough resources — they cannot. FIFO is hard-capped at 3,000 messages/second with batching. Additionally, many candidates incorrectly believe Standard queues guarantee exactly-once delivery or that FIFO queues support per-message delay timers — both are false. Always map the business requirement first: if the scenario says 'high throughput' without mentioning order, Standard wins; if it says 'financial transactions' or 'must not process duplicates,' FIFO wins.
CertAI Tutor · · 2026-02-22
Services
Comparisons