SQS pricing is surprisingly cheap, but the way it’s bundled per million messages can make it feel like a black box if you’re not careful.
Let’s see what that looks like in practice. Imagine you have a small, but busy, microservice that receives about 100,000 messages per day. Each message is a tiny JSON payload, under 256 bytes.
{
"user_id": "a1b2c3d4e5f6",
"event_type": "user_login",
"timestamp": "2023-10-27T10:00:00Z"
}
Your service consumes these messages using a standard queue. Over a month (30 days), that’s 3 million messages.
Here’s the breakdown for SQS Standard queues in us-east-1 (prices can vary by region):
- Data Transfer In: Free.
- Data Transfer Out: Usually free within the same AWS region. If you’re transferring data out to the internet or another region, that’s a separate charge. For this example, let’s assume it’s all within
us-east-1. - API Requests: This is where SQS charges. For standard queues, it’s $0.40 per million requests.
Your service will make SendMessage requests to put messages into the queue and ReceiveMessage/DeleteMessage requests to get them out.
If your producer sends messages in batches of 10, you’ll make 100,000 / 10 = 10,000 SendMessage requests per day. Over 30 days, that’s 300,000 SendMessage requests.
For consumption, if your consumer polls the queue and processes messages one by one, it might make one ReceiveMessage request per message, and one DeleteMessage request per message. So, for 3 million messages consumed, that’s 3 million ReceiveMessage requests and 3 million DeleteMessage requests.
Total API requests: 300,000 (send) + 3,000,000 (receive) + 3,000,000 (delete) = 6,300,000 requests.
The cost for these requests: (6,300,000 requests / 1,000,000) * $0.40 = 6.3 * $0.40 = $2.52 per month.
Now, if you switch to SQS FIFO queues, the pricing changes. FIFO queues are $0.40 per million requests and $0.40 per million delivery delays. They also have a higher throughput limit. For the same 3 million messages, assuming you don’t need delivery delays, the API request cost would be the same. However, FIFO queues are typically more expensive due to their guaranteed ordering and deduplication features.
The key thing to understand is that SQS charges per request, not per message processed. This means that if your application polls the queue frequently but doesn’t receive any messages, you’re still incurring API request costs. A common optimization is to adjust the MaxNumberOfMessages parameter in your ReceiveMessage call. If you can process messages in batches, you reduce the number of ReceiveMessage and DeleteMessage requests. For instance, if you can process 10 messages per ReceiveMessage call, you reduce your receive/delete requests by 90%.
The "cost per million messages" framing is a bit of a simplification because the actual cost is driven by the number of API calls you make to interact with those messages. A single message might involve multiple API calls (send, receive, delete), and the payload size matters for data transfer out of AWS, but not for the core request pricing itself.
The next thing you’ll likely run into is understanding the throughput limits of SQS Standard vs. FIFO queues and how they impact your application’s ability to scale.