SQS Dead Letter queue

SQS Standard vs FIFO Queue – Complete Comparison

~ Last updated on : ~ Kiro Agent

AWS SQS Standard vs FIFO Queue – Differences & Use Cases

Amazon Simple Queue Service (SQS) offers two queue types — Standard and FIFO (First-In-First-Out) — each designed for different messaging requirements. Choosing the wrong queue type leads to either unnecessary complexity or data integrity issues. This comprehensive comparison covers every dimension: ordering, deduplication, throughput, pricing, delivery guarantees, and real-world use cases to help you make the right choice.

🎯 Quick Decision Rule:

  • Need maximum throughput, can handle duplicates & out-of-order? → Standard Queue
  • Need strict ordering & exactly-once processing? → FIFO Queue
  • Need strict ordering AND high throughput (70K+ TPS)? → FIFO Queue with High Throughput Mode
SQS Standard vs FIFO — Message Flow
Standard Queue
Producer → Msg A, B, C
↓ Best-effort ordering
Queue
∞ throughput
↓ At-least-once
Consumer → B, A, C, A
(possible duplicates & reorder)
FIFO Queue (.fifo)
Producer → Msg A, B, C
↓ Strict ordering
Queue
3,000 msg/s (batch)
↓ Exactly-once
Consumer → A, B, C
(guaranteed order, no duplicates)

SQS Standard vs FIFO – Detailed Comparison Table

Feature Standard Queue FIFO Queue
Message Ordering Best-effort ordering; messages may arrive out of order Strict first-in-first-out ordering within each message group
Delivery Guarantee At-least-once delivery; duplicates possible Exactly-once processing; no duplicates within 5-minute deduplication window
Throughput (Default) Nearly unlimited TPS 300 TPS per API action (3,000 msg/sec with batching)
Throughput (High Throughput Mode) N/A – already unlimited Up to 70,000 TPS per API action (700,000 msg/sec with batching) in select regions
Deduplication No built-in deduplication; application must handle idempotency Built-in 5-minute deduplication via MessageDeduplicationId or content-based deduplication (SHA-256 hash)
Message Groups Optional (Fair Queue feature); not required Required MessageGroupId; ordering guaranteed within each group
In-Flight Messages ~120,000 messages 120,000 messages (increased from 20,000 in Nov 2024)
Pricing (US East) $0.40 per million requests (first 100B); tiered pricing down to $0.24/million $0.50 per million requests (first 100B); tiered pricing down to $0.35/million
Free Tier 1 million requests/month free 1 million requests/month free (separate from Standard free tier)
Batching Up to 10 messages per batch (max 256 KB total payload) Up to 10 messages per batch (max 256 KB total payload); multiplies effective throughput 10x
Dead-Letter Queue (DLQ) Supported; DLQ must be a Standard queue; redrive to source supported Supported; DLQ must be a FIFO queue; redrive to source supported (since Nov 2023)
Queue Name Any valid name (up to 80 characters) Must end with .fifo suffix
Message Retention 1 minute to 14 days (default 4 days) 1 minute to 14 days (default 4 days)
Per-Message Delay Supported (0–900 seconds per message) Not supported per-message; only queue-level delay
AWS Service Integration All AWS services (S3 events, SNS, Lambda, etc.) SNS FIFO, Lambda, EventBridge; S3 Event Notifications NOT directly supported
Visibility Timeout 0 seconds to 12 hours (default 30 seconds) 0 seconds to 12 hours (default 30 seconds)
Long Polling Supported (1–20 seconds) Supported (1–20 seconds)

Message Ordering

Standard Queue – Best-Effort Ordering

  • Messages are generally delivered in the order they are sent, but this is not guaranteed
  • The highly distributed architecture optimizes for throughput, which may cause occasional out-of-order delivery
  • If ordering matters, the application must include sequence information in the message body and handle reordering at the consumer level

FIFO Queue – Strict Ordering

  • Messages are delivered in exactly the order they are sent within a message group
  • MessageGroupId is required — messages with the same group ID are delivered in strict FIFO order
  • Different message groups can be processed in parallel by different consumers, enabling concurrent processing while maintaining per-group ordering
  • Only one consumer can process messages from a given message group at a time (until the message is deleted or the visibility timeout expires)

