SQS pricing in 2026: requests, not messages

Amazon SQS pricing has one meter, the request, and the number of requests on the bill is usually larger than the number of messages that moved. Two documented rules do that. A payload is billed in 64 KB chunks, so one 1 MiB message is billed as 16 requests before anything reads it. And an empty response to a poll is still an API action, so a consumer watching a queue that never receives anything still generates a bill. Both are one queue attribute away from costing an order of magnitude less, and both defaults are set the expensive way.

What does Amazon SQS charge for a million requests?

The Amazon SQS pricing page prices standard, FIFO and fair-queue requests differently, on a volume curve that steps down at 100 billion and again at 200 billion requests a month. In US East (N. Virginia) the first tier is $0.40 per million for standard and $0.50 for FIFO, with a separate $0.10 fair-queue charge. Check the page for your own region before budgeting.

There is no queue-hour charge and no per-queue minimum: "With AWS SQS, you pay only for what you use and there is no minimum fee." An idle queue with nothing polling it costs nothing. An idle queue with something polling it is the subject of most of this post.

The rate is close to flat worldwide, which is unusual. Read every region out of the SQS pricing feed that the pricing page renders its tables from, and 26 of the 36 priced entries sit at exactly the US East rate, including South America (Sao Paulo). The whole spread is 15% below to 19% above.

Why does an Amazon SQS bill show more requests than messages?

Because a request is a unit of payload, not a unit of message. The pricing page's metering table says "Every Amazon SQS action counts as a request", then "Each 64 KB chunk of a payload is billed as 1 request (for example, an API action with a 1 MiB payload is billed as 16 requests)."

That worked example settles a unit ambiguity AWS never spells out. If a chunk were 64,000 bytes, a 1,048,576-byte payload would round up to 17 requests, not 16. Only a 65,536-byte chunk gives AWS's own answer, so the 64 KB on that page means 64 KiB. The message quotas page uses the binary units consistently: "The minimum message size is 1 byte (1 character). The maximum is 1,048,576 bytes (1 MiB)."

The rule is written about an API action's payload and does not distinguish sending from receiving. Move one maximum-size message through a standard queue and the lifecycle is 16 billed requests to send, 16 to receive and 1 to delete, since a delete carries only a receipt handle. That is 33 requests for one message against 3 for a small one, eleven times the request cost for identical mechanics. A million 1 MiB messages is $13.20 in US East, where a million small ones is $1.20. Nothing in the queue configuration stops a producer from sending them either: for maximum message size, "The range is from 1 KiB to 1024 KiB. The default value is 1024 KiB."

Is Amazon SQS free, and how far does the 1 million request free tier go?

Partly, and permanently. The pricing page says "All customers can make 1 million Amazon SQS requests for free each month", footnoted that "Unused free usage does not roll over to the next month." All customers, not new accounts for twelve months.

A million requests is generous against messages and thin against polls. Seven consumers long polling at the maximum wait fit inside it for a whole month. One consumer short polling ten times a second exhausts it in 27.8 hours. Same queue, same zero messages.

What does short polling an idle Amazon SQS queue cost per month?

The charge that surprises people, fully documented. The short and long polling page says a short-polling ReceiveMessage "sends an immediate response, even if no messages are found". The polling mode best practice adds the billing consequence: "Short polling is billed the same as long polling." An empty receive is a request. You are paying to ask an empty queue whether it is empty.

Short polling is also the default. The queue parameters page gives the receive message wait time as "The range is 0 to 20 seconds. The default value is 0 seconds", and adds that "Any non-zero value sets long polling." A queue created and left alone polls the expensive way.

What follows is hypothetical arithmetic on AWS's published rates, not a measurement. Take a standard queue in US East that receives no messages at all for a month, and ten consumers watching it. A month is 30 days, or 2,592,000 seconds. Long polling at the documented 20-second maximum produces three requests a minute per consumer. Short polling produces as many as the loop allows, so three loop speeds are shown; the 10-per-second row is the ceiling AWS documents for one Lambda provisioned-mode event poller.

The gap between the first row and the last is $103.16 a month, or $1,237.94 a year, for a queue that carried nothing. The ratio is 200 to 1 and it is one queue attribute. The Amazon SQS FAQ is blunt: "No. Long-polling ReceiveMessage calls are billed exactly the same as short-polling ReceiveMessage calls", and "In general, you should use a maximum of 20 seconds for a long-poll timeout."

Most people never write that loop, which is why the charge hides. Lambda writes it for them. The Lambda event source mapping scaling page says each provisioned-mode poller polls "with up to 10 polls per second, which incur SQS API requests cost", and that "Using provisioned mode incurs additional costs." In standard mode Lambda tunes itself down instead: it "scales back the processing to five concurrent invokes, and can optimize to as few as 2 concurrent invokes to reduce the Amazon SQS calls and corresponding costs." Read a queue attached to a function the way you would read what a Lambda cold start costs: the invocation is the visible charge and the polling around it is not.

When does Amazon SQS batching stop saving money?

At exactly 64 KiB per message, and at every multiple of it. AWS publishes that break-even nowhere; it falls out of two of its own pricing rules held together.

The batch actions page says batching lets you "reduce costs and manipulate up to 10 messages with a single action", and the FAQ agrees that "By grouping messages into batches, you can reduce your Amazon SQS costs." True, but the tenfold saving everyone quotes assumes small messages. The pricing page caps a request at "from 1 to 10 messages, up to a maximum total payload of 1 MiB" and charges that payload by the chunk. So a batch of ten 64 KiB messages is a 640 KiB payload, which is ten chunks, which is ten billed requests. Sending them one at a time is also ten billed requests.

