Cost

SQS bills per request, in 64 KB chunks — not per message. Once you internalise that sentence, every cost optimisation in this module is obvious, and so is why some teams pay a thousand times more than they need to for the same workload.

1. What you will learn

• Explain exactly what SQS charges for
• Compute the monthly cost of a workload from its message rate and size
• Identify the three optimisations that matter and quantify each
• Spot the patterns that generate surprising bills
• Compare SQS cost against Kafka and RabbitMQ on a total-cost basis

2. Why this concept exists

• SQS is cheap enough that teams do not model it — and then discover that an idle queue with tight-loop consumers costs thousands a year
• The cost model is also the throughput model: fewer API calls is both cheaper and faster

3. Beginner explanation

• You pay for API calls, not for storage or uptime
• The first million calls each month are free
• Ten messages in one call cost the same as one message in one call

4. How it actually works

• Billing unit is the request, and each 64 KB of payload counts as one request — a 1 MiB message is billed as 16
• Free tier: 1,000,000 requests/month, permanently
• Standard from $0.40/M, FIFO from $0.50/M, tiered down at volume → aws-facts.md §9
• Every API call counts: SendMessage, ReceiveMessage (including empty responses), DeleteMessage, ChangeMessageVisibility, GetQueueAttributes
• Data transfer is free in-Region; cross-Region and internet transfer are billed normally
• The three levers:
• 1. Long polling — eliminates billed empty receives. Often 10–1000× on idle queues
• 2. Batching — up to 10× on both receives and deletes
• 3. Payload size — keep messages under 64 KB to stay at 1 request each
• Fair-queue requests on standard queues are billed at both fair-queue and standard rates
• KMS is a separate bill: SSE-KMS generates KMS calls; KmsDataKeyReusePeriodSeconds (up to 24 h) is the lever
• Lambda ESM polling costs SQS requests even when there are no messages — a commonly missed line item

5. Diagram

• Cost breakdown of a worked workload: send vs receive vs delete vs empty receives
• Before/after of the three optimisations on the same workload

6. Step-by-step flow

• Count messages per month
• Multiply by requests per message (send + receive + delete = 3, before batching)
• Divide by batch size where batching applies
• Add empty receives (consumers × polls/sec × seconds, unless long polling)
• Multiply payload size ÷ 64 KB, rounded up, per request
• Subtract the free tier, apply the rate, apply tiering
• Add KMS if SSE-KMS is enabled

7. Configuration

• ReceiveMessageWaitTimeSeconds = 20
• MaxNumberOfMessages = 10
• KmsDataKeyReusePeriodSeconds
• Payload strategy: S3 pointer vs inline

8. Production considerations

• The classic surprise: 20 consumers short-polling an idle queue ≈ 50 M requests/day ≈ $600/month for zero messages
• The second surprise: 500 KB payloads billed as 8 requests each — an 8× multiplier nobody modelled
• Tag queues and use Cost Explorer per queue; an unattributed SQS line item is impossible to act on
• Compare honestly against alternatives: MSK has an hourly floor, self-hosted RabbitMQ has instances plus an on-call engineer. SQS's cost is usage-shaped, which suits spiky workloads
• Set a billing alarm before the first lab

9. Common mistakes

• Assuming per-message billing. Why → the 64 KB chunking changes large-payload costs by an order of magnitude. Instead → model per request
• Forgetting empty receives are billed. Why → the dominant cost on idle queues. Instead → long poll
• Large payloads inline. Why → 16× on a 1 MiB message. Instead → S3 pointer
• Ignoring Lambda ESM polling cost. Why → pollers call ReceiveMessage continuously. Instead → include it in the model
• SSE-KMS with a short key reuse period. Why → a KMS call per message. Instead → increase the reuse period

10. Real-world example

• A workload at 10 M messages/day, 8 KB average: naive cost vs optimised cost, itemised. Then the same workload at 500 KB average to show the chunking effect

11. Interview questions

• 🟢 How is SQS priced?
• 🟡 How does batching reduce cost?
• 🟡 Are empty receives billed?
• 🔴 A team's SQS bill is $4,000/month for 2 M messages/day. What do you check first?
• 🔴 How does message size affect cost? Give the exact rule.
• ⚫ Model the monthly cost of a 1,000,000 events/minute pipeline and compare it with MSK.

12. Summary

• Billing is per request, 64 KB per chunk, not per message
• Long polling and batching are the two big levers; payload size is the third
• Empty receives and Lambda poller calls are billed
• 1 M requests/month free, forever
• The cheap design and the fast design are the same design

Authoring notes

Terms defined in this module (defined once here, linked from everywhere else):

• request-based pricing
• 64 KB chunk
• free tier
• tiered pricing

Code samples:

• A cost calculator taking message rate, size, consumer count and polling mode
• A Cost Explorer query by queue tag

Mandatory "why?" answers:

• Why is an idle queue sometimes the most expensive one you own?
• Why does batching cut cost by ~10× but not exactly 10×?

Facts to pull from _reference/aws-facts.md: free tier 1M, $0.40/M standard, $0.50/M FIFO, 64 KB chunk, in-Region transfer free

← Previous: 17 — Monitoring and Observability · Index: Course home · Next: 19 — SQS and AWS Lambda →