Effortlessly Juggling Multiple Concurrent Requests in AWS Lambda
--
Have you ever tried to handle a ton of requests at once with AWS Lambda? What if you had a critical operation that required speed, scaling the performance of a request down to single-digit milliseconds?
In a previous article, I discussed how to speed up your Lambda function, touching on the concept of a ‘cold start’ and how to minimize it by moving some non-critical code outside the Lambda handler, such as establishing a DB connection.
When we send a request to execute a Lambda function, the service initialises an execution environment. That’s a virtual machine (MicroVM) dedicated to each concurrent invocation of a Lambda function. Within this VM, there’s a kernel, a runtime (e.g. Node.js), function code, and extensions code. The cold start period includes creating this environment, initialising the runtime and extensions, and downloading the code. It also includes the execution of the ‘Init’ code (the code you write before the handler function).
With multiple consecutive executions, the Lambda service would reuse a previously created execution environment, and only execute the code within the handler function (that’s what we call warm start). That’s fascinating and would be sufficient in lots of cases. However, in some instances, we need to execute a single Lambda function concurrently. That would cause the creation of a new execution environment for each execution, which means that we cannot leverage the warm Lambda, and would need to experience the cold start for each invocation.
The solution in this case is to set up provisioned concurrency. Let’s test it.
Set up the project
We will build a simple project consisting of 2 Lambda functions, one orchestrator and one worker that will be invoked concurrently from the orchestrator Lambda.
Let’s create the infrastructure in Terraform:
- Create the IAM policies and roles that will be used by the Lambda functions
locals {
policy_document_cloudwatch = {
Version = "2012–10–17"…