What limits throughput on a default SQS FIFO queue, and what do the DeduplicationScope and FifoThroughputLimit attributes change?

## Where the ceiling comes from Ordering costs coordination, and FIFO queues expose that cost as a request quota rather than as latency. As of 2025 a FIFO queue in the default configuration is limited to 300 transactions per second **per API action**: 300 `SendMessage` calls, 300 `ReceiveMessage` calls and 300 `DeleteMessage` calls per second. Because a batch call carries up to ten messages, batching turns that into roughly 3,000 messages per second in each direction. Standard queues publish no equivalent inbound ceiling, which is the practical difference that bites teams who adopted FIFO for a small stream and then grew into it. When a FIFO producer starts seeing throttling, the cause is almost always this quota rather than anything about consumer capacity. ## What high throughput mode is High throughput mode is not a single toggle; it is two attributes that must be set together on the queue: ```bash aws sqs set-queue-attributes --queue-url "$QUEUE_URL" \ --attributes DeduplicationScope=messageGroup,FifoThroughputLimit=perMessageGroupId ``` `FifoThroughputLimit` takes `perQueue` (the default) or `perMessageGroupId`. `DeduplicationScope` takes `queue` (the default) or `messageGroup`. AWS only permits the high-throughput combination — per-group throughput requires per-group deduplication scope — so setting one without the other is rejected. With both set, the throughput quota applies **per message group** instead of per queue, and the aggregate ceiling rises by orders of magnitude. The exact published figure varies by Region and has been revised upward repeatedly, so quote the shape of the limit rather than a number: it is high enough that group cardinality, not the quota, becomes your constraint. ## The catch: dedup scope moves with it The two attributes are coupled for a reason. In the default mode, SQS maintains one deduplication space for the whole queue, so a repeated `MessageDeduplicationId` is caught no matter which group it lands in. Tracking that space queue-wide is precisely what limits throughput. Switching to `messageGroup` scope means the id is only compared against other sends in the same group. If a producer bug sends the same logical event under two group ids, both are accepted and both are delivered. In practice this is usually harmless, because a well-chosen group key is derived from the same entity as the dedup id — all events for `cust-42` carry group `cust-42`, so retries land in the same group. It becomes a real hazard when the group key is derived from something volatile, like a shard number or a hostname, that can change between the original send and the retry. ## Group cardinality still governs High throughput mode does not remove the one-in-flight-per-group rule. A group is still a serial lane; the change is that the quota no longer counts against a single queue-wide budget. So the scaling story is unchanged in shape: throughput comes from having many concurrently active groups. A queue with three group ids will not benefit from high throughput mode, because three serial lanes were never near 3,000 messages per second anyway. A queue with tens of thousands of entity-keyed groups benefits enormously. If you enable the mode and see no improvement, the group key is the thing to examine, not the setting. ## Cheaper levers first Before reaching for the mode, check the obvious ones. Batching with `SendMessageBatch` and `DeleteMessageBatch` gives a tenfold multiplier on the same quota and reduces cost, since FIFO requests are billed at a higher rate than standard. Long polling reduces wasted receive calls that consume quota while returning nothing. And it is worth re-asking whether the whole stream needs to be ordered: splitting traffic so that only the order-sensitive subset goes to the FIFO queue, with the rest on a standard queue, is frequently the largest win available and removes the ceiling from most of the volume. ## Operationally Both attributes are set with `SetQueueAttributes` on an existing queue, so this is not a migration — no new queue, no producer changes, no drain window. That makes it a reasonable response to sustained throttling, provided you have first confirmed that duplicate sends cannot cross group boundaries in your producer.