AWS Lambda SnapStart - Part 8 Measuring Java 17 Lambda cold starts

Introduction

In the part 7 of our series we re-measured the cold start of the Lambda function with Corretto Java 11 runtime and SnapStart enabled after AWS fixed the "Restore Duration" time displayed in the CloudWatch (Logs). You can refer to the part 7 to review the results of our measurements. As SnapStart is also supported with Java 17 runtime directly from the beginning I was curious what cold start we will get with Java 17 with SnapStart enabled.

Measuring the cold start times with Java 17 and SnapStart enabled

For measurement purposes I created/copied the sample application and configured Lambda functions to use Java 17 runtime for Lambda and 1024 MB memory .

Now we use the same CloudWatch Logs Insights Query as we used in the part 7 of our series. We also enable SnapStart for both our Lambda functions GetProductByIdWithPureJava17Lambda (without priming) and GetProductByIdWithPureJava17LambdaAndPriming (with priming of DynamoDB invocation) and after approximately 100 cold starts we got the following durations:

Conclusion

For the cold start times measured with Java 11 and Java 17 runtimes with SnapStart enabled and additionally with and without priming of DynamoDB invocation we got very comparable results. For some percentiles Java 17 cold starts were a bit lower, but this may depend on the executed measurements. This was also my expectation before I started these measurements as SnapStart is based on the whole Firecracker microVM snapshot create and restore phases. And the latter phase is occurring during the cold start of the Lambda function and will probably take similar amount of time independent on the Java runtime version used as JVM restore is only a part of the whole microVM restore. In the next article of series I’d like to share some thoughts on how AWS can further improve its offering around reducing cold starts on AWS Lambda with Java Runtime and also developer experience.