SQS FIFO

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

AWS SQS FIFO Queue – Ordering & Deduplication

~ Last updated on : ~ jayendrapatil ~ 5 Comments

AWS SQS FIFO Queue

  • SQS FIFO Queue provides enhanced messaging between applications with the additional features
    • FIFO (First-In-First-Out) delivery
      • order in which messages are sent and received is strictly preserved
      • key when the order of operations & events is critical
    • Exactly-once processing
      • a message is delivered once and remains available until consumer processes and deletes it
      • key when duplicates can’t be tolerated.
      • By default, limited to 300 transactions per second (TPS) per API action (SendMessage, ReceiveMessage, DeleteMessage)
      • With batching (up to 10 messages per API call), effective throughput can reach 3,000 messages per second
      • With High Throughput Mode enabled, supports up to 70,000 TPS per API action (700,000 messages/sec with batching) in select regions
  • FIFO queues provide all the capabilities of Standard queues, improve upon, and complement the standard queue.
  • FIFO queues support message groups that allow multiple ordered message groups within a single queue. There is no quota to the number of message groups within a FIFO queue.
  • FIFO Queue name should end with .fifo
  • SQS FIFO supports one or more producers and messages are stored in the order that they were successfully received by SQS.
  • SQS FIFO queues don’t serve messages from the same message group to more than one consumer at a time.
  • FIFO queues support a maximum of 120,000 in-flight messages (increased from 20,000 in Nov 2024). Messages are considered in-flight after being received by a consumer but not yet deleted.
  • Maximum message payload size is 1 MiB (increased from 256 KiB in Aug 2025), applicable to both standard and FIFO queues. For payloads up to 2 GB, use the Extended Client Library with Amazon S3.
  • AWS Lambda supports SQS FIFO as an event source for building event-driven applications with ordered processing.
  • Not all AWS services support FIFO queues as a direct event destination. For example:
    • Amazon S3 Event Notifications (use Amazon EventBridge as an intermediary to route to FIFO queues)
    • Amazon EventBridge Scheduler Dead-Letter Queues

High Throughput Mode for FIFO Queues

  • High throughput mode increases the transaction limit significantly beyond the default 300 TPS.
  • Supports up to 70,000 transactions per second per API action in select regions (US East N. Virginia, US West Oregon, Europe Ireland).
  • With batching, this translates to up to 700,000 messages per second.
  • Enabling high throughput mode requires two configuration changes:
    • Deduplication scope – Set to Message group (deduplication occurs at the message group level instead of queue level)
    • FIFO throughput limit – Set to Per message group ID (throughput quota applies per message group rather than per queue)
  • If either setting is changed from the required configuration, normal throughput (300 TPS) is in effect.
  • Available in all regions where Amazon SQS is available, though maximum throughput quotas vary by region.
  • To achieve maximum throughput, distribute messages across multiple message groups.

Message Deduplication

  • SQS APIs provide deduplication functionality that prevents message producers from sending duplicates.
  • Message deduplication ID is the token used for the deduplication of sent messages.
  • 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.
  • So basically, any duplicates introduced by the message producer are removed within a 5-minute deduplication interval.
  • Message deduplication applies to an entire queue (default), not to individual message groups.
    • With High Throughput Mode enabled, deduplication scope is set to message group level.
  • Content-based deduplication can be enabled on the queue, which uses a SHA-256 hash of the message body to generate the deduplication ID automatically.
  • New FIFO-specific CloudWatch metric NumberOfDeduplicatedSentMessages (added July 2024) tracks the number of messages that were deduplicated.

Message Groups

  • Messages are grouped into distinct, ordered “bundles” within a FIFO queue.
  • Message group ID is the tag that specifies that a message belongs to a specific message group.
  • For each message group ID, all messages are sent and received in strict order.
  • However, messages with different message group ID values might be sent and received out of order.
  • Every message must be associated with a message group ID, without which the action fails.
  • SQS delivers the messages in the order in which they arrive for processing if multiple hosts (or different threads on the same host) send messages with the same message group ID.
  • There is no quota to the number of message groups within a FIFO queue.
  • New FIFO-specific CloudWatch metric ApproximateNumberOfGroupsWithInflightMessages (added July 2024) tracks the approximate number of message groups with in-flight messages.