Deduplication

Standard Queue – No Built-in Deduplication

  • At-least-once delivery means the same message may be delivered more than once
  • Applications must implement idempotent consumers — processing the same message twice should produce the same result
  • Common patterns: use a unique message identifier stored in DynamoDB or a database to track processed messages

FIFO Queue – Built-in Deduplication

  • Provides exactly-once processing within a 5-minute deduplication interval
  • Two deduplication mechanisms:
    • Content-based deduplication — Enable on the queue; SQS generates a SHA-256 hash of the message body as the deduplication ID. Messages with identical bodies within 5 minutes are treated as duplicates.
    • MessageDeduplicationId — Explicitly provide a unique token per message. If a message with the same deduplication ID is sent within 5 minutes, it is accepted but not delivered again.
  • If both are configured, the explicit MessageDeduplicationId takes precedence over content-based deduplication
  • After the 5-minute window expires, sending the same message again is treated as a new message

Throughput & Scaling

Standard Queue

  • Nearly unlimited throughput — supports unlimited TPS for SendMessage, ReceiveMessage, and DeleteMessage
  • Can handle any spike without pre-provisioning or configuration changes
  • Ideal for applications with unpredictable or extremely high message volumes

FIFO Queue

  • Default mode: 300 TPS per API action (SendMessage, ReceiveMessage, DeleteMessage)
  • With batching (10 messages/request): effectively 3,000 messages/second
  • High Throughput Mode (enable via SQS console or API):
    • Up to 70,000 TPS per API action without batching in US East (N. Virginia), US West (Oregon), and Europe (Ireland)
    • Up to 700,000 messages/second with batching in those regions
    • Up to 18,000 TPS in other supported regions
    • Uses message group-level partitioning — distribute messages across multiple message group IDs for maximum throughput
  • In-flight message limit: 120,000 messages (increased from 20,000 in November 2024)
⚡ Throughput Tip: To maximize FIFO throughput, use unique MessageGroupId values for messages that don’t require relative ordering. Each message group is processed independently, enabling parallel processing across groups.

Pricing

Monthly Requests Standard (per million) FIFO (per million)
First 1 million Free Free
1M – 100 Billion $0.40 $0.50
100B – 200 Billion $0.30 $0.40
Over 200 Billion $0.24 $0.35
  • FIFO queues cost approximately 25% more than Standard queues at every tier
  • Each 64 KB chunk of payload counts as one request (a 256 KB message = 4 requests)
  • Batch operations (up to 10 messages) count as a single request — use batching to reduce costs
  • No additional cost for enabling High Throughput Mode on FIFO queues
  • AWS KMS encryption adds KMS API call charges (if server-side encryption is enabled)

Delivery Guarantees

Standard Queue – At-Least-Once Delivery

  • A message is delivered at least once, but occasionally more than once
  • Duplicate delivery occurs because SQS stores messages redundantly across multiple servers for high availability
  • Applications must be designed to handle duplicates gracefully (idempotent processing)
  • Best suited when occasional duplicates are acceptable and throughput is the priority

FIFO Queue – Exactly-Once Processing

  • Each message is delivered exactly once and remains available until processed and deleted
  • SQS uses the deduplication mechanism to prevent duplicate delivery within the 5-minute window
  • If a consumer receives a message but fails to delete it before the visibility timeout, the message becomes available again to the same or another consumer — but only within the same message group ordering constraints
  • Best suited when duplicate processing would cause business logic errors (financial transactions, order processing)

Batching

  • Both queue types support batch operations: SendMessageBatch, ReceiveMessage (up to 10 messages), and DeleteMessageBatch
  • Maximum total payload per batch: 256 KB
  • A single batch API call counts as one request for billing purposes — batching reduces cost by up to 10x
  • Standard queues: Batching is purely a cost optimization; throughput is already unlimited
  • FIFO queues: Batching is critical for throughput — it effectively multiplies the TPS limit by 10 (e.g., 300 TPS → 3,000 messages/sec; 70,000 TPS → 700,000 messages/sec)
  • Note: FIFO queues are NOT compatible with the SQS Buffered Asynchronous Client (which batches messages client-side). Use the standard SDK SendMessageBatch API instead.

