SQS FIFO versus standard: what ordering costs per message

Quick answer

Standard SQS costs $0.40 per million requests, FIFO costs $0.50 per million, a 25 percent premium. At 1 billion messages a month with send, receive, and delete operations, that is $1,200 versus $1,500, a difference of $300. The larger cost is structural: FIFO throughput is limited per message group, so ordering constraints reduce parallelism and can force more consumers, longer processing windows, or a larger number of message groups to manage. Use FIFO only where ordering or deduplication is genuinely required, and where it is, high throughput mode with many message groups keeps the parallelism penalty small.

Ordering guarantees are one of those requirements that get asserted rather than analyzed. Someone says the messages must be processed in order, a FIFO queue goes in, and the design inherits both a price premium and a throughput model that is very different from a standard queue. The premium is small. The throughput model is where the money actually goes.

The direct price difference

Queue type	Rate	1 billion messages, 3 ops each
Standard	$0.40 per million requests	$1,200
FIFO	$0.50 per million requests	$1,500
Standard, batched 10	$0.40 per million requests	$120
FIFO, batched 10	$0.50 per million requests	$150

Note the far bigger lever in that table. Batching reduces request count by up to a factor of 10, since one API call can carry 10 messages, and it applies to both queue types. The $300 difference between standard and FIFO at a billion messages is much less interesting than the $1,080 available from batching. Remember too that payloads are billed in 64 KB chunks, so a 200 KB message counts as 4 requests regardless of type.

Throughput and where it bites

Standard queues offer effectively unlimited throughput. FIFO queues default to 300 transactions per second per API action, or 3,000 messages per second with batching. High throughput mode for FIFO raises this substantially, into the tens of thousands of messages per second per queue in supported regions, but the per-message-group limit remains the governing constraint.

Ordering is guaranteed within a message group, and only one consumer processes a group's messages at a time. If your message group id is the customer id and you have 100,000 customers, parallelism is excellent. If your message group id is a single constant because someone wanted global ordering, you have a fully serialized pipeline no matter how many consumers you run.

Message group design	Effective parallelism	Cost consequence
One group for everything	1	Backlogs, long Lambda durations, timeouts
Group per tenant or entity	Thousands	Near standard-queue behaviour
Group per shard key	Number of shards	Tunable, predictable

The cost of a serialized pipeline is not in the queue bill, it is in the workarounds: over-provisioned consumers waiting for work, longer end-to-end latency, retries against timeouts, and occasionally a second parallel path built to bypass the bottleneck.

Deduplication has its own cost profile

FIFO queues deduplicate within a 5 minute window using either a content-based hash or an explicit deduplication id. That is genuinely valuable, and worth comparing against the alternative: an idempotency table in DynamoDB doing roughly 2 writes per message. At 1 billion messages a month, that table would cost about $2,500 on-demand, substantially more than the entire FIFO premium. If 5 minutes of deduplication covers your duplicate window, FIFO is the cheaper mechanism by a wide margin.

If your duplicates can arrive hours apart, FIFO's window will not help and you need the idempotency store anyway, at which point the ordering guarantee is the only thing you are buying.

Consumer cost follows the queue type

Lambda event source mappings behave differently against the two queue types, and it shows up in the compute bill. Against a standard queue, the mapping scales out aggressively, adding up to 60 more concurrent pollers per minute, which clears a backlog quickly at the cost of a concurrency spike. Against a FIFO queue, concurrency is capped by the number of active message groups, so a backlog on few groups drains slowly no matter what you configure. A 10 million message backlog on a standard queue with 500 concurrent consumers at 200 ms clears in about 67 minutes and costs roughly $18 in duration at 512 MB. The same backlog concentrated in 20 FIFO message groups takes over 27 hours, and the cost of that delay is usually commercial rather than technical.

Choosing deliberately

Ask what breaks without ordering. Many pipelines that assume they need it are actually fine with last-write-wins semantics or a version number on each record, both of which work on a standard queue at lower cost and full parallelism. Financial ledgers, state machines driven by event sequence, and inventory decrements often do need it, but usually only within an entity, which is exactly what message group ids express.

If you adopt FIFO, batch aggressively, choose a high-cardinality message group id, enable high throughput mode, and set consumer concurrency to match the number of active groups rather than the total message rate. If you do not need ordering, standard queues are 20 percent cheaper per request and remove an entire class of throughput planning. Compare both against thequeue pricing comparison and price the queue and its consumers together against the resource catalog.

FAQ

How much more do FIFO queues cost than standard SQS?

FIFO costs $0.50 per million requests against $0.40 for standard, a 25 percent premium. At 1 billion messages a month with send, receive, and delete operations, that is $1,500 versus $1,200, a $300 difference. Batching up to 10 messages per API call reduces both figures by up to a factor of 10 and is a much larger lever.

What is the throughput limit on a FIFO queue?

FIFO queues default to 300 transactions per second per API action, or 3,000 messages per second with batching. High throughput mode raises this into the tens of thousands of messages per second per queue in supported regions, but ordering is still guaranteed per message group and only one consumer processes a given group at a time.

Why does message group design affect cost?

Because parallelism is bounded by the number of active message groups. A single constant group id serializes the entire pipeline regardless of consumer count, causing backlogs, long durations, timeouts, and retries. A high-cardinality group id such as a tenant or entity id gives parallelism close to a standard queue while preserving per-entity ordering.

Is FIFO deduplication cheaper than an idempotency table?

Considerably, when a 5 minute window suffices. FIFO deduplicates within 5 minutes using a content hash or explicit deduplication id at no extra charge beyond the queue premium. A DynamoDB idempotency table doing 2 writes per message would cost about $2,500 a month at 1 billion messages, far more than the entire FIFO premium.

When do I actually need ordered message processing?

When the business outcome depends on sequence: financial ledgers, state machines driven by event order, and inventory decrements are common cases. Many pipelines that assume they need ordering are fine with last-write-wins semantics or a version number on each record, both of which work on a cheaper standard queue with full parallelism.

How does C3X help with queue cost decisions?

C3X prices queues and the functions consuming them from Terraform, so the choice between FIFO and standard, and the batch size configured on an event source mapping, show their cost in the pull request. Since batching is usually a larger lever than queue type, seeing both priced together directs attention to the change that saves most.

What to do next

Price ordering before you require it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.