You budgeted messaging at forty cents per million requests, then the AWS bill arrived three times higher than your message count said it should be. The culprit is not a price hike. It is the 64 KB chunking rule: AWS does not bill a logical message, it bills every 64 KB chunk of payload on every API call that touches it. A 200 KB order event is four billable requests when you send it, four more when a worker receives it, and four more when the worker deletes it. Twelve charges for one message, before SNS fan-out multiplies it again.
This post explains how SQS and SNS actually count requests, what that costs at realistic volume, why production messaging belongs in cost of goods sold rather than overhead, and how to book it so your gross margin tells the truth.
How SQS Turns One Message Into Many Billable Requests
SQS pricing looks disarmingly simple: Standard queues cost about forty cents per million requests, FIFO queues about fifty cents per million, with the first million Standard requests free each month. The complexity hides in the definition of a request.
Each 64 KB chunk is a request
Every started 64 KB chunk of payload counts as one request of its own. A 30 KB message is one request. A 64 KB message is one request. A 65 KB message is two. A 200 KB message is four, a 256 KB message is four, and a 1 MB payload is sixteen.
That last number matters more than it used to. In August 2025 AWS raised the SQS maximum message size from 256 KB to 1 MB for both Standard and FIFO queues. The headroom is convenient for the occasional large event, but anything you park above 64 KB pays the chunk multiplier on every touch. A team that moves from 50 KB to 200 KB average payloads quadruples its SQS request count without sending a single additional message.
Every API action counts separately
Each API action against a queue is a request, and the chunk multiplier applies to each one. Sending, receiving, deleting, and changing message visibility each meter independently.
Walk through the full lifecycle of one 200 KB message on a Standard queue. The send is four billable requests. The worker's receive is four more. The delete after successful processing is four more. One logical message, twelve billable requests, roughly half a cent per thousand at list rates. The same lifecycle for a 30 KB message is three requests total. Payload size is the dominant variable in most SQS bills, not message count.
Two more meters surprise first-time operators. Empty receives are billable: every poll that returns no messages still counts as a request, so an aggressive short-poll loop on an idle queue burns money for nothing. And FIFO queues carry about a 25 percent premium over Standard at every volume tier, which adds up fast when the chunk multiplier is already working against you. Use FIFO where ordering and exactly-once processing are genuine requirements, and Standard everywhere else.
How SNS Multiplies It a Second Time
SNS adds a second billing dimension, because a published message is metered once on arrival and again on every delivery.
Publishes and deliveries are separate meters
Publishing to a topic costs about fifty cents per million requests, chunked the same way: a 256 KB publish counts as four. Each delivery to each subscriber is then metered per 64 KB chunk as well, with the rate depending on the delivery protocol.
Not all deliveries cost the same. Deliveries to SQS queues, Lambda functions, and Firehose streams carry no delivery charge, which makes SNS-to-SQS fan-out nearly free on the delivery side. HTTP and HTTPS deliveries, email, and mobile push are metered, and SMS is priced separately per message segment. A 256 KB event fanned out to three SQS queues and one HTTP webhook therefore costs four publish requests, zero for the three SQS deliveries, and four HTTP deliveries. Shrink that event under 64 KB and the same fan-out costs one publish plus one HTTP delivery.
SNS followed SQS into larger payloads in September 2026, allowing 1 MB messages behind a topic-level maximum-size setting. Topics configured above 256 KB can only deliver to SQS, Lambda, and Firehose, with at most one hundred subscriptions. The constraint is a hint about the intended pattern: large events belong in a queue-backed pipeline, not blasted to every protocol.
Why fan-out still wins
The delivery meter tempts teams to skip SNS and send duplicate SQS messages to each consumer directly. Resist that. Duplicate sends multiply the most expensive part of the cycle, the per-consumer send plus receive plus delete, while SNS-to-SQS fan-out pays one publish and zero SQS delivery charges per subscriber. When several consumers need the same event, fan-out is both the cleaner architecture and the cheaper bill.
What This Costs at Real Volume
List rates are per-million numbers that only make sense multiplied out, so here are three realistic shapes.
A side project sending 2 million small messages a month through one Standard queue pays almost nothing. Each message under 64 KB costs one send, one receive, and one delete, or 6 million requests. The first million are free, leaving 5 million at forty cents per million: about two dollars.
A mid-size SaaS platform publishing 5 million 10 KB notifications a month to a Standard topic with three SQS subscribers and one HTTP webhook pays single digits for the SNS leg. Publishes run about two dollars and fifty cents. The three SQS deliveries are free. HTTP deliveries run about three dollars at six cents per hundred thousand. The downstream SQS API actions roughly double the total, leaving the whole notification pipeline under fifteen dollars a month. This is the shape where messaging is genuinely negligible.
Now replay that SaaS workload with 200 KB payloads because each event embeds a full order document. Every meter quadruples. Publishes jump to ten dollars, HTTP deliveries to twelve, and the downstream SQS receives and deletes quadruple too. The pipeline lands near sixty dollars a month, still small in absolute terms, but four times the cost of the same workload with lean events, and the gap compounds as volume grows. At 500 million chunked requests a month the difference between lean and bloated events is a four-figure annual line item.
Volume tiers exist but rarely matter for small businesses: Standard requests step down past 100 billion and 200 billion requests a month. Your realistic lever is not the tier, it is the average chunk factor.
Why Production Messaging Is Variable COGS, Not Overhead
Messaging that delivers your product to paying customers is a direct cost of revenue. It scales with usage, it disappears when nothing sells, and investors expect to see it above the gross-margin line alongside compute, database, storage, and bandwidth for production.
Accounting standards leave room here: generally accepted principles do not precisely define cost of goods sold, and SaaS gross-margin practice fills the gap with a direct-cost test. Ask whether the spend exists to serve customers in production. Production queues carrying order events, notification topics fanning out to customer-facing workers, and webhook deliveries to customer endpoints all pass. Staging queues, load-test topics, developer sandbox subscriptions, and the dead-letter queue draining last quarter's load test do not. Those belong in research and development or general overhead.
The production boundary is the entire game. One AWS bill lumps every queue and topic together, so tag production resources and split the invoice every month. Teams that skip the split usually err in the flattering direction, burying infrastructure in overhead and reporting a gross margin their unit economics cannot defend. A diligence review reclassifies it in an afternoon, and the restated margin is never the higher one.
Book the net amount you actually pay. The free tier is a billing discount, not revenue, so there is nothing to gross up. If you want visibility into how much of the workload the free tier absorbs, track billable requests separately in your metrics and keep the ledger entry at cash cost.
How to Book It So Your Margin Tells the Truth
Give messaging its own cost-of-sales account rather than blending it into a generic cloud or software line. A dedicated account such as cloud messaging lets you divide the month's spend by the month's billable requests and see your true cost per chunked request, which is the number that tells you whether payload growth is eating margin.
The AWS charge settles after month-end, so accrue it. Estimate the messaging portion from your request metrics at close, true up to the invoice when it lands, and keep the sandbox portion out of cost of sales. Here is a full cycle for a month where production messaging ran eighteen dollars and forty cents and the sandbox added two dollars and ten cents:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:AWS USD
2026-01-31 * "AWS" "January SQS prod 8.2M chunked requests plus SNS publishes and HTTP deliveries"
Expenses:CostOfSales:Cloud-Messaging 18.40 USD
Liabilities:Accrued:AWS -18.40 USD
2026-02-03 * "AWS" "January AWS charge settles, prod messaging plus 2.10 sandbox"
Liabilities:Accrued:AWS 18.40 USD
Expenses:Research:Cloud-Sandbox 2.10 USD
Assets:Cash:Operating -20.50 USDReconcile the accrued amount to your cost explorer grouped by service and usage type at least monthly. SQS and SNS should appear as separate lines so a spike in one does not hide inside the other's flat trend. If you keep your books in plain text, the cost-tracking patterns in the docs extend naturally to a per-service messaging split.
One classification trap to avoid: FIFO premiums and extended-retention storage are still messaging costs, but extended retention beyond your genuine redrive window is a storage choice, not a delivery cost. Either shorten retention or move the storage portion where it belongs instead of letting a fourteen-day retention policy quietly inflate cost of sales.
Five Controls That Typically Cut the Bill 30 to 50 Percent
Start with long polling and batching. Together they routinely cut SQS spend by nearly half and take an afternoon to implement.
1. Turn on long polling everywhere
Set the receive wait time to twenty seconds on every queue. Workers then hold the connection open instead of hammering empty polls, which collapses the empty-receive line that dominates idle-queue bills and smooths CPU spikes on consumers.
2. Batch every API call that allows it
Send, receive, and delete all support batches of up to ten messages. A worker processing one message per call pays ten times the request count of a worker draining ten at a time. Batch deletes are the most commonly missed: teams that carefully batch sends often delete one by one.
3. Put the payload on a diet
Keep each event under one 64 KB chunk. Store the full document in object storage and send a reference with the identifiers the consumer needs, the claim-check pattern. Compress where references are impractical, and strip embedded blobs, duplicated customer records, and verbose debug context from the hot path. Every chunk you remove multiplies across sends, receives, deletes, publishes, and deliveries.
4. Filter at the topic
Attach filter policies so each subscriber receives only the events it handles. Unfiltered fan-out pays delivery and downstream processing for messages the consumer drops on arrival. This is pure waste with a one-line fix per subscription.
5. Reserve FIFO for where ordering is real
Audit which queues genuinely need ordering and deduplication. FIFO's premium applies to every chunked request on the queue, so a FIFO queue carrying events nobody orders is a standing 25 percent surcharge. While auditing, set short retention with a dead-letter queue for failures instead of letting poison messages retry into a large request count.
Monitor the two metrics that predict the bill: approximate number of messages sent and number of empty receives. Alert when empty receives exceed a small share of total receives, and review average payload size per queue quarterly. Payload growth is gradual enough to miss month to month and large enough to matter year to year.
Month-End Checklist for Messaging Costs
Close the loop the same way each month so the numbers stay trustworthy:
- Pull chunked request counts for SQS and SNS from your billing breakdown, not logical message counts from application logs.
- Divide each service's spend by its chunked requests to get the true unit cost, and compare it against the forty- and fifty-cent list benchmarks.
- Compute the average chunk factor per queue by dividing billable requests by logical messages; anything above 1.2 deserves a payload review.
- Split production from staging and sandbox spend using resource tags, and confirm only production landed in cost of sales.
- True up last month's accrual to the settled invoice and carry the variance forward in your estimate.
- Check empty receives as a share of total receives, and confirm long polling is still enabled after any infrastructure change.
- Confirm every new queue and topic created during the month inherited production tags and filter policies.
Pull this month's SQS and SNS lines from your billing console today and compute the average chunk factor. If it sits above 1.2, your cheapest margin win is a smaller payload, not a bigger plan.