Dead-Letter Queues (DLQ)

  • Both Standard and FIFO queues support DLQs for isolating messages that fail processing
  • Configure maxReceiveCount (1–1,000) — after this many receives without deletion, the message moves to the DLQ
  • DLQ must match the source queue type: Standard queue → Standard DLQ; FIFO queue → FIFO DLQ
  • DLQ redrive to source (moving messages back to the original queue) is supported for both types
  • FIFO DLQ redrive was launched in November 2023 and expanded to GovCloud in April 2024
  • Messages retain their original message ID when moved to a DLQ, enabling tracking
💡 DLQ Best Practice: Don’t use a DLQ with a FIFO queue if breaking the exact order of messages/operations would cause issues. When a message is moved to the DLQ, subsequent messages in the same group can proceed, potentially breaking the intended sequence.

Use Cases

When to Use Standard Queue

  • High-volume event processing — website clickstream analytics, IoT telemetry ingestion
  • Background job processing — image/video transcoding, report generation, email sending
  • Decoupling microservices — when services need to communicate asynchronously at high throughput
  • Fan-out with SNS — receiving messages from SNS Standard topics at scale
  • Batch data processing — ETL pipelines where order doesn’t matter
  • Buffer for traffic spikes — absorbing burst traffic between web tier and backend services
  • Log aggregation — collecting logs from distributed systems for centralized processing

When to Use FIFO Queue

  • Financial transactions — ensuring debits and credits are processed in sequence
  • E-commerce order processing — order placed → payment → fulfillment must happen in sequence
  • Inventory management — stock updates must be applied in order to maintain accuracy
  • Command execution — ensuring commands are executed in the exact order submitted
  • Price updates — displaying the correct current price by processing changes in order
  • Event sourcing — maintaining event sequence for aggregate reconstruction
  • Ticketing systems — first-come-first-served ticket allocation
  • Registration workflows — ensuring account creation precedes enrollment actions

Decision Guidance – When to Choose Each

Choose Standard Queue when:

  • Your application can tolerate occasional duplicate messages
  • Message order is not critical to business logic
  • You need the highest possible throughput without any limits
  • You’re integrating with AWS services that don’t support FIFO (e.g., S3 event notifications directly)
  • Cost optimization is a priority (25% cheaper than FIFO)
  • Your consumer is already idempotent
Choose FIFO Queue when:

  • Message ordering is critical to correctness (financial, ordering, sequential workflows)
  • Duplicate processing would cause data corruption or business logic errors
  • You need exactly-once semantics without building custom deduplication logic
  • Throughput requirements are within FIFO limits (up to 70K TPS with High Throughput Mode)
  • You can group messages logically using MessageGroupId for parallel processing within ordering constraints

Migration Considerations

  • You cannot convert an existing Standard queue to FIFO or vice versa — you must create a new queue
  • FIFO queue names must end with .fifo suffix
  • When migrating from Standard to FIFO, you must add MessageGroupId (required) and either enable content-based deduplication or provide MessageDeduplicationId
  • Test throughput requirements before migrating — ensure FIFO limits (even with High Throughput Mode) meet your peak load

AWS Certification Exam Tips (SAA-C03 / DVA-C02)

📝 Key Points for the Exam:

  • FIFO = ordering + exactly-once. Any question mentioning “strict order,” “sequence,” “exactly-once,” or “no duplicates” → FIFO queue.
  • Standard = high throughput + at-least-once. Questions about “unlimited throughput” or “maximum scalability” → Standard queue.
  • MessageGroupId is required for FIFO queues. Messages with the same group ID are ordered; different groups can be processed in parallel.
  • FIFO queue names must end in .fifo — this is a common trick in exam questions.
  • S3 event notifications cannot directly target FIFO queues. Use EventBridge as an intermediary.
  • DLQ must match queue type — Standard DLQ for Standard queue, FIFO DLQ for FIFO queue.
  • High Throughput Mode eliminates the throughput objection — FIFO can now handle 70K+ TPS. Questions about “ordering AND high throughput” → FIFO with High Throughput Mode.
  • Deduplication window is 5 minutes. Content-based deduplication uses SHA-256 hash of message body.
  • Per-message delay is NOT supported in FIFO queues — only queue-level DelaySeconds.
  • DVA-C02 focus: Understand how to implement idempotent consumers for Standard queues and how MessageDeduplicationId works for FIFO queues.

