Amazon SQS Pricing: The 64 KB Rule, FIFO Premium, and Why Empty Receives Drive Half the Bill

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. For the broader event-driven design context, the event-driven async messaging post 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.

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.

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.

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.

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.
• 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.
• 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.

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 <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 covers the trade-offs.