Introduction to AWS Serverless Java Container (for Spring Boot 3)
The AWS Serverless Java Container makes it easier to run Java applications written with frameworks such as Spring, Spring Boot 2 and 3, or JAX-RS/Jersey in Lambda. We have already seen that Micronaut framework also uses AWS Serverless Java Container.
The container provides adapter logic to minimize code changes. Incoming events are translated to the Servlet specification so that frameworks work as before **.
AWS Serverless Java Container delivers the core container and framework-specific container, like one for Spring Boot 3, which is the area of our interest for this article. There are also other containers for Spring, Struts, and Jersey frameworks. The major update to version 2.0 has been recently released for all AWS Serverless Java Containers. If we look into the whole dependency tree, we'll discover another dependency spring-cloud-function-serverless-web that the artifact aws-serverless-java-container-springboot3 requires, which is the collaboration effort between Spring and AWS Serverless developers. It provides Spring Cloud Function on AWS Lambda functionality. We'll look deeper into the capabilities of Spring Cloud Function on AWS Lambda in one of my upcoming articles.
AWS Serverless Java Core Container also includes abstractions like AWSProxyRequest/Response for mapping of API Gateway (Rest) request to the Servlet model, including different authorizers like the Amazon Cognito and HttpApiV2JwtAuthorizer.
Then everything will be proxied internally in the core container through the AwsHttpServletRequest/Response abstractions or their derivatives like AwsProxyHttpServletRequest.
My personal wish is that a subset of abstractions, i.e., from the com.amazonaws.serverless.proxy.model package like
- AwsProxyRequest
- ApiGatewayRequestIdentity
- AwsProxyRequestContext
- AwsProxyResponse
and others will be a part of a separate project and therefore also used without the usage of all other AWS Serverless Java Container APIs, only for the purpose of mocking the API Gateway Request/Response (i.e., for Priming). I've already used them for Priming requests for Quarkus and Micronaut frameworks. Dependency to the AWS Serverless Java Container was included by default for the Micronaut on AWS Lambda SnapStart Priming example and needed to be added explicitly for the Quarkus on AWS Lambda SnapStart Priming example only to implement web request priming. We'll make use of these abstractions in one of our subsequent articles when we'll discuss cold and warm start time improvements for Spring Boot 3 application on AWS Lambda using AWS Lambda SnapStart in conjunction with priming techniques.
The Lambda runtime must know which handler method to invoke. For this AWS Serverless Spring Boot 3 Container, which internally uses AWS Serverless Java Core Container, adds only several implementations on top that like SpringDelegatingLambdaContainerHandler or implements our own handler Java class that delegates to AWS Serverless Java Container. This is useful if we want to implement additional functionality like the Lambda SnapStart priming technique. This can be done by using SpringBootLambdaContainerHandler abstraction (which inherits AwsLambdaServletContainerHandler from the core container), which can be created by giving a SpringBoot class that is annotated with @SpringBootApplication as an input. For Spring Boot 3 applications that take longer than 10 seconds to start, there is an asynchronous way of creating SpringBootLambdaContainerHandler by using SpringBootProxyHandlerBuilder abstraction. Since version 2.0.0, it always runs asynchronously by default. In the prior versions, we had to invoke the asyncInit method (which is now deprecated) to run the builder asynchronously. I'll provide a more detailed explanation about this with code examples in the next article of the series.
Conclusion
In this article, we introduced AWS Serverless Java Container components like core and framework-specific adaptors like for Spring Boot 3. In the next article of the series, we'll explore how to develop the Lambda functions using AWS Serverless Java Container (for Spring Boot), which receives the request from Amazon API Gateway and stores to and reads from Amazon DynamoDB.
** Re-platforming Java applications using the updated AWS Serverless Java Container
Update from February 13, 2025: new measurements with Spring Boot 3.4 and AWS Serverless Java Container version 2.1 published in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container.
Top comments (0)