AWS Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

  1. A financial services company processes stock trade orders. Each trade must be processed exactly once and in the precise order it was submitted. The system handles approximately 500 trades per second during peak hours. Which Amazon SQS configuration meets these requirements with the LEAST operational overhead?

    1. Use a Standard queue with application-level deduplication using DynamoDB
    2. Use a Standard queue with message sequencing in the message body
    3. Use a FIFO queue with MessageGroupId set to the stock ticker symbol
    4. Use Amazon Kinesis Data Streams with one shard per stock symbol
    Show Answer

    Answer: c) – FIFO queues provide exactly-once processing and strict ordering within each message group. Using the stock ticker as the MessageGroupId ensures trades for the same stock are processed in order while allowing parallel processing across different stocks. 500 TPS is well within FIFO default limits (300 TPS per group, but distributed across many groups = much higher aggregate).

  2. A developer is building an application that sends S3 event notifications to an SQS queue for ordered processing. The team requires FIFO delivery of these notifications. What should the developer do?

    1. Configure S3 to send events directly to an SQS FIFO queue
    2. Configure S3 to send events to Amazon EventBridge, then create a rule to forward events to an SQS FIFO queue
    3. Configure S3 to send events to an SNS Standard topic, then subscribe the SQS FIFO queue
    4. Configure S3 to send events to a Standard queue and use Lambda to forward them to a FIFO queue
    Show Answer

    Answer: b) – S3 Event Notifications do not support SQS FIFO queues as a direct destination. Amazon EventBridge receives S3 events and can route them to SQS FIFO queues as a rule target, providing the required FIFO delivery with minimal operational overhead.

  3. An e-commerce platform needs to process over 100,000 order update messages per second with strict per-customer ordering. The solutions architect wants to use Amazon SQS. Which approach meets BOTH the throughput and ordering requirements?

    1. Use a Standard queue with application-level ordering per customer
    2. Use multiple FIFO queues with default settings and distribute customers across them
    3. Use a FIFO queue with High Throughput Mode enabled and a unique MessageGroupId per customer
    4. Use Amazon Kinesis Data Streams with customer ID as the partition key
    Show Answer

    Answer: c) – FIFO High Throughput Mode supports up to 70,000 TPS per API action (700,000 messages/sec with batching) in select regions. Using a unique MessageGroupId per customer ensures per-customer ordering while distributing load across message group partitions. With batching of 10 messages per request, 100,000+ messages/second is achievable.

  4. A development team is using an SQS FIFO queue for processing payment events. They notice that after enabling content-based deduplication, some messages with different payment amounts but identical message bodies (due to a serialization bug) are being silently dropped. What is the MOST appropriate fix?

    1. Disable deduplication entirely on the FIFO queue
    2. Switch to a Standard queue to avoid deduplication issues
    3. Provide an explicit MessageDeduplicationId (e.g., a unique payment transaction ID) for each message instead of relying on content-based deduplication
    4. Increase the deduplication interval beyond 5 minutes
    Show Answer

    Answer: c) – Content-based deduplication uses a SHA-256 hash of the message body. If messages have identical bodies (due to a bug), they get the same deduplication ID and are treated as duplicates. Providing an explicit MessageDeduplicationId (like a unique transaction ID) ensures each legitimate message is treated as unique regardless of body content. The deduplication interval cannot be changed from 5 minutes.

  5. A company has a Standard SQS queue receiving 50,000 messages per second. They are experiencing issues with duplicate message processing causing double charges to customers. The team wants to prevent duplicates with minimal code changes. What should they do?

    1. Increase the visibility timeout to prevent reprocessing
    2. Migrate to a FIFO queue with content-based deduplication enabled, using customer account ID as the MessageGroupId
    3. Add a DynamoDB table for deduplication tracking in the consumer application
    4. Enable long polling to reduce duplicate receives
    Show Answer

    Answer: b) – For “minimal code changes” and preventing duplicates, migrating to FIFO with content-based deduplication is the most effective solution. FIFO provides exactly-once processing natively without custom deduplication logic. However, verify that 50,000 TPS is achievable with High Throughput Mode enabled (70K TPS in select regions). Option c is valid but requires more code changes. Option a doesn’t prevent duplicates — it only reduces the window.

