Introduction
During the part 2, part 3, and part 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 the 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 (i.e., Express.js, Next.js, Flask, Spring Boot, ASP.NET, and Laravel, anything that speaks HTTP 1.1/1.0) and run them on AWS Lambda. The same Docker image can run on AWS Lambda, Amazon EC2, AWS Fargate, and local computers *.
Among its most important features are:
-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, with 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", the Lambda Web Adapter will stream the response to the 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 into 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, the 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 the readiness check, the Lambda Web Adapter will start the Lambda Runtime and forward the invocations 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 a Lambda Runtime environment locally, we can use AWS SAM CLI with the 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 a Zip package for AWS managed runtimes and attached as a 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 the concepts behind it. In the next part of the series, we'll learn how to develop, deploy, and run the Serverless application (on AWS Lambda) using this tool.
*Source AWS Lambda Web Adapter
Update from February 17, 2025: new measurements with Spring Boot 3.4 and AWS Lambda Web Adapter published in the article Spring Boot 3.4 application on AWS Lambda- Part 2 AWS Lambda Web Adapter.
Top comments (0)