Dead-Letter Queue (DLQ) Support for FIFO Queues

  • FIFO queues support dead-letter queues. A DLQ for a FIFO queue must also be a FIFO queue.
  • DLQ Redrive for FIFO Queues (launched Nov 2023) allows messages to be moved from a FIFO dead-letter queue back to the source queue or a custom FIFO destination queue.
    • Previously, DLQ redrive was only available for standard queues.
    • Supported via the AWS Console, AWS SDK, and CLI.
    • Available in all commercial regions and AWS GovCloud (US) Regions (April 2024).
  • Configure a redrive policy to specify the maximum number of receives before a message is moved to the DLQ.

SQS Standard Queues vs SQS FIFO Queues

SQS Standard vs 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 restaurant reservation application needs the ability to maintain a waiting list. When a customer tries to reserve a table, and none are available, the customer must be put on the waiting list, and the application must notify the customer when a table becomes free. What service should the Solutions Architect recommend to ensure that the system respects the order in which the customer requests are put onto the waiting list?
    1. Amazon SNS
    2. AWS Lambda with sequential dispatch
    3. A FIFO queue in Amazon SQS
    4. A standard queue in Amazon SQS
  2. In relation to Amazon SQS, how can you ensure that messages are delivered in order? Select 2 answers
    1. Increase the size of your queue
    2. Send them with a timestamp
    3. Using FIFO queues
    4. Give each message a unique id
    5. Use sequence number within the messages with Standard queues
  3. A company has run a major auction platform where people buy and sell a wide range of products. The platform requires that transactions from buyers and sellers get processed in exactly the order received. At the moment, the platform is implemented using RabbitMQ, which is a light weighted queue system. The company consulted you to migrate the on-premise platform to AWS. How should you design the migration plan? (Select TWO)
    1. When the bids are received, send the bids to an SQS FIFO queue before they are processed.
    2. When the users have submitted the bids from frontend, the backend service delivers the messages to an SQS standard queue.
    3. Add a message group ID to the messages before they are sent to the SQS queue so that the message processing is in a strict order.
    4. Use an EC2 or Lambda to add a deduplication ID to the messages before the messages are sent to the SQS queue to ensure that bids are processed in the right order.
  4. A company needs to process financial transactions with exactly-once semantics and strict ordering. The system currently handles 500 transactions per second and is expected to grow to 5,000 TPS. Which SQS FIFO configuration should the solutions architect recommend?
    1. Use a standard SQS queue with application-level deduplication
    2. Enable high throughput mode on the FIFO queue with deduplication scope set to message group and distribute transactions across multiple message groups
    3. Use multiple standard queues with sequence numbers
    4. Use a single FIFO queue with default settings and request a quota increase
  5. An application uses an SQS FIFO queue and frequently encounters messages that cannot be processed successfully. The development team needs a mechanism to isolate failed messages for analysis and then reprocess them after fixing the underlying issue. What is the most operationally efficient approach?
    1. Implement application logic to move failed messages to a separate standard queue
    2. Delete failed messages and log them to CloudWatch for later replay
    3. Configure a FIFO dead-letter queue with a redrive policy, then use DLQ redrive to move messages back to the source queue after fixing the issue
    4. Use a Lambda function to periodically check and reprocess failed messages
  6. A solutions architect is designing a system that processes messages from an SQS FIFO queue using AWS Lambda. The system needs to handle partial failures within a batch without blocking the entire message group. Which approach should the architect implement?
    1. Configure the Lambda function with a batch size of 1 to process messages individually
    2. Enable ReportBatchItemFailures in the Lambda event source mapping and implement partial batch response handling in the function code
    3. Use a standard queue instead of FIFO to avoid message group blocking
    4. Set a very short visibility timeout to quickly retry failed messages

References