Related Posts

Frequently Asked Questions

What is the difference between SQS Standard and FIFO?

SQS Standard offers unlimited throughput with best-effort ordering and at-least-once delivery. FIFO guarantees exact message ordering and exactly-once processing but is limited to 3,000 messages/second with batching (300 without).

When should I use SQS FIFO queue?

Use FIFO when message ordering matters (e.g., financial transactions, e-commerce order processing) or when you need exactly-once processing to prevent duplicate actions. Use Standard for high-throughput workloads where occasional duplicates or out-of-order messages are acceptable.

Can I convert an SQS Standard queue to FIFO?

No, you cannot convert between queue types. You must create a new FIFO queue and migrate your application. FIFO queue names must end with the .fifo suffix.

Related Posts

References

Amazon SQS Features – Visibility, DLQ & Batching

~ Last updated on : ~ jayendrapatil ~ 2 Comments

Amazon SQS Features

  • Visibility timeout defines the period where SQS blocks the visibility of the message and prevents other consuming components from receiving and processing that message.
  • Dead-letter queues – DLQ helps source queues (Standard and FIFO) target messages that can’t be processed (consumed) successfully.
  • DLQ Redrive policy specifies the source queue, the dead-letter queue, and the conditions under which messages are moved from the former to the latter if the consumer of the source queue fails to process a message a specified number of times.
  • DLQ Redrive APIs (StartMessageMoveTask, CancelMessageMoveTask, ListMessageMoveTasks) allow programmatic management of dead-letter queue redrive, enabling messages to be moved from DLQ back to the original source queue or to a custom destination queue.
  • Short and Long polling control how the queues would be polled and Long polling help reduce empty responses.
  • Fair Queues automatically mitigate noisy-neighbor impact in multi-tenant standard queues by prioritizing message delivery for quieter tenants when one tenant creates a backlog.

Queue and Message Identifiers

Queue URLs

  • Queue is identified by a unique queue name within the same AWS account
  • Each queue is assigned with a Queue URL identifier for e.g. http://sqs.us-east-1.amazonaws.com/123456789012/queue2
  • Queue URL is needed to perform any operation on the Queue.

Message ID

  • Message IDs are useful for identifying messages
  • Each message receives a system-assigned message ID that is returned with the SendMessage response.
  • To delete a message, the message’s receipt handle instead of the message ID is needed
  • Message ID can be of is 100 characters max

Receipt Handle

  • When a message is received from a queue, a receipt handle is returned with the message which is associated with the act of receiving the message rather than the message itself.
  • Receipt handle is required, not the message id, to delete a message or to change the message visibility.
  • If a message is received more than once, each time it is received, a different receipt handle is assigned and the latest should be used always.

Message Deduplication ID

  • Message Deduplication ID is used for the deduplication of sent messages.
  • Message Deduplication ID is applicable for FIFO queues.
  • If a message with a particular message deduplication ID is sent successfully, any messages sent with the same message deduplication ID are accepted successfully but aren’t delivered during the 5-minute deduplication interval.

Message Group ID

  • Message Group ID specifies that a message belongs to a specific message group.
  • Message Group ID is applicable for FIFO queues.
  • Messages that belong to the same message group are always processed one by one, in a strict order relative to the message group.
  • However, messages that belong to different message groups might be processed out of order.
  • For Standard queues with Fair Queues enabled, MessageGroupId is used only as a tenant identifier for fair queuing and does not enforce message ordering.

Visibility timeout

