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?
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:
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With