Message queue pricing: SQS vs Service Bus vs Pub/Sub

Par Rohit Athaide · Publié le 4 nov. 2026

Short answer: a message queue passes work between parts of a system so they do not need to run at the same speed. It is billed per message handled, but each send, receive and delete can count as a request, and message size can multiply the count. Batching is the biggest saving.

Key points

• Each send, receive and delete can be a billed request.
• Some services round message size up to a block.
• Batch operations reduce request counts directly.
• Queues are not event streams and are billed differently.
• Failed messages that retry forever keep billing.

Which services are equivalent?

They are equivalent as managed queues for decoupling services. They are not the same as event streaming services built for high-volume, replayable logs. For those, see event streaming costs.

How does billing work?

• Per request. Each send, receive and delete counts. A message that is sent, read and deleted can count as three or more requests.
• Message size. Many services bill in blocks, so a message just over the block size counts as two. OCI Queue, for example, counts a request as up to 64 KB and larger messages as several.
• Tier or units. Some services, such as Service Bus, sell tiers with a base fee that includes a number of operations.
• Data volume. Pub/Sub bills by data volume, with a minimum per request.
• Retention and storage. Messages held longer than a default period may cost extra.
• Delivery to outside targets. Calls to HTTP endpoints, email or phones are billed separately.

What does a worked example look like?

Made-up round numbers to show the method, not real prices. A system processes 20 million messages a month, each 8 KB, in blocks of 64 KB.

The same traffic costs 34.37 or 2.40 depending on how the code calls the queue. Moving from single calls to batches of 10 divides the request count by about ten, and long polling removes the empty calls. Message size matters too: at 70 KB each, every message would count as two blocks and double the figure.

How do I spend less?

1. Batch. Send and receive many messages per call. This cuts request counts directly. See message size and batching for the same idea with IoT.
2. Long polling. Wait for messages instead of calling repeatedly on an empty queue.
3. Keep messages small. Send a reference to data in object storage, not the data.
4. Use one topic with filters, not many topics, where the service allows.
5. Move failed messages to a dead-letter queue and set limits on retries.

Which mistakes are common?

• Polling an empty queue every second from many workers.
• Sending large payloads inside the message.
• No retry limit, so a bad message loops.
• Using a queue where a function trigger would remove the queue.

Decision checklist

• How many messages per month and how large?
• Is the code batching and long polling?
• Is there a dead-letter queue?
• Is this a queue job, or does it need event streaming?

Next steps

Count messages per month, average size, and how many times each is read. Multiply by the unit from each vendor’s page. Compare with a function trigger, which may remove the need for a queue. See Lambda vs Azure Functions vs Cloud Functions and stream processing costs.