---
title: Amazon SQS Pricing: The 64 KB Rule, FIFO Premium, and Why Empty Receives Drive Half the Bill
description: SQS charges $0.40 per million standard requests and $0.50 per million FIFO requests, but a single 256 KB message counts as four requests under the 64 KB rule. Short polling on idle queues silently quadruples the bill. Cross-region data transfer adds a line many teams never count.
url: https://www.factualminds.com/blog/amazon-sqs-pricing-64kb-rule-fifo-vs-standard/
datePublished: 2026-06-13T00:00:00.000Z
dateModified: 2026-06-13T00:00:00.000Z
author: palaniappan-p
category: Cost Optimization & FinOps
tags: aws-sqs, sqs-pricing, aws-pricing, cost-optimization, finops, messaging
---
# Amazon SQS Pricing: The 64 KB Rule, FIFO Premium, and Why Empty Receives Drive Half the Bill
> SQS charges $0.40 per million standard requests and $0.50 per million FIFO requests, but a single 256 KB message counts as four requests under the 64 KB rule. Short polling on idle queues silently quadruples the bill. Cross-region data transfer adds a line many teams never count.
import PricingHeroStats from '~/components/blog/PricingHeroStats.astro';
import PricingDimensionTable from '~/components/blog/PricingDimensionTable.astro';
import BillSurpriseCallout from '~/components/blog/BillSurpriseCallout.astro';
import PricingDecisionCard from '~/components/blog/PricingDecisionCard.astro';
Amazon SQS is one of the simplest AWS pricing pages — two queue types, two per-million-request rates, a free tier. The bill is rarely simple. The reason is structural: SQS does not bill per logical message; it bills per 64 KB chunk of payload, multiplied by each API call against that chunk, multiplied by every consumer polling whether there is anything to receive. Get the polling configuration wrong and a queue handling 10K logical messages/day generates a million billable requests.
This post is the bill story. For queue architecture, error handling, retry semantics, and the SQS Extended Client pattern, see our [SQS reliable messaging patterns guide](/blog/aws-sqs-reliable-messaging-patterns-for-production/). For the broader event-driven design context, the [event-driven async messaging post](/blog/aws-event-driven-async-messaging-boundaries/) covers when SQS is the right primitive vs SNS, EventBridge, or Kinesis.
## The Five SQS Billing Dimensions
## The 64 KB Rule Most Teams Never Notice
SQS does not bill per logical message. It bills per 64 KB chunk of payload on each API call. The mechanics:
- A 30 KB message: 1 billable SendMessage + 1 billable ReceiveMessage = 2 requests.
- A 200 KB message: 4 billable SendMessage chunks + 4 billable ReceiveMessage chunks = 8 requests.
- A 256 KB message (the per-message max): 4 + 4 = 8 requests.
- 10 messages of 25 KB each in one ReceiveMessage batch: 10 SendMessage + 10 ReceiveMessage = 20 requests (the batch API does not chunk smaller messages together).
The leverage is in payload size and batching. Keep messages under 64 KB whenever possible; batch up to 10 small messages per call where the API supports it.
Teams routinely treat the 256 KB SQS max-message size as "send up to 256 KB freely." It isn't. A 200 KB message sent
and received once is 8 billable requests vs 2 for a 64 KB message. On high-volume queues with large payloads, this
multiplier dominates the bill. Use the SQS Extended Client pattern: store the payload in S3, send the S3 key in a
small SQS message. The S3 storage cost is dramatically cheaper than the SQS per-request chunk premium at any
meaningful volume.
## Long Polling Is Not Optional at Scale
The single most common SQS waste pattern is short polling on idle or low-volume queues. With `WaitTimeSeconds=0` (the default until you explicitly set it), every ReceiveMessage call returns immediately. A consumer in a polling loop on an empty queue can generate one billable request per loop iteration.
The math on an idle worker:
Set `ReceiveMessageWaitTimeSeconds=20` on the queue itself rather than relying on every consumer to set it on each call. Defaults applied at the queue level are inherited by every consumer; per-call configuration is forgotten in new consumer code.
## FIFO vs Standard: When 25% More Is Worth It
FIFO queues bill at $0.50 per million requests vs $0.40 for Standard — a 25% premium. The features FIFO provides:
- **Exactly-once processing** within the message deduplication interval (default 5 minutes).
- **Strict ordering** within a message group ID.
- **Content-based deduplication** when a deduplication ID is computed from the message body.
- **Throughput** up to 300 messages/second per API action (or 3000/sec with batching) per message group ID — significantly lower than Standard's near-unlimited throughput.
The right use case for FIFO: ordered state transitions per entity (each entity's events on its own message group ID), financial workflows where double-processing is unacceptable, fulfillment pipelines where order matters within a customer or shipment.
The wrong use case: general background work, fanout to many consumers, or anything where the consumer can be made idempotent at the application layer. Standard queues with idempotent consumers do the same job at 20% less cost and with no throughput ceiling.
FIFO is often chosen out of caution: "we want exactly-once, so let's use FIFO." For most workloads the right pattern
is Standard plus idempotent consumers (write with a unique business key, check-before-insert, or use conditional
DynamoDB writes). The premium and the per-message-group throughput cap are both avoidable when the consumer handles
deduplication.
## DLQ and Retry Storms
Dead-letter queues use the same per-request pricing as the source queue. The cost driver is retry traffic: a consumer that fails to process a message keeps retrying — each retry is a billable Receive, a billable visibility-timeout extension, and eventually a billable move to DLQ when `maxReceiveCount` is exhausted.
A 1% failure rate with `maxReceiveCount=5` adds roughly 5% to the request bill from retries alone. A poison-message storm (e.g., a deploy with a parse error causing every message to fail) can multiply the request volume by `maxReceiveCount` overnight until the storm is detected and the bad code rolled back.
Set `maxReceiveCount` conservatively (3–5 for most workloads), alert on DLQ depth crossing a low threshold, and add a
CloudWatch alarm on `ApproximateAgeOfOldestMessage` to catch processing failures within minutes. The faster you catch
a retry storm, the smaller the bill spike.
## Cross-Region and the Hidden Data Transfer Line
SQS has no native cross-region replication. Common patterns to achieve it:
- **Lambda forwarder**: a Lambda consumes from the primary region's queue and SendMessage to a replica queue in another region. Pays the standard inter-region data transfer rate ($0.02/GB) plus the destination-region SQS request cost — effectively double-billing each message.
- **SNS-to-SQS multi-region fanout**: an SNS topic in one region with SQS subscriptions in multiple regions. SNS handles the fanout; data transfer still bills per cross-region delivery.
- **Custom replication via DynamoDB Streams**: rarely the right answer for messaging but occasionally used when DynamoDB is already the system of record.
Replicate only when the DR pattern genuinely requires it. A 100M-message-per-month queue replicated across two secondary regions adds roughly the source-region bill twice for the request side, plus the inter-region data transfer for the message bodies.
## What This Means for Common SQS Bill Patterns
## When to Use SQS vs Alternatives
## A 30-Day SQS Bill Cleanup Plan
**Week 1 — Audit polling mode.** Find every queue with `ReceiveMessageWaitTimeSeconds=0`. Set to 20 on the queue (consumers inherit the default). This alone often recovers 30–60% of the request bill on accounts with many idle workers.
**Week 2 — Audit payload sizes.** Use CloudWatch's `SentMessageSize` metric per queue. Identify queues averaging over 64 KB per message. Migrate to the SQS Extended Client pattern (S3-backed) for those queues. Cross-check S3 cost in our [S3 pricing calculator](/tools/aws-s3-pricing-calculator/).
**Week 3 — Audit FIFO usage.** Identify FIFO queues where the consumer logic is naturally idempotent. Migrate those to Standard with idempotent processing (DynamoDB conditional writes, business-key uniqueness, or a deduplication table).
**Week 4 — DLQ and alarm hygiene.** Set `maxReceiveCount` to 3–5 across queues that have it higher (or unset). Add CloudWatch alarms on DLQ depth and `ApproximateAgeOfOldestMessage` for every production queue.
## What This Post Doesn't Cover
- **SQS metric resolution costs in CloudWatch** — every queue publishes built-in CloudWatch metrics; covered in the [CloudWatch pricing post](/blog/amazon-cloudwatch-pricing-metrics-logs-alarms-dashboards/).
- **Lambda-as-consumer concurrency and throttling** — the Lambda side of SQS-triggered consumption has its own cost dynamics; covered in the [Lambda cost optimization post](/blog/aws-lambda-cost-optimization-pay-per-request-vs-provisioned/).
- **MQ for AMQP/JMS workloads** — Amazon MQ is a different product entirely with a $700/month minimum entry point; covered in a separate Phase 3 post.
- **SNS-to-SQS fanout pricing** — covered in the [SNS pricing post](/blog/amazon-sns-pricing-publishes-fanout-protocols/).
## If You Only Do One Thing This Week
Set `ReceiveMessageWaitTimeSeconds=20` on every queue in your account. The change is non-destructive, applies immediately, and on accounts with idle worker pools typically recovers 30–60% of the SQS request bill within days. Run `aws sqs list-queues` followed by `aws sqs get-queue-attributes --queue-url --attribute-names ReceiveMessageWaitTimeSeconds` to find the queues that need the change; ship the fix via your IaC of choice and the bill drops next month.
For the broader queue-architecture decision — when SQS is the right primitive vs alternatives — the [reliable queue systems on AWS post](/blog/reliable-queue-systems-aws-sqs-kafka-redis/) covers the trade-offs.
## FAQ
### Why does a single SQS message sometimes count as four requests?
SQS bills per 64 KB chunk of payload, not per logical message. A 200 KB message counts as four requests on the SendMessage call and four more on the ReceiveMessage call — eight billable requests for a single round trip. Keep messages under 64 KB whenever possible by storing the payload in S3 and passing the S3 key in the SQS body. This is the SQS Extended Client pattern and the per-request saving on high-volume queues with large payloads is substantial.
### Is FIFO really worth 25% more per request?
FIFO queues bill $0.50 per million requests vs $0.40 per million for Standard — a 25% premium. The premium pays for exactly-once processing, strict ordering within a message group, and content-based deduplication. The right use case is workflows that genuinely require ordering (financial transactions in sequence, state-machine updates per entity, ordered fulfillment events). The wrong use case is general fanout or background work where ordering is not a hard requirement; Standard queues with idempotent consumers do the same job at 20% less cost and significantly higher throughput.
### How does short polling drive the bill up?
Short polling (the default WaitTimeSeconds=0) returns immediately whether or not messages are available. A consumer in a tight ReceiveMessage loop on an empty queue can generate millions of billable "empty receive" requests per day per consumer — each one billed at the per-request rate. Long polling (WaitTimeSeconds=20) holds the connection until a message arrives or the timeout expires, collapsing dozens or hundreds of empty receives into one billable request. The change is one parameter; the saving on idle or low-volume queues can be 90%+.
### What does the SQS free tier actually cover?
AWS provides 1 million free requests per month per account across all SQS queues (Standard + FIFO combined). This covers low-volume use cases entirely. The free tier resets monthly and is account-wide, not per-queue. It is enough to run a hobby project or a development environment for free; production workloads almost always exceed it. Verify your usage against the SQS console metrics — many teams underestimate request volume because they count messages rather than chunks-times-receives.
### Does dead-letter queue traffic cost the same?
Yes. DLQ writes are billed at the standard SQS request rate. The cost driver is poison-message storms: a consumer that fails to process a message keeps retrying (each retry is a billable receive + visibility timeout extension) until the maxReceiveCount is exhausted, then the message moves to the DLQ (another billable request). For a high-volume queue experiencing a 1% failure rate with maxReceiveCount=5, the retry traffic alone can add 5% to the request bill. Tune maxReceiveCount conservatively and alert on DLQ depth to catch storms early.
### How much does cross-region SQS replication cost?
SQS itself does not have native cross-region replication. Common patterns — Lambda forwarding messages from a primary region queue to a replica queue, or SNS fanout to multiple regional SQS queues — incur the standard inter-region data transfer rate ($0.02/GB) plus the destination region SQS request cost. For a high-volume queue replicated across two secondary regions, the data transfer and double-billed request lines can exceed the primary queue cost. Replicate only when the DR pattern genuinely requires it.
### When should I use SNS-to-SQS fanout vs EventBridge?
SNS-to-SQS fanout is cheaper for simple one-to-many event distribution to a fixed set of queues: SNS publishes are $0.50/M and the SQS-side delivery is free under the SNS billing model. EventBridge is more expensive per event ($1/M) but provides richer routing rules, schema discovery, and replay capability. Use SNS-to-SQS for predictable high-volume fanout to known consumers; use EventBridge when you need rule-based routing, cross-account event sharing, or integration with the AWS partner-event ecosystem.
---
*Source: https://www.factualminds.com/blog/amazon-sqs-pricing-64kb-rule-fifo-vs-standard/*