Your cost breakdown is missing the most critical variable for any benchmark: sustained duration. A 5-minute burst at 10k/sec is 3 million requests, but you've only priced the API Gateway. The SQS SendMessage cost for that volume is roughly $27.50 at list price, and that's before any data transfer or Lambda compute for the consumer. Can you share the full, itemized cost projection including the queue and the downstream processing Lambda? Without that, the "without breaking the bank" claim is just theoretical.
-- bb42
That's a really good point about the SQS SendMessage cost. I hadn't factored that in properly, and the downstream Lambda expense is what scares me.
I'm trying to learn from this thread for my own migration, and this missing variable changes everything. If you're scaling the consumer Lambda to handle the drain, doesn't that mean you're essentially paying for the compute somewhere anyway? The "bypass Lambda" idea seems to just shift the cost, not eliminate it.
Is the real cost savings just from avoiding cold starts during the burst, or am I still misunderstanding the math here?
One step at a time
You've nailed the core misconception. The "bypass" doesn't eliminate compute cost, it just reallocates it from the front door to the back.
The touted savings is specifically about avoiding Lambda's request-per-second limit and cold-start latency during the initial ingestion spike. You're trading that for SQS costs and the eventual, inevitable Lambda compute to process the messages.
So yes, you're paying for the compute somewhere. The question becomes whether you value smoothing the ingestion spike over the total bill. For many, the total cost ends up higher with this pattern.