Is it wrong to use a web framework with Lambda? Koki Miura(@k_miura_io)

INTRODUCTION • Koki Miura • Backend Engineer @Acall inc • Staff @JAWS UG Nagoya & Kobe • Favorite AWS Services：AWS IoT, Lambda, ECS

Can we use Lambda with web framework? Setting “ANY {proxy+}” in the API Gateway routing configuration enables routing of applications running within a Lambda function.

Lambda Deploy Pattern ZIP file Lambda Layer Container Web Adapter

ZIP File • Zipped function code with dependencies • Merit: Simple deploy • Demerit: Maximum size is 250MB when unzipped

Lambda Layer • Deploy dependencies as split layer • Merit: Share dependencies another application • Demerit: Maximum size is 250MB when unzipped with functions

Container • Deploy container image which based Lambda runtime • Merit: Maximum size is 10GB image • Demerit: Still need to set up the inputs and outputs to match the Lambda interface

Web Adapter • Rust based tool to run web applications on Lambda • Merit: Unnecessary arrange the inputs and outputs to match the Lambda interface • Demerit: Can be set up in either Layer or Container, but Layer may be more time-consuming. https://github.com/awslabs/aws-lambda-web-adapter

PERFORMANCE COMPARISON

Rule • There are 5 scenarios by deploy pattern • Lab1: Web framework app which deploy zip file • Lab2: Web framework app which uses layer of dependencies • Lab3: Web framework app which deploy container image • Lab4: Web framework app which uses web adapter • Lab5: Pure Lambda function app same web framework • All scenario’s uses Node.js runtime • Use Locust and perform a 5-minute load test assuming 100 people accessing the site. • Source code of these scenarios: https://github.com/Miura55/pankration2024_lambda_demos

Result Type Name Requests Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s GET /Prod/users 24029 915 43.35 21 1000 70.63 80.09 3.05 Lab1 (ZIP) Type Name Requests Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s GET /Prod/users 24049 1353 43.52 20 1094 69.97 80.16 4.51 Lab2 (Layer)

Type Name Requests Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s GET /Prod/users 24053 1497 42.3 20 769 69.76 80.18 4.99 Lab4 (Web Adapter) Type Name Requests Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s GET /Prod/users 24066 1200 41.87 21 1256 70.2 80.22 4 Lab3 (Cotainer) Type Name Requests Fails Average (ms) Min (ms) Max (ms) Average size (bytes) RPS Failures/s GET /Prod/users 24182 1065 37.5 19 1093 70.41 80.61 3.55 Lab5 (Pure Lambda)

From Result • Locust was being requested concurrently, and in both scenarios, the request was failing with an error when the Lambda concurrency limit was applied in the latter half of the request • Slow initial requests tended to result in failures in requests in the second half of the request Container Layer Zip Pure Lambda Faster Later Request Time

Conclusion • Container based application can execute computing with web adapter in Lambda • Container runtime takes time to cold-start longer • If you replace web framework application to Lambda, recommend to split function to pure Lambda

END