AWSLambdaJavaSnapStart VS aws-sdk-java-v2

To ensure reliability, Lambda manages multiple copies of each snapshot. Lambda automatically patches snapshots and their copies with the latest runtime and security updates. When we call the function version for the first time and as the calls increase, Lambda continues new execution environments from the cached snapshot instead of initialising them from scratch, which improves startup latency. More information can be found in the article Reducing Java cold starts on AWS Lambda functions with SnapStart. I have published the whole series about Lambda SnapStart for Java applications.

If you don't like to use APIGatewayProxyRequestEvent SnapStart priming, please also remove the dependency to aws-lambda-java-serialization in the pom.xml as it contributes additional 4.5 MB to the Lambda deployment artifact size.

You can find the source code in my pure-lambda-21 repo. I only updated dependencies in the pom.xml to use its recent versions.

You've probably already read my article series about AWS Lambda SnaptStart and know that I like to explore SnapStart priming techniques. In the next part of this article series, I'll explain how these flame graphs gave me some ideas about how to prime even more and therefore to reduce the cold starts of the Lambda function. Stay tuned !

The Z Garbage Collector. There are 2 different ZGC algorithms: default and the newer one- generational. You can set it explicitly in AWS SAM template by adding -XX:+UseZGC or -XX:+UseZGC -XX:+ZGenerational to the JAVA_TOOL_OPTIONS environment variable.

AWS Lambda SnapStart which significantly reduces cold start times is currently only available for Java Corretto managed runtimes (11, 17 and 21) and not for Docker container images. You can explore jlink tool to assemble and optimize a set of modules and their dependencies into a smaller custom runtime image and Class data sharing (CDS) though which helps reduce the startup time for Java programming language applications, in particular smaller applications, as well as reduce footprint. The advantage of using the Docker Image as deployment artifact for Java is the ability to use recent Java runtime like Java 23 which will be released in September.

In pom.xml you see all dependencies with the scope provided (by the Lambda layer attached).

In our experiment we'll use the sample application. There are basically 2 Lambda functions defined in the AWS SAM template which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function GetProductByIdWithPureJava21LambdaWithCommonLayer can be used with and without SnapStart and the second one GetProductByIdWithPureJava21LambdaAndPrimingWithCommonLayer uses SnapStart and DynamoDB request invocation priming.

For the sake of exploration we'll use the sample application for creating the Lambda layer with Java 21 runtime packaging the following dependencies into the layer :

In our experiment we'll re-use the application introduced in part 8 for this and rewrite it to use asynchronous HTTP client. You can the find application code here. There are basically 2 Lambda functions which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function GetProductByIdWithPureJava17AsyncLambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava17AsyncLambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We give both Lambda functions 1024 MB memory.

Thankfully most of the AWS SDK uses interfaces[1] so one can use Mockito if you already have the muscle memory with it, or its InvocationHandler friend[2] if truly customized responses are needed

If one needs to exercise the AWS SDK itself, as part of some repo steps for a support issue, it's similarly glucose-cheap to patch moto to 500 in the necessary circumstances. I've had good luck using their ExecutionInterceptor ServiceLoader mechanism[3] to patch the Client's endpoint URI to point to moto or localstack without having to monkey with every single Client instantiation, which can be especially no-fun for STS AssumeRole or AssumeRoleWithWebIdentity setups (since one doesn't want it to use real STS for anything). That way the actual SDK pathway is still exercised all the way into the caller's code for a more honest-to-goodness bad outcome but without the hope-and-pray of contacting real S3

1: e.g. https://sdk.amazonaws.com/java/api/2.29.16/software/amazon/a...

2: https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

3: https://github.com/aws/aws-sdk-java-v2/blob/2.29.17/core/sdk...

In this article we'll now add another dimension to our measurements : the choice of HTTP Client implementation. This is also interesting, because starting from AWS SDK for Java version 2.22 AWS added support for their own implementation of the synchronous CRT HTTP Client. The asynchronous CRT HTTP client has been generally available since February 2023. In this article we'll explore synchronous HTTP clients first and leave asynchronous ones for the next article.

The updates could be parsed from the github repo's CHANGELOG files (ex: javascript, java, python). I'm picturing an RSS feed generated for a specific language and module (ex: python s3, javascript s3, java sqs)

Meanwhile the [SDK doesn't provide samples or an API for USER_SRP_AUTH AuthFlow](https://github.com/aws/aws-sdk-java-v2/issues/2851). (I don't think that's the right choice, anyway, because if I'm right I'd have to register my user in my new app, and I don't want to do that).

Bonus: AWS SDK for Java v2 - this one I'm not sure of their reasons, but this request to add nullability annotations was filed 4.5 years ago, and there has been virtually no movement or feedback on it, so I can only speculate about their reasons for not fixing this.

If you think its a genuine bug in the API or the client somehow I think opening an issue in the github repo for the sdk might be a good place to start https://github.com/aws/aws-sdk-java-v2/issues .

Should be possible to just issue a GetObject with a range for the initial request skipping a head request. See here for caveats about how the Content Range data is returned in the response header: https://github.com/aws/aws-sdk-java-v2/issues/1209

V2 AWS SDK for Dynamo DB, SNS, and SQS

DynamoDB mapper AWS SDK v2 readme