queue-advisor-pricing-app

The question I heard most often in architecture reviews was never "which queue should we use?" — it was "what does this cost a year from now, when volume is ten times higher?". The four AWS messaging services answer that question with different billing models, and that is exactly where comparing in your head breaks down.

SQS bills per million requests, with every 64 KB of payload counting as one request. Kinesis Data Streams bills per shard-hour (or per GB ingested in on-demand mode) plus extended retention beyond 24 hours. EventBridge bills per million events published to a custom bus. MSK bills per broker-hour and per GB-month of storage, whether the cluster is busy or idle. Four units, four curves: one is linear with message count, one is a staircase with shard count, one is nearly flat regardless of traffic.

I have watched decisions get made from a three-month-old spreadsheet — and the invoice come in differently because nobody counted the average message size. This repository exists to turn that arithmetic into a form: you enter throughput, message size and retention, the app applies each service's pricing model and shows the four results on one screen. The goal is not to replace the AWS Pricing Calculator; it is to answer, in under a minute, at which volume band each service stops making sense.

The app is a form plus a pricing model in TypeScript. There is no runtime call to the AWS Price List API — rates are constants in the code, which keeps the tool static, fast and credential-free, with the maintenance cost that comes with it: someone has to update the constant when AWS changes the table.

Inputs: messages per second, average message size in KB, retention in days and, for fit, what the workload demands — strict ordering, replay of old messages, more than one consumer reading the same event.

Cost: each service has its own function. For SQS, the model converts throughput into requests per month and rounds payload up in 64 KB chunks — that rounding is why a 70 KB message costs twice a 64 KB one. For Kinesis, it derives the shard count from the larger of 1 MB/s write and 1,000 records/s per shard, multiplies by shard-hours and adds retention beyond 24 h. For EventBridge, it is events per million, with the 256 KB payload limit as a constraint rather than a cost. For MSK, it is broker-hours times broker count plus GB-month of storage — the fixed cost that dominates at low volume.

Fit: simple rules flag what each service does not do. Standard SQS does not guarantee order; SQS FIFO does, but with a per-group throughput ceiling. Kinesis and MSK allow replay within retention; SQS does not. EventBridge fans out to multiple targets per rule; SQS delivers each message to one consumer.

The output is a table: four columns, estimated monthly cost and fit flags. The table does not decide for you — it removes the part of the conversation that is arithmetic.

Three things I learned using this tool in architecture reviews.

The lowest cost is rarely the answer. At 100 messages per second with a 4 KB payload, SQS usually comes out cheaper than anything else — and it is the wrong choice if you need to reprocess the last 24 hours after a broken deploy. The fit column exists for that: a service flagged as no-replay should not win on price.

Message size matters more than throughput. The SQS model rounds to 64 KB chunks; the Kinesis model counts shards per MB/s. A workload of 50 messages per second at 200 KB each costs, in SQS requests, the same as 200 messages per second at 50 KB. Whoever only reports "messages per second" underestimates the bill.

Fixed cost becomes an advantage at high volume. MSK looks expensive at 10 messages per second because the broker-hour does not know it is idle. At 20,000 messages per second with 7-day retention, that same fixed bill falls behind Kinesis on-demand — and that is where having all four on one screen, with the same scenario, beats four estimates made on different days.

The tool does not replace the architecture design. It replaces the part of the design that used to be a spreadsheet.