Screen Shot 2016-05-05 at 8.17.04 AM.png

  • SQS does not delete the message once it is received by a consumer, because the system is distributed, there’s no guarantee that the consumer will actually receive the message (it’s possible the connection could break or the component could fail before receiving the message)
  • The consumer should explicitly delete the message from the Queue once it is received and successfully processed.
  • As the message is still available in the Queue, other consumers would be able to receive and process and this needs to be prevented.
  • SQS handles the above behavior using Visibility timeout.
  • SQS blocks the visibility of the message for the Visibility timeout period, which is the time during which SQS prevents other consuming components from receiving and processing that message.
  • Consumer should delete the message within the Visibility timeout. If the consumer fails to delete the message before the visibility timeout expires, the message is visible again to other consumers.
  • Once Visible the message is available for other consumers to consume and can lead to duplicate messages.
  • Visibility timeout considerations
    • Clock starts ticking once SQS returns the message
    • should be large enough to take into account the processing time for each message
    • default Visibility timeout for each Queue is 30 seconds and can be changed at the Queue level
    • when receiving messages, a special visibility timeout for the returned messages can be set without changing the overall queue timeout using the receipt handle
    • can be extended by the consumer, using ChangeMessageVisibility , if the consumer thinks it won’t be able to process the message within the current visibility timeout period. SQS restarts the timeout period using the new value.
    • a message’s Visibility timeout extension applies only to that particular receipt of the message and does not affect the timeout for the queue or later receipts of the message
    • Maximum visibility timeout is 12 hours from the time SQS receives the ReceiveMessage request.
  • SQS has a 120,000 limit for the number of inflight messages per queue (both Standard and FIFO queues) i.e. messages received but not yet deleted and any further messages would receive an error after reaching the limit.

Message Lifecycle

Screen Shot 2016-05-05 at 8.16.39 AM.png

  1. Component 1 sends Message A to a queue, and the message is redundantly distributed across the SQS servers.
  2. When Component 2 is ready to process a message, it retrieves messages from the queue, and Message A is returned. While Message A is being processed, it remains in the queue but is not returned to subsequent receive requests for the duration of the visibility timeout.
  3. Component 2 deletes Message A from the queue to avoid the message being received and processed again once the visibility timeout expires.

SQS Dead Letter Queues – DLQ

  • SQS supports dead-letter queues (DLQ), which other queues (source queues – Standard and FIFO) can target for messages that can’t be processed (consumed) successfully.
  • Dead-letter queues are useful for debugging the application or messaging system because DLQ help isolates unconsumed messages to determine why their processing doesn’t succeed.
  • DLQ redrive policy
    • specifies the source queue, the dead-letter queue, and the conditions under which SQS moves messages from the former to the latter if the consumer of the source queue fails to process a message a specified number of times.
    • specifies which source queues can access the dead-letter queue.
    • also helps move the messages back to the source queue.
  • DLQ Redrive APIs
    • StartMessageMoveTask – starts an asynchronous task to move messages from the DLQ to the original source queue or a custom destination queue.
    • CancelMessageMoveTask – cancels a message move task in progress.
    • ListMessageMoveTasks – lists the most recent message move tasks (up to 10) for a specific source queue.
    • Enables programmatic DLQ management via AWS SDK or CLI at scale.
    • FIFO queues also support DLQ redrive.
  • SQS does not create the dead-letter queue automatically. DLQ must first be created before being used.
  • DLQ for the source queue should be of the same type i.e. Dead-letter queue of a FIFO queue must also be a FIFO queue. Similarly, the dead-letter queue of a standard queue must also be a standard queue.
  • DLQ should be in the same account and region as the source queue.

SQS Dead Letter Queue - Redrive Policy

SQS Delay Queues

  • Delay queues help postpone the delivery of new messages to consumers for a number of seconds
  • Messages sent to the delay queue remain invisible to consumers for the duration of the delay period.
  • Minimum delay is 0 seconds (default) and the Maximum is 15 minutes.
  • Delay queues are similar to visibility timeouts as both features make messages unavailable to consumers for a specific period of time.
  • The difference between the two is that, for delay queues, a message is hidden when it is first added to the queue, whereas for visibility timeouts a message is hidden only after it is consumed from the queue.

