Lambda, containerize or not?

When implementing AWS Lambda functions, a common challenge is deciding on the most efficient deployment method. In the tech stacks I've worked with, Docker is heavily utilized, making it seem logical to deploy Lambda functions as container images via Amazon ECR to streamline deployment processes. However, concerns have been raised about potential increases in cold start times and performance overhead when using container images, suggesting that deploying functions as ZIP archives might be more efficient. This prompted me to investigate: Is deploying Lambda functions using container images significantly slower, and what potential issues could this approach entail?

To explore this, I conducted tests using two different scenarios with varying Lambda memory sizes (since a Lambda's memory size is correlated with its allocated virtual CPU):

• A simple "hello world" function to test cold start times.

• A function that returns all the prime numbers from the first 100,000 positive integers to test CPU-intensive tasks.

In deploying the AWS Lambda functions, I utilized both Docker images from Amazon ECR and ZIP archives. While both methods are relatively straightforward to set up, deploying via ECR introduces more initial overhead. ZIP uploads are limited to 50 MB (unzipped) without using S3 and up to 250 MB (unzipped) if utilizing S3. For larger packages, Lambda layers can be used to handle dependencies when using the ZIP method. On the other hand, conatiner images via ECR support sizes up to 10 GB, making them ideal for larger deployments.

The testing was conducted using AWS Lambda Power Tuning to invoke the function multiple times with varying memory sizes allocated to the Lambda. Each memory configuration was run 50 times, and the average execution time was calculated. The invocation times in Figure 1 exclude cold start times. As shown in Figure 1, the Lambdas deployed using container images and ZIP archives perform almost identically in terms of invocation time when cold starts are excluded. This indicates that, for the runtime of the function, there is no clear advantage to using a ZIP archive over a container image.

However, when considering cold start times, there is a noticeable trend: container image cold starts are almost twice as long as those for ZIP archives. This is expected, as the Lambda service needs to fetch the container image from ECR during cold starts. Another important factor is cost. In the case of ZIP-deployed Lambdas, you are not charged for the cold start time, whereas with container-deployed Lambdas, you are billed for the entire initialization phase, including the cold start. This cost can accumulate, especially if your Lambdas are deployed in a fan-out pattern where each individual Lambda must cold start. In the container scenario, you would pay for the initialization phase of each of these Lambdas.

Conclusion

Deploying AWS Lambda functions using containers via ECR offers advantages in supporting larger package sizes and aligning with container-centric workflows. However, this approach comes with trade-offs in cold start performance and cost. The increased cold start times associated with container images can impact user experience, particularly for latency-sensitive applications. Additionally, being billed for the entire initialization phase when using container-deployed Lambdas can lead to higher operational costs, especially in architectures involving frequent cold starts or numerous functions.

Conversely, deploying Lambda functions as ZIP archives provides faster cold start times and avoids the additional costs associated with the initialization phase. Therefore, if your application is sensitive to cold start latency or cost and does not require the larger package size that container images support, deploying Lambda functions as ZIP archives may be the more efficient choice. Ultimately, the decision should be based on the specific needs of your application, weighing the benefits of containerization against the potential performance and cost implications.