Lambda Concurrency Calculator for AWS Sizing

In the past, trying to handle sudden bursts of serverless traffic felt like playing the lottery. You launch that cool new feature, see your log files start filling up with throttling errors, and rush to increase your limits before your users complain. It’s been a game of guessing and hoping you’re right.

The underlying issue isn’t so much “does Lambda work well” under ordinary circumstances, but what happens when reality no longer resembles your test environment. How many concurrent executions will likely occurs at the same time? It is not about number of requests per second. On paper, it seems straightforward: the basic math. Steady state concurrency is (requests per second) x (average execution duration).

Why Your Serverless App Fails During Traffic Bursts

But very few production systems spends their time in this neat little steady state. Production systems have backlogs from previous outages that is still eking their way through the system. They have tails and they have retries. And most estimates break down there. Plan for the average. Then one day when you see a burst, you’ll hit the wall because you didn’t account for all those slow ones that built up on top of each other.

This is easier to visualize if we use the calculator above. It will take your baseline traffic and multiply that by your p95 duration, which is how long those requests last. How long those requests last), which blows up your concurrency requirements on short bursts. Then it adds back async backlog draining rates + retries to show the overall load being thrown at your functions. It doesn’t spit out just “steady state” number, either. It breaks apart the burst requirement vs background noise, and shows you where the bottlenecks are forming… Because the way you prevent a bottleneck is different than the way you fix one.

Retries are the silent killer of concurrency planning. It’s tempting to think “A few failed requests won’t hurt”. Then you realize they’re automatically retried and now you’ve doubled (or tripled) your load within a few seconds. That’s a multiplier effect, something the calculator takes into account so you can visualize how much additional capacity you’ll need just to survive a minor hiccup from one of your downstream systems. Even a healthy function can throttle itself if its retry rate is too aggressive. Resilience vs. Resource exhaustion: you gotta balance these two things.

And then there’s asynchronous backlogs. This means when your events stack up in EventBridge and SQS, they don’t dissapears. Instead, they sit in a queue awaiting some available room to process them, but that same room is required to process new traffic too. To process all those backlog event, it needs dedicated concurrency; concurrency that could otherwise serve real-time requests. Unless you account for the rate at which the backlog drains, your system will either throttle new users attempting to reach the front of the queue, or it’ll hang around processing old stuff forever.

The calculator assumes this backlog is actualy traffic demand, so you need to decide how fast you want to empty the queue vs. You must decide how much spare capacity to reserve for spike periods. The levers you have to manage this are reserved and provisioned concurrency. Reserved concurrency provides a hard ceiling: it won’t let one runaway handler starve other functions. Provisioned concurrency eliminates cold starts by keeping your environments warm. This is critical for latency sensitive paths, but it is very expensive if applied indiscriminately.

The tool’s reference tables gives clues as to how they interact across different types of workloads such as batch ETL jobs vs API gateways. While an authentication callback can’t afford a few extra milliseconds of cold start time, an image processing job probably could. The calculation is also different depending on what runtime you choose: In certain configurations, languages like Go and Node.js are generally more adept at handling warm-up vs. This affects how much starting capacity you must set up to provide smooth service.

The less well your language starts up, the greater the cost of getting concurrency wrong, each cold start consumes a chunk of available slots, resulting in longer wait times for answers. The takeaway: Properly sizing Lambda is not about optimizing for the average. It is about managing variance by getting your headroom just right. You need room to spare for those inevitable bursts, but you should of have no extra cost when things are quiet.

The calculator above does the heavy math for you, while you figure out the right retry strategy and set some smart throttle limits. Once you get your head around how backlogs, retries and duration compound each other, throttling isn’t such a black art anymore; it’s just another engineering problem that’s solvable.