SQS Fair Queues

  • Fair Queues is a feature of Amazon SQS standard queues that automatically mitigates noisy-neighbor impact in multi-tenant queues.
  • In multi-tenant systems, one tenant can become a “noisy neighbor” by sending a larger volume of messages or requiring longer processing time, creating a backlog that increases message dwell time for all other tenants.
  • Fair Queues detects noisy neighbors by monitoring message distribution among tenants during the in-flight state (messages received by consumers but not yet deleted).
  • When a tenant has a disproportionately large number of in-flight messages, SQS prioritizes message delivery for other (quieter) tenants, reducing dwell time impact.
  • To enable Fair Queues, message producers set a MessageGroupId on outgoing messages as a tenant identifier.
  • MessageGroupId on standard queues with Fair Queues does NOT enforce message ordering (unlike FIFO queues) — it is used only as a tenant identifier.
  • Fair Queues does not limit the consumption rate per tenant — it allows consumers to receive messages from noisy tenants when there is spare consumer capacity.
  • No changes required in consumer code, no impact on API latency, and no throughput limitations.
  • Supports virtually unlimited throughput and unlimited number of tenants.
  • Provides additional CloudWatch metrics:
    • ApproximateNumberOfMessagesVisibleInQuietGroups – backlog for non-noisy tenants
    • ApproximateAgeOfOldestMessageInQuietGroups – oldest message age for quiet groups
  • Best suited for high-throughput multi-tenant queues where dwell time is a quality-of-service metric.

Learn More: Amazon SQS Fair Queues Documentation

Short and Long polling

SQS provides short polling and long polling to receive messages from a queue.

Short Polling

  • ReceiveMessage request queries only a subset of the servers (based on a weighted random distribution) to find messages that are available to include in the response.
  • SQS sends the response right away, even if the query found no messages.
  • By default, queues use short polling.

Long Polling

  • ReceiveMessage request queries all of the servers for messages.
  • SQS sends a response after it collects at least one available message, up to the maximum number of messages specified in the request.
  • SQS sends an empty response only if the polling wait time expires.
  • Wait time greater than 0 triggers long polling with a max of 20 secs.
  • Long polling helps
    • reduce the cost of using SQS by eliminating the number of empty responses (when there are no messages available for a ReceiveMessage request)
    • reduce false empty responses (when messages are available but aren’t included in a response).
    • Return messages as soon as they become available.

SQS Message Size

  • Maximum message payload size is 1 MiB (1,048,576 bytes) for both Standard and FIFO queues. (Increased from 256 KB in August 2025)
  • For messages larger than 1 MiB, use the Amazon SQS Extended Client Library to store the message payload in Amazon S3 and send a reference pointer through SQS.
  • Each message can have up to 10 message attributes (metadata).
  • Message retention period: minimum 60 seconds, default 4 days, maximum 14 days.

SQS Server-Side Encryption (SSE)

  • All SQS queues are encrypted by default using SQS-owned encryption keys (SSE-SQS).
  • SSE-SQS requires no configuration and encrypts all messages at rest at no additional cost.
  • Optionally, queues can be configured with AWS KMS-managed keys (SSE-KMS) for customer-managed encryption keys with more granular access control.
  • With SSE-KMS, only kms:GenerateDataKey permission is needed for SendMessage (kms:Decrypt is no longer required for sending). kms:Decrypt is still required for ReceiveMessage.

SQS FIFO High Throughput

  • FIFO queues by default support 300 transactions per second (TPS) per API action (SendMessage, ReceiveMessage, DeleteMessage).
  • High throughput mode for FIFO queues supports up to 70,000 TPS per API action without batching, and up to 700,000 messages per second with batching in select regions (US East N. Virginia, US West Oregon, Europe Ireland).
  • High throughput mode can be enabled via the Amazon SQS console by setting FifoThroughputLimit to perMessageGroupId and DeduplicationScope to messageGroup.
  • Messages should be distributed across multiple message groups to take advantage of high throughput.