The saving is not monotonic. It collapses at 64 KiB, recovers to 45% one kilobyte later because single sends then waste a partial chunk each, and collapses again at 128 KiB. The full 90% survives only while ten messages fit in one chunk, which is 6,553 bytes each. Batch anyway for throughput, but do not plan a 90% request saving on a queue carrying 50 KiB payloads.

One detail costs people money here. Only three batch actions exist: SendMessageBatch, DeleteMessageBatch and ChangeMessageVisibilityBatch. The same page nonetheless tells you to use them "to send, receive, and delete messages, and to change the message visibility timeout for multiple messages with a single action", which its own list contradicts. Receiving in bulk is a parameter, not a batch action: the ReceiveMessage reference gives MaxNumberOfMessages as "Valid values: 1 to 10. Default: 1." Leave that default and every receive is its own billed request, however carefully the sends were batched.

How much more do Amazon SQS FIFO queues cost than standard queues?

25% more per request below 100 billion a month, and the gap widens with volume, not narrows: 33% in the middle tier and 46% above 200 billion, because the standard curve falls faster than the FIFO one. The pricing page scopes the premium narrowly: "API actions for sending, receiving, deleting, and changing visibility of messages from FIFO queues are charged at FIFO rates. All other API requests are charged at standard rates." Administrative calls against a FIFO queue stay at the standard rate. The FAQ flatly disagrees: asked whether every request is charged, it answers "Yes, for any requests beyond the free tier. All Amazon SQS requests are chargeable, and they are billed at the same rate." They are not. Take the pricing page.

The rounding is not uniform either. At the first tier FIFO is exactly 1.25 times standard in every region but three: Asia Pacific (Malaysia) and Asia Pacific (Thailand) at 1.2647, and Israel (Tel Aviv) at 1.2619, where AWS rounded the published cents rather than the ratio.

The charge most likely to appear without anyone choosing it is fair queues, which are standard queues that mitigate noisy-neighbour effects. The FAQ describes enabling them as a producer-side change only: "To enable fair queues, include a message group ID when sending messages to your Amazon SQS standard queues. No changes to message consumers are required." The pricing page then explains what that costs. Standard-queue actions "incur fair queue rates when at least one message with a message group ID is involved", and "These requests are charged both fair queue rates and standard queue rates."

Both rates. $0.40 plus $0.10 is $0.50 per million, which is exactly the FIFO rate. A single message carrying a message group ID inside a batch of ten applies it to the whole request. Adding one attribute to a producer raises a standard queue's request price by 25%, with no queue setting changed and nothing in the console to review.

Does AWS charge for data transfer on Amazon SQS?

Not within a region, according to the pricing page: "AWS does not charge for data transfer when sending messages to Amazon SQS or receiving messages from Amazon SQS if all resources are in the same AWS region. For cross-region data transfer and data transfer to or from the internet, standard AWS Data Transfer Charges apply."

The FAQ states a narrower exemption on the same question. It says SQS cost is "calculated per request, plus data transfer charges for data transferred out of Amazon SQS (unless data is transferred to Amazon Elastic Compute Cloud (EC2) instances or to AWS Lambda functions within the same region)." One page exempts every in-region resource, the other exempts EC2 and Lambda. For an ECS task or an EKS pod the two answers differ. Plan against the pricing page, and know the gap exists before an unexplained transfer line appears.

Reaching SQS privately has its own bill. The sending from a VPC guide says "To connect your VPC to Amazon SQS, you must define an interface VPC endpoint", which is billed per endpoint hour and per gigabyte regardless of what SQS charges. On a low-volume queue those endpoint hours outweigh the request charges entirely, as what VPC endpoints actually cost works through.

What else lands on an Amazon SQS bill besides requests?

Encryption, large payloads and the services around the queue. Server-side encryption with a customer managed key scales with time rather than traffic. The SQS key management page publishes the formula R = (B / D) * (2 * P + C), where B is the billing period in seconds, D is the data key reuse period, P is producing principals and C is consuming principals. Its own example, a 31-day month at a five-minute reuse period with one producer and one consumer, comes to 26,784 KMS calls. Both of the page's worked examples check out when recomputed. Note what is absent from the formula: message volume. A near-silent encrypted queue generates the same KMS calls as a busy one, and the page warns that "A shorter reuse period provides better security but results in more calls to AWS KMS, which might incur charges beyond the Free Tier." What those calls cost is in what AWS KMS costs per key and per request.

Payloads above 1 MiB go to S3 through the Extended Client Library, where "you incur Amazon S3 charges for any Amazon S3 storage you use to send message payloads." A dead-letter queue is a queue, so every redrive is another billed send and receive.

None of it separates itself on the bill by default. SQS request charges roll up per region, not per queue, unless queues are tagged and those tags are activated for cost allocation, the failure mode described in why cost allocation tags go missing. Request meters also compound: a queue behind an API pays for the REST or HTTP API tier in front of it, and a queue inside an orchestration pays per Step Functions state transition as well.

Three settings decide almost all of it. Set the receive message wait time to 20 seconds so polls stop billing for nothing. Set MaxNumberOfMessages to 10. Keep payloads under 6,553 bytes if batching is meant to pay the full 90%, and treat anything near 1 MiB as a sixteen-times multiplier, not one message.