5
votes

From the AWS Lambda FAQ:

Q: Is there a limit to the number of AWS Lambda functions I can execute at once?

No. AWS Lambda is designed to run many instances of your functions in parallel. However, AWS Lambda has a default safety throttle of 100 concurrent executions per account per region. If you wish to submit a request to increase the throttle of 100 concurrent executions you can visit our Support Center, click “Open a new case”, and file a service limit increase request.

Q: What happens if my account exceeds the default throttle limit on concurrent executions?

On exceeding the throttle limit, AWS Lambda functions being invoked synchronously will return a throttling error (429 error code). Lambda functions being invoked asynchronously can absorb reasonable bursts of traffic for approximately 15-30 minutes, after which incoming events will be rejected as throttled. In case the Lambda function is being invoked in response to Amazon S3 events, events rejected by AWS Lambda may be retained and retried by S3 for 24 hours. Events from Amazon Kinesis streams and Amazon DynamoDB streams are retried until the Lambda function succeeds or the data expires. Amazon Kinesis and Amazon DynamoDB Streams retain data for 24 hours.

What constitutes 'reasonable bursts' above? Does anyone have specific numbers?

3
This seems like a question for AWS support.Mark B
When you're doing capacity planning I would recommend that you don't consider "reasonable bursts" -- it's not guaranteed. I'd request limit increases that can handle your expected capacity with some headroom.Dave Maple

3 Answers

2
votes

Don't have specific hard numbers, but from day-to-day practice we've managed to have more than 1000 λ Invocations at a point of time.

We have an invoker lambda that is triggered via Kinesis Streams, the invoker lambda gets a batch of 10 records out of the stream, and invokes one worker lambda per record. Depending on how fast you get records into Kinesis it will trigger LOTS of worker lambdas:

Worker invokation count

It can trigger ~5000 at any point (and sustain it for a while) as long as we keep pushing events into Kinesis.

This same lambda can also be invoked via API Gateway. I would think that it could also handle the same kind of performance if there's no actual rate limiting set on the API Gateway. The lambda itself is the same.

Note that we are invoking the workers, the dispatcher function is the one that's triggered by Kinesis.

1
votes

Any form of bursting in AWS should never really be relied on for your production usage, this is different to things like CPU credits where there is a quantifiable allocation and recharge rate.

Essentially it's like the padding around the edges of a trampoline where if you happen to fall it will help you, but you still don't go diving on it just for fun :)

I would interpret this as being if the available resource is there then AWS will let you use it, but don't rely on it.

My suggestion is select a higher resource allocation for you lambda function that's more suitable to your workload, or break your workload up into smaller chunks for multiple lambdas, or consider moving your workload to EC2.

0
votes

Lambda does maintain an internal queuing mechanism and when you send requests more than your limit (default 100) then it will throttle your lambda calls and wait for your first 100 lambda functions to complete and go back to the available list and then call them for next request from the queue.

So there is no defined value of reasonable bursts. It depends on how fast your each lambda finish its job. In case you have more than 1000 request/sec and each lambda takes less than 10 secs then it could be able to handle them well but if each lambda execution takes more than 120 secs then it may throttle for some time but when its queue fill up then it will start rejecting the new request.