Introduction
During the parts 2, 3 and 4 we introduced the concepts behind the AWS Serverless Java Container and especially its variant for the Spring Boot (3) application, learned how to develop, deploy, run and optimize Spring Boot 3 Application on AWS Lambda using AWS Serverless Java Container. In this part of the series we'll introduce another alternative, the tool called AWS Lambda Web Adapter and the concepts behind it.
AWS Lambda Web Adapter
AWS Lambda Web Adapter is a tool written in Rust programming language (which is very fast) to run web applications on AWS Lambda. It allows developers to build web apps (HTTP API) with familiar frameworks (e.g. Express.js, Next.js, Flask, Spring Boot, ASP.NET and Laravel, anything that 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 *.
To its most important features belong :
-Run web applications on AWS Lambda
-Supports Amazon API Gateway Rest API and Http API endpoints, Lambda Function URLs, and Application Load Balancer
-Supports Lambda managed runtimes, custom runtimes and docker OCI images
-Supports any web frameworks and languages, no new code dependency to include
-Automatic encode binary response
-Enables graceful shutdown
-Supports response payload compression
-Supports response streaming as Lambda Web Adapter invoke mode. The default mode is "buffered". When configured as "response_stream", Lambda Web Adapter will stream response to Lambda service. This makes sense to use to reduce the time to first byte when a big file or video will be streamed to the client. You can read a deep dive to this feature here and here. Using response streaming we can bypass AWS Lambda service quota for the maximum size of an incoming synchronous invocation request or outgoing response which is 6 MB.
-Supports non-http event triggers. It supports all non-HTTP event triggers, such as SQS, SNS, S3, DynamoDB, Kinesis, Kafka, EventBridge, and Bedrock Agents.
-Supports readiness check port/path and traffic port can be configured using environment variables. 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 retry this request every 10 milliseconds until the web application returns an HTTP response (status code >= 100 and < 500) or the function times out. After passing readiness check, Lambda Web Adapter will start Lambda Runtime and forward the invokes to the web application.
-Supports local debugging. Lambda Web Adapter allows developers to develop web applications locally with familiar tools and debuggers: just run the web app locally and test it. If we want to simulate Lambda Runtime environment locally, we can use AWS SAM CLI with sam local command.
You can find a very good introduction video to the AWS Lambda Web Adapter which Harold Sun gave at the Re:Invent 2023.
AWS Lambda Web Adapter can be deployed in several ways:
-Lambda functions packaged as Docker Images
-Lambda functions packaged as OCI Images
-Lambda functions packaged as Zip package for AWS managed runtimes and attached as Lambda layer to your Lambda function. This is how we'll deploy AWS Lambda Web Adapter for our sample Spring Boot 3 application in the next part of the series.
Conclusion
In this part of the series, we introduced AWS Lambda Web Adapter and concepts behind it. In next part we'll learn how to develop deploy and run the Serverless application (on AWS Lambda) using this tool.
*Source AWS Lambda Web Adapter