SQS Integration with AWS Lambda

  • SQS can trigger AWS Lambda functions via event source mappings (ESM).
  • Lambda supports both Standard and FIFO queue triggers.
  • Provisioned Mode for SQS ESM (November 2025): Allocates dedicated event polling resources with configurable minimum and maximum limits.
    • Provides 3x faster scaling compared to standard mode.
    • Supports up to 20,000 concurrency (16x higher capacity).
    • Ideal for handling sudden traffic spikes with lower latency processing.
  • The Lambda function and the SQS queue must be in the same AWS Region (but can be in different AWS accounts).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. How does Amazon SQS allow multiple readers to access the same message queue without losing messages or processing them many times?
    1. By identifying a user by his unique id
    2. By using unique cryptography
    3. Amazon SQS queue has a configurable visibility timeout
    4. Multiple readers can’t access the same message queue
  2. If a message is retrieved from a queue in Amazon SQS, how long is the message inaccessible to other users by default?
    1. 0 seconds
    2. 1 hour
    3. 1 day
    4. forever
    5. 30 seconds
  3. When a Simple Queue Service message triggers a task that takes 5 minutes to complete, which process below will result in successful processing of the message and remove it from the queue while minimizing the chances of duplicate processing?
    1. Retrieve the message with an increased visibility timeout, process the message, delete the message from the queue
    2. Retrieve the message with an increased visibility timeout, delete the message from the queue, process the message
    3. Retrieve the message with increased DelaySeconds, process the message, delete the message from the queue
    4. Retrieve the message with increased DelaySeconds, delete the message from the queue, process the message
  4. You need to process long-running jobs once and only once. How might you do this?
    1. Use an SNS queue and set the visibility timeout to long enough for jobs to process.
    2. Use an SQS queue and set the reprocessing timeout to long enough for jobs to process.
    3. Use an SQS queue and set the visibility timeout to long enough for jobs to process.
    4. Use an SNS queue and set the reprocessing timeout to long enough for jobs to process.
  5. You are getting a lot of empty receive requests when using Amazon SQS. This is making a lot of unnecessary network load on your instances. What can you do to reduce this load?
    1. Subscribe your queue to an SNS topic instead.
    2. Use as long of a poll as possible, instead of short polls.
    3. Alter your visibility timeout to be shorter.
    4. Use sqsd on your EC2 instances.
  6. Company B provides an online image recognition service and utilizes SQS to decouple system components for scalability. The SQS consumers poll the imaging queue as often as possible to keep end-to-end throughput as high as possible. However, Company B is realizing that polling in tight loops is burning CPU cycles and increasing costs with empty responses. How can Company B reduce the number of empty responses?
    1. Set the imaging queue visibility Timeout attribute to 20 seconds
    2. Set the Imaging queue ReceiveMessageWaitTimeSeconds attribute to 20 seconds (Long polling. Refer link)
    3. Set the imaging queue MessageRetentionPeriod attribute to 20 seconds
    4. Set the DelaySeconds parameter of a message to 20 seconds
  7. A multi-tenant SaaS application uses a single SQS standard queue shared across all customers. During peak hours, one large customer floods the queue with messages, causing increased dwell time for all other customers. Which SQS feature helps mitigate this noisy neighbor problem?
    1. Enable FIFO queue with message group IDs
    2. Configure visibility timeout to a lower value
    3. Enable Fair Queues by setting MessageGroupId as tenant identifier on standard queue
    4. Create separate DLQs for each customer
  8. A development team needs to programmatically move messages from a dead-letter queue back to the original source queue for reprocessing. Which API action should they use?
    1. SendMessage with the source queue URL
    2. ChangeMessageVisibility on DLQ messages
    3. StartMessageMoveTask
    4. PurgeQueue followed by republishing messages
  9. An application using Amazon SQS FIFO queues needs to process a high volume of ordered messages. What is the maximum throughput achievable with FIFO high throughput mode without batching?
    1. 300 TPS per API action
    2. 3,000 TPS per API action
    3. 18,000 TPS per API action
    4. 70,000 TPS per API action
  10. What is the maximum message payload size supported by Amazon SQS?
    1. 64 KB
    2. 256 KB
    3. 1 MiB (1,048,576 bytes)
    4. 2 MiB