A tool to run web applications on AWS Lambda

AWS Lambda Web Adapter allows developers to build web apps (http api) with familiar frameworks (e.g. Express.js, Next.js, Flask, SpringBoot, and Laravel, anything speaks HTTP 1.1/1.0) and run it on AWS Lambda. The same docker image can run on AWS Lambda, Amazon EC2, AWS Fargate, and local computers.

AWS Lambda Web Adapter is developed as a Lambda extension (since v0.2.0). For details, checkout its design and development documents.

AWS Lambda Web Adapter work with Lambda functions packaged as both docker images and Zip packages.

To use Lambda Web Adapter with docker images, package your web app (http api) in a Dockerfile, and add one line to copy Lambda Web Adapter binary to /opt/extensions inside your container. By default, Lambda Web Adapter assumes the web app is listening on port 8080. If not, you can specify the port via configuration.

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.3.3 /lambda-adapter /opt/extensions/lambda-adapter

Pre-compiled Lambda Web Adapter binaries are provided in ECR public repo: public.ecr.aws/awsguru/aws-lambda-adapter. Multi-arch images are also provided in this repo. It works on both x86_64 and arm64 CPU architecture.

Below is a Dockerfile for an example nodejs application.

FROM public.ecr.aws/docker/library/node:16.13.2-stretch-slim
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.3.3 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=7000
WORKDIR "/var/task"
ADD src/package.json /var/task/package.json
ADD src/package-lock.json /var/task/package-lock.json
RUN npm install --production
ADD src/ /var/task
CMD ["node", "index.js"]

This works with any base images except AWS managed base images. To use AWS managed base images, you need to override the ENTRYPOINT to start your web app.

AWS Lambda Web Adapter also works with AWS managed Lambda runtimes. You need to do three things:

1. attach Lambda Web Adapter layer to your function.
   1. x86_64: arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerX86:3
   2. arm64: arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerArm64:3
2. configure Lambda environment variable AWS_LAMBDA_EXEC_WRAPPER to /opt/bootstrap.
3. set function handler to your web application start up script. e.g. run.sh.

For details, please check out the example nodejs application.

When a new Lambda Execution Environment starts up, Lambda Web Adapter will boot up as a Lambda Extension, followed by the web application.

Lambda Web Adapter will send HTTP GET requests to the web application at http://127.0.0.1:{READINESS_CHECK_PORT}{READINESS_CHECK_PATH}.

Lambda Web Adapter will retry this request every 10 milliseconds until the web application returns a successful response (http status code 2xx) or the function times out.

After passing readiness check, Lambda Web Adapter will start Lambda Runtime and forward the invokes to the web application.

The readiness check port/path and traffic port can be configured using environment variables. These environment variables can be defined either within docker file or as Lambda function configuration.

ASYNC_INIT Lambda managed runtimes offer up to 10 seconds for function initialization. During this period of time, Lambda functions have burst of CPU to accelerate initialization, and it is free. If a lambda function couldn't complete the initialization within 10 seconds, Lambda will restart the function, and bill for the initialization. To help functions to use this 10 seconds free initialization time and avoid the restart, Lambda Web Adapter supports asynchronous initialization. When this feature is enabled, Lambda Web Adapter performs readiness check up to 9.8 seconds. If the web app is not ready by then, Lambda Web Adapter signals to Lambda service that the init is completed, and continues readiness check in the handler. This feature is disabled by default. Enable it by setting environment variable ASYNC_INIT to true.

REMOVE_BASE_PATH - The value of this environment variable tells the adapter whether the application is running under a base path. For example, you could have configured your API Gateway to have a /orders/{proxy+} and a /catalog/{proxy+} resource. Each resource is handled by a separate Lambda functions. For this reason, the application inside Lambda may not be aware of the fact that the /orders path exists. Use REMOVE_BASE_PATH to remove the /orders prefix when routing requests to the application. Defaults to empty string. Checkout SpringBoot example.

• Flask
• Express.js
• Express.js in Zip
• Next.js
• Next.js in Zip
• SpringBoot
• SpringBoot in Zip
• nginx
• php
• rust axum

This project was inspired by several community projects.

• re:Web
• Serverlessish

See CONTRIBUTING for more information.

This project is licensed under the Apache-2.0 License.