Forem: Vadym Kazulkin

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 6 Using GraalVM Native Image

Vadym Kazulkin — Wed, 22 Apr 2026 14:02:36 +0000

Introduction

In part 1, we introduced our sample application. In parts 2-5, we measured Lambda function performance using different approaches:

without activation of Lambda SnapStart
with activation of Lambda SnapStart, but without using any priming techniques
with activation of Lambda SnapStart and using different priming techniques

We observed that by activating the SnapSart and applying different priming techniques, we could significantly further reduce the Lambda cold start times. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could significantly reduce the maximal value for the Lambda warm start times.

In this article, we'll introduce another approach to improve the performance of the Lambda function - GraalVM Native Image.

GraalVM Native Image

This article assumes prior knowledge of GraalVM and its native image capabilities. For a concise overview of them and how to get both installed, please refer to the following articles: Introduction to GraalVM, GraalVM Architecture, and GraalVM Native Image or read my article Introduction to GraalVM and its native image capabilities.

To install GraalVM and native image, please follow the instructions in the article Installing GraalVM. In my example, I used the 25.0.2-graal version, but you can use the newest one.

Sample application with JDBC and Hikari connection pool using GraalVM Native Image

We'll reuse the sample application from part 1, but adjust it. The goal is to be able to build GraalVM Native Image and deploy it on AWS Lambda as a Custom Runtime.

Here is the final version of the aws-lambda-java-25-aurora-dsql-as-graalvm-native-image application.

Let's go step-by-step through the changes compared to the initial application from part 1. The business logic (Entity, ProductDao, and the Lambda handlers) remains completely the same. All changes are made in the pom.xml, AWS SAM template, and by providing additional GraalVM configuration.

Making sample application GraalVM Native Image capable

For our sample application to run as a GraalVM Native Image, we need to declare all classes whose objects will be instantiated by reflection. These classes needed to be known by the AOT compiler at compile time. This happens in reflect-config.json. As we can see, we need to declare there the following:

all our Lambda functions like GetProductByIdHandler] and CreateProductHandler
entities like Product that Jackson converts from JSON payload and back
APIGatewayProxyRequestEvent and all its inner classes because we declared this event type as a request event in our Lambda functions, like GetProductByIdHandler and CreateProductHandler
org.joda.time.DateTime, which will be used to convert a timestamp from a string and back. Such a timestamp is a part of the API Gateway proxy request and response events. In my opinion, it's time to switch from Joda-Time to the Java Date/Time API for this.
classes for Hikari Connection Pool creation (HikariConfig, HikariDataSource, ConcurrentBag$IConcurrentBagEntry[])

There are multiple ways, how, and where to define GraalVM Native configuration, like reflection configuration. For this, I refer you to the article Build a Native Executable with Reflection.

We used these ways to define reflection configuration for the dependencies in use : postgresql and aurora-dsql-jdbc-connector. Many providers of the open source libraries ship this configuration for the GraalVM metadata directly. Unfortunately, not all of them do it, so we don't need to define it on our own.

To avoid errors with Loggers during the initialization described in the article Class Initialization in Native Image, we need to add GraalVM Native Image build arguments in the native-image.properties:

Args=--allow-incomplete-classpath \
    --initialize-at-build-time=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory
    -- --trace-class-initialization=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory

The native-image.properties should be placed in the META-INF/native-image/${MavenGroupIid}/${MavenArtifactId}.

As we use slf4j-simple Logger in our application, we need to place native-image.properties in the path META-INF/native-image/org.slf4j/slf4j-simple.
If you use another Logger implementation (e.g., log4j or logback), you need to adjust this file and place it accordingly.

Also, by default, no resources (schemas, services, and others) will be a part of the native image. We need to define them manually. There are multiple ways to Include Resources in Native Image . We have to place them in the resource-config.json file in the META-INF/native-image/${MavenGroupIid}/${MavenArtifactId}. We need it to include the file containing the correct implementation of the java.sql.Driver. In our case, it's aurora-dsql-jdbc-connector. We defined it in the following resource-config.json.

To save the manual work of defining all this metadata, you can use GraalVM Tracing Agent to generate it for you.

Lambda Custom Runtime

There is no managed GraalVM (Native Image) on AWS Lambda. To deploy the native image on AWS Lambda, we need a custom runtime. For this, we need to package everything into a file with a .zip extension, which includes the file with the name bootstrap. This file can either be the GraalVM Native Image or contain instructions on how to invoke the GraalVM Native Image placed in another file. We'll use the latter way; let's explore it.

Building GraalVM Native Image

We'll build GraalVM Native Image automatically in the package phase defined in the pom.xml. The relevant part is defined in the following plugin:

<plugin>
   <groupId>org.graalvm.nativeimage</groupId>
   <artifactId>native-image-maven-plugin</artifactId>
   <version>21.2.0</version>
   <executions>
       <execution>
           <goals>
           <goal>native-image</goal>
       </goals>
        <phase>package</phase>
      </execution>
   </executions>
   <configuration>
      <skip>false</skip>              
       <mainClass>
           com.formkiq.lambda.runtime.graalvm.LambdaRuntime
       </mainClass>
       <imageName>
           aws-lambda-java-25-with-aurora-dsql-as-graalvm-native-image 
       </imageName>
       <buildArgs>
         --no-fallback
         --enable-http
         -H:ReflectionConfigurationFiles=../src/main/reflect-config.json
      </buildArgs>
   </configuration>
</plugin>

We use native-image-maven-plugin from org.graalvm.nativeimage tools and execute native-image in the package phase. You can also use the alternative native-maven-plugin plugin, whose configuration is very similar. This plugin requires the definition of the main class, which a Lambda function doesn't have. That's why we use Lambda Runtime GraalVM and define its main class com.formkiq.lambda.runtime.graalvm.LambdaRuntime. Lambda Runtime GraalVM is a Java library that makes it easy to convert AWS Lambda written in the Java programming language to the GraalVM. We defined it previously in pom.xml as a dependency:

<dependency>
   <groupId>com.formkiq</groupId>
   <artifactId>lambda-runtime-graalvm</artifactId>
   <version>2.6.0</version>
</dependency>

We then give the native image name aws-lambda-java-25-with-aurora-dsql-as-graalvm-native-image (the default one will also be an artifact name). After it, we include some GraalVM Native Image arguments and previously defined reflection-config.

<buildArgs>
    --no-fallback
    --enable-http
   -H:ReflectionConfigurationFiles=../src/main/reflect-config.json
</buildArgs>

To zip the built GraalVM Native Image as function.zip required by Lambda Custom Runtime, we use the maven-assembly plugin:

<plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <executions>
            <execution>
                  <id>native-zip</id>
                  <phase>package</phase>
                  <goals>
                        <goal>single</goal>
                  </goals>
                  <inherited>false</inherited>
            </execution>
      </executions>
      <configuration>
            <finalName>function</finalName>
            <appendAssemblyId>false</appendAssemblyId>
            <descriptors>
                  <descriptor>src/assembly/native.xml</descriptor>
            </descriptors>
      </configuration>
</plugin>

The finalName is the name of the zip file, in our case, function. We also include native.xml descriptor:

<assembly>
    <id>native-zip</id>
    <formats>
        <format>zip</format>
    </formats>
  <baseDirectory/>
    <fileSets>
        <fileSet>
            <directory>src/shell/native</directory>
            <outputDirectory>/</outputDirectory>
            <useDefaultExcludes>true</useDefaultExcludes>
            <fileMode>0775</fileMode>
            <includes>
                <include>bootstrap</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>target</directory>
            <outputDirectory>/</outputDirectory>
            <useDefaultExcludes>true</useDefaultExcludes>
            <fileMode>0775</fileMode>
            <includes>
                <include>aws-lambda-java-25-with-aurora-dsql-as-graalvm-native-image</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

This descriptor defines what files from which directories with what permissions will be added to the zip as an assembly format. fileMode equal to 0775 means it has permission to be executable on the Linux operating system. We include previously built GraalVM Native Image with the name aws-lambda-java-25-with-aurora-dsql-as-graalvm-native-image there. We also include the already defined bootstrap file, which basically invokes the GraalVM Native Image :

#!/bin/sh

cd ${LAMBDA_TASK_ROOT:-.}

./aws-lambda-java-25-with-aurora-dsql-as-graalvm-native-image

In the end, we have to build GraalVM Native Image packaged as a zip file, which can be built as a Lambda Custom Runtime with mvn clean package.

Deploying GraalVM Native Image as a Lambda Custom Runtime

In the AWS SAM template, we set the Lambda runtime as provided.al2023, which is the newest version of the custom runtime, and provide the path to the previously built GraalVM Native Image as target/function.zip.

Globals:
  Function:
    CodeUri: target/function.zip
    Runtime: provided.al2023

Now we are ready to deploy our application with sam deploy -g.

Measurements of cold and warm start times of the Lambda function of the sample application with JDBC and Hikari connection pool using GraalVM Native Image

We'll measure the performance of the GetProductById Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQGVNI25" https://{$API_GATEWAY_URL}/prod/products/1.

We designed the experiment exactly as described in part 2.

I did the measurements with provided:al2023.v124 version, and the deployed artifact size of this application was 20.459 KB.

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Custom Runtime with GraalVM Native Image	629	802	885	943	945	946	4.65	5.16	5.64	9.16	136.50	668

Sample application with Hibernate and Hikari connection pool and using GraalVM Native Image

The same is true for the sample application using JDBC instead of Hibernate. We'll reuse the sample application from part 1, but adjust it. The goal is to be able to build GraalVM Native Image and deploy it on AWS Lambda as a Custom Runtime.

Here is the final version of the aws-lambda-java-25-hibernate-aurora-dsql-as-graalvm-native-image application.

Making sample application GraalVM Native Image capable

Many steps (creating a native image zip, building, and deploying) described above are implemented in exactly the same way. Additional complexity comes from using the Hibernate framework, which doesn't ship native image metadata. Also, Hibernate comes with a lot of internal loggers, which usually don't play well with the native image. It took me a lot of time to figure out the required GraalVM metadata (native-image.properties and reflect.json). You can review them here. I also had to include the whole package org.hibernate.event.spi into the native image, see -H:Preserve=package=org.hibernate.event.spi in the native image configuration in the pom.xml.

It's probable that if you update the Hibernate version in use, something will break. And as a result, you'll need to adjust the native image metadata, for example, by re-running the GraalVM Tracing Agent to generate them for you.

Building GraalVM Native Image

The biggest challenge was the fact that Hibernate uses Byte Buddy. Byte Buddy is a code generation and manipulation library for creating and modifying Java classes during the runtime of a Java application, without the help of a compiler. This obviously doesn't work at runtime in the GraalVM native image. Hibernate also ships no-op org.hibernate.bytecode.internal.none.BytecodeProviderImpl, but for many versions, it doesn't allow its configuration from outside. The Byte Buddy implementation was always found in the classpath and broke at runtime. Frameworks like Quarkus and Spring Boot can do this magic with the AOT, but as I don't use them, I was seeking the possibilities of how to solve it. Please, read my discussion in the Hibernate forum.

Even if I'm not very happy with the solution, which feels more like a workaround, I'll describe how I solved it.

I first defined org.hibernate.bytecode.spi.BytecodeProvider with a no-op bytecode implementation in my application. Then I built the uber-jar with maven-shade-plugin. With that, I saw that it, of course, flattens META-INF/services and puts all service files into one shared META-INF/services folder, so that only one file per service can be there. And it indeed by default puts the org.hibernate.bytecode.spi.BytecodeProvider from my application with a no-op implementation, which I defined there. But even if it would put the ByteBuddy implementation from the hibernate-core dependency, I could use the filtering feature of the maven-shade-plugin to exclude it in pom.xml:

<filters>
   <filter>
      <artifact>*:*</artifact>
      <excludes>
         <exclude>META-INF/services/org.hibernate.bytecode.spi.BytecodeProvider
      </exclude>
   </excludes>
 </filter>
</filters>

I then also need to include the no-op byte implementation in the resource-config.json.

This will then default to no-op implementation if ServiceLoader doesn’t find any implementation. Now, to build the GraalVM Native Image from the uber-jar, I had to use the native-maven-plugin Maven plugin pom.xml because it supports classpath definition:

<plugin>
   <groupId>org.graalvm.buildtools</groupId>
   <artifactId>native-maven-plugin</artifactId>
   ....
   <configuration>
     <classpath>
        <param>         
             ${project.build.directory}/${project.artifactId}-${project.version}.jar
      </param>
     </classpath>
   </configuration>
 ....
</plugin>

This is how the native-maven-plugin Maven plugin configuration looks in pom.xml with all changes that I described above:

<plugin>
   <groupId>org.graalvm.buildtools</groupId>
   <artifactId>native-maven-plugin</artifactId>
   <version>0.11.4</version>
   <configuration>
        <mainClass>com.formkiq.lambda.runtime.graalvm.LambdaRuntime</mainClass>
         <imageName>aws-lambda-java-25-with-hibernate-and-aurora-dsql-as-graalvm-native-image</imageName>
          <buildArgs>
             <buildArg> --no-fallback </buildArg>
             <buildArg> --enable-http </buildArg>
             <buildArg> -H:ReflectionConfigurationFiles=src/main/reflect-config.json </buildArg>
             <buildArg> -H:ResourceConfigurationFiles=src/main/resource-config.json </buildArg>
             <buildArg> -H:Preserve=package=org.hibernate.event.spi </buildArg>
          </buildArgs>
          <classpath>
          <param>                   
    ${project.build.directory}/${project.artifactId}-${project.version}.jar
          </param>
      </classpath>
     </configuration>
  ....      
</plugin>

Measurements of cold and warm start times of the Lambda function of the sample application with Hibernate and Hikari connection pool using GraalVM Native Image

We'll measure the performance of the GetProductById Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEHDQGVNI25" https://{$API_GATEWAY_URL}/prod/products/1.

We designed the experiment exactly as described in part 2.

I did the measurements with provided:al2023.v124 version, and the deployed artifact size of this application was 33.377 KB.

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Custom Runtime with GraalVM Native Image	945	995	1115	1192	1214	1215	4.69	5.04	5.42	9.38	38.76	300

Conclusion

In this part of the series, we first introduced GraalVM Native Image. Then we explained step-by-step how to convert the sample applications to those where the native image can be built. When we deployed the native image on AWS Lambda using the Lambda Custom Runtime. Finally, we measured the performance of the Lambda function. We observed that the cold and warm start times vary compared to using the Lambda SnapStart. Sometimes GraalVM, sometimes SnapStart provides better performance. Sometimes it depends on which priming techniques we use, see the measurements table in part 5. On the other hand, creating a Native Image is not for free, as we need to scale CI/CD pipeline to build a native image. Building it requires many GBs of memory, and the process takes many minutes depending on the hardware. Creating a full set of the Native Image metadata, even using GraalVM Tracing Agent, means introducing additional complexity. Lambda SnapStart, on the other hand, is fully managed. Especially if we use Hibernate in our application without using any frameworks (Spring Boot, Quarkus) on top, it makes things very complicated. That's why I'd advocate against using Hibernate alone in such scenarios.

We'll compare both approaches in one of the next articles.

Please also watch out for another series where I use a NoSQL serverless Amazon DynamoDB database instead of Aurora DSQL to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and DynamoDB - Part 6 Using GraalVM Native Image

Vadym Kazulkin — Mon, 20 Apr 2026 16:31:10 +0000

Introduction

In part 1, we introduced our sample application. In parts 2-5, we measured Lambda function performance using different approaches:

without activation of Lambda SnapStart
with activation of Lambda SnapStart, but without using any priming techniques
with activation of Lambda SnapStart and using different priming techniques

In this article, we'll introduce another approach to improve the performance of the Lambda function - GraalVM Native Image.

GraalVM Native Image

To install GraalVM and native image, please follow the instructions in the article Installing GraalVM. In my example, I used the 25.0.2-graal version, but you can use the newest one.

Sample application using GraalVM Native Image

We'll reuse the sample application from part 1, but adjust it. The goal is to be able to build GraalVM Native Image and deploy it on AWS Lambda as a Custom Runtime.

Here is the final version of the aws-lambda-java-25-dynamodb-as-graalvm-native-image application.

Making sample application GraalVM Native Image capable

all our Lambda functions like GetProductByIdHandler] and CreateProductHandler
entities like Product that Jackson converts from JSON payload and back
APIGatewayProxyRequestEvent and all its inner classes because we declared this event type as a request event in our Lambda functions, like GetProductByIdHandler and CreateProductHandler
org.joda.time.DateTime, which will be used to convert a timestamp from a string and back. Such a timestamp is a part of the API Gateway proxy request and response events. In my opinion, it's time to switch from Joda-Time to the Java Date/Time API for this.

There are multiple ways, how, and where to define GraalVM Native configuration, like reflection configuration. For this, I refer you to the article Build a Native Executable with Reflection.

Args=--allow-incomplete-classpath \
    --initialize-at-build-time=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory
    -- --trace-class-initialization=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory

The native-image.properties should be placed in the META-INF/native-image/${MavenGroupIid}/${MavenArtifactId}

To save the manual work of defining all this metadata, you can use GraalVM Tracing Agent to generate it for you.

Lambda Custom Runtime

Building GraalVM Native Image

We'll build GraalVM Native Image automatically in the package phase defined in the pom.xml. The relevant part is defined in the following plugin:

<plugin>
   <groupId>org.graalvm.nativeimage</groupId>
   <artifactId>native-image-maven-plugin</artifactId>
   <version>21.2.0</version>
   <executions>
       <execution>
           <goals>
           <goal>native-image</goal>
       </goals>
        <phase>package</phase>
      </execution>
   </executions>
   <configuration>
      <skip>false</skip>              
       <mainClass>
           com.formkiq.lambda.runtime.graalvm.LambdaRuntime
       </mainClass>
       <imageName>
           aws-lambda-java-25-with-dynamodb-as-graalvm-native-image
       </imageName>
       <buildArgs>
         --no-fallback
         --enable-http
         -H:ReflectionConfigurationFiles=../src/main/reflect-config.json
      </buildArgs>
   </configuration>
</plugin>

<dependency>
   <groupId>com.formkiq</groupId>
   <artifactId>lambda-runtime-graalvm</artifactId>
   <version>2.6.0</version>
</dependency>

We then give the native image name aws-lambda-java-25-with-dynamodb-as-graalvm-native-image (the default one will also be an artifact name). After it, we include some GraalVM Native Image arguments and previously defined reflect-config.

<buildArgs>
    --no-fallback
    --enable-http
   -H:ReflectionConfigurationFiles=../src/main/reflect-config.json
</buildArgs>

To zip the built GraalVM Native Image as function.zip required by Lambda Custom Runtime, we use the maven-assembly plugin:

<plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <executions>
            <execution>
                  <id>native-zip</id>
                  <phase>package</phase>
                  <goals>
                        <goal>single</goal>
                  </goals>
                  <inherited>false</inherited>
            </execution>
      </executions>
      <configuration>
            <finalName>function</finalName>
            <appendAssemblyId>false</appendAssemblyId>
            <descriptors>
                  <descriptor>src/assembly/native.xml</descriptor>
            </descriptors>
      </configuration>
</plugin>

The finalName is the name of the zip file, in our case, function. We also include native.xml descriptor:

<assembly>
    <id>native-zip</id>
    <formats>
        <format>zip</format>
    </formats>
  <baseDirectory/>
    <fileSets>
        <fileSet>
            <directory>src/shell/native</directory>
            <outputDirectory>/</outputDirectory>
            <useDefaultExcludes>true</useDefaultExcludes>
            <fileMode>0775</fileMode>
            <includes>
                <include>bootstrap</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>target</directory>
            <outputDirectory>/</outputDirectory>
            <useDefaultExcludes>true</useDefaultExcludes>
            <fileMode>0775</fileMode>
            <includes>
                <include>aws-lambda-java-25-with-dynamodb-as-graalvm-native-image</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

This descriptor defines what files from which directories with what permissions will be added to the zip as an assembly format. fileMode equal to 0775 means it has permission to be executable on the Linux operating system. We include previously built GraalVM Native Image with the name aws-lambda-java-25-with-dynamodb-as-graalvm-native-image there. We also include the already defined bootstrap file, which basically invokes the GraalVM Native Image :

#!/bin/sh

cd ${LAMBDA_TASK_ROOT:-.}

./aws-lambda-java-25-with-dynamodb-as-graalvm-native-image

In the end, we have to build GraalVM Native Image packaged as a zip file, which can be built as a Lambda Custom Runtime with mvn clean package.

Deploying GraalVM Native Image as a Lambda Custom Runtime

Globals:
  Function:
    CodeUri: target/function.zip
    Runtime: provided.al2023

Now we are ready to deploy our application with sam deploy -g.

Measurements of cold and warm start times of our application using GraalVM Native Image

We'll measure the performance of the GetProductById Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDBGVNI25" https://{$API_GATEWAY_URL}/prod/products/1.

We designed the experiment exactly as described in part 2.

I did the measurements with provided:al2023.v124 version, and the deployed artifact size of this application was 25.186 KB.

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Custom Runtime with GraalVM Native Image	559	568	593	692	739	739	3.84	4.23	4.88	10.00	55.92	124

Conclusion

In this part of the series, we first introduced GraalVM Native Image. Then we explained step-by-step how to convert the sample application to one where the native image can be built. When we deployed the native image on AWS Lambda using the Lambda Custom Runtime. Finally, we measured the performance of the Lambda function. We observed that the cold and warm start times were lower compared to using the Lambda SnapStart, even with priming techniques, see the measurements table in part 5. On the other hand, creating a Native Image is not for free, as we need to scale CI/CD pipeline to build a native image. Building it requires many GBs of memory, and the process takes many minutes depending on the hardware. Creating a full set of the Native Image metadata, even using GraalVM Tracing Agent, means introducing additional complexity. Lambda SnapStart, on the other hand, is fully managed.

We'll compare both approaches in one of the next articles.

Please also watch out for another series where I use a relational serverless Amazon Aurora DSQL database and additionally the Hibernate ORM framework instead of DynamoDB to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 5 SnapStart and full priming

Vadym Kazulkin — Wed, 15 Apr 2026 14:47:26 +0000

Introduction

In part 4, we introduced how to apply Lambda SnapStart priming technique, such as Aurora DSQL request priming. The goal was to even further improve the performance of our Lambda functions. We saw that by doing this kind of priming and writing some additional code, we could additionally reduce the Lambda cold start times compared to simply activating the SnapStart. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could also reduce the maximal value for the Lambda warm start times by preloading classes (as Java lazily loads classes when they are required for the first time) and doing some preinitialization work (by invoking the method to retrieve the product from the Aurora DSQL products table by its ID). Previously, all this happened once during the first warm execution of the Lambda function.

In this article, we'll introduce another Lambda SnapStart priming technique. I call it API Gateway Request Event priming (or full priming). We'll then measure the Lambda performance by applying it and comparing the results with other already introduced approaches.

Sample application with JDBC and Hikari connection pool and the enabled AWS Lambda SnapStart using full priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

You can read more about the concepts behind the Lambda SnapStart in part 2 and about SnapStart runtime hooks (which we'll use again) in part 3.

In this article, I will introduce you to the API Gateway Request Event priming (or full priming for short). We implemented it in the extra GetProductByIdWithFullPrimingHandler class.

public class GetProductByIdWithFullPrimingHandler implements 
                 RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, Resource {

private static final ProductDao productDao = new ProductDao();
private static final ObjectMapper objectMapper = new ObjectMapper();

public GetProductByIdWithFullPrimingHandler () {
    Core.getGlobalContext().register(this);
}

@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
    APIGatewayProxyRequestEvent requestEvent = 
    LambdaEventSerializers.serializerFor(APIGatewayProxyRequestEvent.class, ClassLoader.getSystemClassLoader())                 
    .fromJson(getAPIGatewayProxyRequestEventAsJson());
    this.handleRequest(requestEvent, new MockLambdaContext());
 }


private static String getAPIGatewayProxyRequestEventAsJson() throws Exception{
    final APIGatewayProxyRequestEvent proxyRequestEvent = new APIGatewayProxyRequestEvent ();
    proxyRequestEvent.setHttpMethod("GET");
    proxyRequestEvent.setPathParameters(Map.of("id","0"));
    return objectMapper.writeValueAsString(proxyRequestEvent);      
 }

@Override
public void afterRestore(org.crac.Context<? extends Resource> context) throws Exception {   
}

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
      String id = requestEvent.getPathParameters().get("id");
      Optional<Product> optionalProduct = productDao.getProduct(id);
      return new APIGatewayProxyResponseEvent()
           .withStatusCode(HttpStatusCode.OK)                                                 
          .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
....
}

I refer to part 4 for the explanation about how the Lambda SnapStart runtime hooks work. Please read my article Using insights from AWS Lambda Profiler Extension for Java to reduce Lambda cold starts, on how I came up with this idea. I also described in this article in detail why it is supposed to speed things up. Shortly speaking, we primed another expensive LambdaEventSerializers.serializerFor invocation. It consists of class loading and expensive initialization logic, which I identified. By invoking handleRequest, we fully prime this method invocation, which consists mainly of Aurora DSQL request priming introduced in part 4. At the end, we also prime the APIGatewayProxyResponseEvent object construction.

In our example, we primed the APIGatewayProxyRequestEvent "get product by id equal to zero" request. This is enough to instantiate and initialize all we need, even if we'd like to invoke the "create product" request. This priming implementation is also a read request without any side effects. But if you'd like, for example, to prime a "create product" request, you can do it as well:

 private static String getAPIGatewayProxyRequestEventAsJson() throws Exception{
    final APIGatewayProxyRequestEvent proxyRequestEvent = new APIGatewayProxyRequestEvent ();
    proxyRequestEvent.setHttpMethod("POST");
    proxyRequestEvent.setBody("{ 'id': 0, 'name': 'Print 10x13', 'price': 15 }");
    return objectMapper.writeValueAsString(proxyRequestEvent);      
 }

Use some artificial product ID like 0 or a negative one that isn't used in production. If you use API Gateway HTTP API instead of REST API (like in our example), you can use APIGatewayV2HTTPEvent instead of APIGatewayProxyRequestEvent to prime such a request.

Measurements of cold and warm start times of the Lambda function of the sample application with JDBC and Hikari connection pool

We'll measure the performance of the GetProductByIdJava25WithDSQLAndFullPriming Lambda function mapped to the GetProductByIdWithFullPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/productsWithFullPriming/1.

We designed the experiment exactly as described in part 2.

I will present the Lambda performance measurements with SnapStart being activated for all approx. 100 cold start times (labelled as all in the table), but also for the last approx. 70 (labelled as last 70 in the table). With that, the effect of the snapshot tiered cache, which we described in part 3, becomes visible to you.

To show the impact of the SnapStart full priming, we'll also present the Lambda performance measurements from all previous parts.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 17.150 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	2336	2453	2827	3026	3131	3132	4.84	5.29	5.73	8.88	195.38	531
SnapStart enabled but no priming applied, all	970	1058	1705	1726	1734	1735	4.92	5.33	5.86	9.84	198.52	1134
SnapStart enabled but no priming applied, last 70	901	960	1061	1212	1212	1212	4.84	5.29	5.77	9.54	196.94	719
SnapStart enabled and DSQL database request priming applied, all	879	980	1499	1515	1518	1518	4.84	5.25	5.77	9.54	163.96	914
SnapStart enabled and DSQL database request priming applied, last 70	803	912	996	1056	1056	1056	4.84	5.25	5.77	9.54	152.61	597
SnapStart enabled and full priming applied, all	543	625	1306	1411	1433	1434	4.77	5.20	5.68	9.16	159.36	864
SnapStart enabled and full priming applied, last 70	526	578	885	945	945	945	4.77	5.16	5.64	9.24	146.93	560

Sample application with Hibernate and Hikari connection pool and the enabled AWS Lambda SnapStart using full priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

We implemented the full priming in the extra GetProductByIdWithFullPrimingHandler class.

The explanation of what we would like to achieve and how is exactly the same as in the first sample application above. And the code itself looks the same.

Measurements of cold and warm start times of the Lambda function of the sample application with Hibernate and Hikari connection pool

We'll measure the performance of the GetProductByIdJava25WithHibernateAndDSQLAndFullPriming Lambda function mapped to the GetProductByIdWithFullPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/productsWithFullPriming/1.

Please read part 2 for the description of how we designed the experiment.

To show the impact of the SnapStart full priming, we'll also present the Lambda performance measurements from all previous parts.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 42.333 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	6243	6625	7056	8480	8651	8658	5.46	5.96	6.50	9.77	200.10	707
SnapStart enabled but no priming applied, all	1277	1360	3050	3103	3200	3201	5.50	6.01	6.45	10.16	196.94	2349
SnapStart enabled but no priming applied, last 70	1258	1320	1437	1634	1634	1634	5.42	5.91	6.40	10.08	195.94	1093
SnapStart enabled and DSQL database request priming applied, all	1030	1185	2310	2341	2345	2347	5.33	5.91	6.50	11.64	201.70	1607
SnapStart enabled and DSQL database request priming applied, last 70	970	1076	1226	1511	1511	1511	5.37	5.96	6.61	12.01	203.32	670
SnapStart enabled and full priming applied, all	811	933	2101	2148	2154	2155	5.42	5.91	6.45	9.84	196.94	1420
SnapStart enabled and full priming applied, last 70	748	831	918	1033	1033	1033	5.42	5.91	6.40	9.84	195.38	546

Conclusion

In this part of the series, we introduced how to apply another Lambda SnapStart priming technique. I call it API Gateway Request Event priming (or full priming). The goal was to even further improve the performance of our Lambda functions. We saw that by doing this kind of priming and writing even more additional (but simple) code, we could further reduce the Lambda cold start times compared to simply activating the SnapStart and doing Aurora DSQL request priming. It's once again especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could again reduce the maximal value for the Lambda warm start times by preloading classes and doing some preinitialization work.

It's up to you to decide whether this additional complexity is worth the Lambda function performance improvement. You could also be happy with its performance using the Lambda SnapStart with the Aurora DSQL request priming.

Please also watch out for another series where I use a NoSQL serverless Amazon DynamoDB database instead of Aurora DSQL to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and DynamoDB - Part 5 SnapStart and full priming

Vadym Kazulkin — Mon, 13 Apr 2026 15:50:42 +0000

Introduction

In part 1, we introduced our sample application. In part 2, we measured the performance (cold and warm start times) of the Lambda function without any optimizations. What we observed was quite a large cold start time. We introduced AWS Lambda SnapStart in part 3 as one of the approaches to reduce the cold start times of the Lambda function. We saw that by enabling the SnapStart on the Lambda function, the cold start time goes down.

In part 4, we introduced how to apply Lambda SnapStart priming techniques and started with DynamoDB request priming. We saw that by doing this kind of priming and writing some additional code, we could significantly further reduce the Lambda cold start times compared to simply activating the SnapStart. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could significantly reduce the maximal value for the Lambda warm start times by preloading classes (as Java lazily loads classes when they are required for the first time) and doing some preinitialization work (by invoking the method to retrieve the product from the DynamoDB table by its ID). Previously, all this happened once during the first warm execution of the Lambda function.

Sample application with the enabled AWS Lambda SnapStart using full priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

You can read more about the concepts behind the Lambda SnapStart in part 2 and about SnapStart runtime hooks (which we'll use again) in part 3.

In this article, I will introduce you to the API Gateway Request Event priming (or full priming for short). We implemented it in the extra GetProductByIdWithFullPrimingHandler class.

public class GetProductByIdWithFullPrimingHandler implements 
                 RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, Resource {

private static final ProductDao productDao = new ProductDao();
private static final ObjectMapper objectMapper = new ObjectMapper();

public GetProductByIdWithFullPrimingHandler () {
    Core.getGlobalContext().register(this);
}

@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
    APIGatewayProxyRequestEvent requestEvent = 
    LambdaEventSerializers.serializerFor(APIGatewayProxyRequestEvent.class, ClassLoader.getSystemClassLoader())                 
    .fromJson(getAPIGatewayProxyRequestEventAsJson());
    this.handleRequest(requestEvent, new MockLambdaContext());
 }


private static String getAPIGatewayProxyRequestEventAsJson() throws Exception{
    final APIGatewayProxyRequestEvent proxyRequestEvent = new APIGatewayProxyRequestEvent ();
    proxyRequestEvent.setHttpMethod("GET");
    proxyRequestEvent.setPathParameters(Map.of("id","0"));
    return objectMapper.writeValueAsString(proxyRequestEvent);      
 }

@Override
public void afterRestore(org.crac.Context<? extends Resource> context) throws Exception {   
}

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
      String id = requestEvent.getPathParameters().get("id");
      Optional<Product> optionalProduct = productDao.getProduct(id);
      return new APIGatewayProxyResponseEvent()
           .withStatusCode(HttpStatusCode.OK)                                                 
          .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
....
}

I refer to part 4 for the explanation about how the Lambda SnapStart runtime hooks work. Please read my article Using insights from AWS Lambda Profiler Extension for Java to reduce Lambda cold starts, on how I came up with this idea. I also described in this article in detail why it is supposed to speed things up. Shortly speaking, we primed another expensive LambdaEventSerializers.serializerFor invocation. It consists of class loading and expensive initialization logic, which I identified. By invoking handleRequest, we fully prime this method invocation, which consists mainly of DynamoDB request priming introduced in part 4. At the end, we also prime the APIGatewayProxyResponseEvent object construction.

 private static String getAPIGatewayProxyRequestEventAsJson() throws Exception{
    final APIGatewayProxyRequestEvent proxyRequestEvent = new APIGatewayProxyRequestEvent ();
    proxyRequestEvent.setHttpMethod("POST");
    proxyRequestEvent.setBody("{ 'id': 0, 'name': 'Print 10x13', 'price': 15 }");
    return objectMapper.writeValueAsString(proxyRequestEvent);      
 }

Measurements of cold and warm start times of our application with Lambda SnapStart and full priming

We'll measure the performance of the GetProductByIdJava25WithDynamoDBAndFullPriming Lambda function mapped to the GetProductByIdWithFullPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" https://{$API_GATEWAY_URL}/prod/productsWithFullPriming/1.

We designed the experiment exactly as described in part 2.

To show the impact of the SnapStart full priming, we'll also present the Lambda performance measurements from all previous parts.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 13.796 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	3800	3967	4183	4411	4495	4499	5.55	6.15	7.00	12.18	56.37	4000
SnapStart enabled but no priming applied, all	2294	2366	3530	3547	3548	3551	5.68	6.30	7.33	13.43	44.74	2923
SnapStart enabled but no priming applied, last 70	2247	2324	2389	2637	2637	2637	5.68	6.35	7.39	13.65	44.03	2051
SnapStart enabled and DynamoDB request priming applied, all	778	817	1544	1572	1601	1602	5.50	6.10	6.99	12.01	34.74	933
SnapStart enabled and DynamoDB request priming applied, last 70	752	790	837	988	988	988	5.46	6.05	6.99	11.92	42.65	412
SnapStart enabled and full priming applied, all	600	660	172	1310	1325	1325	5.46	6.05	6.93	11.82	37.25	630
SnapStart enabled and full priming applied, last 70	598	640	711	895	895	895	5.42	6.01	6.93	12.01	34.95	214

Conclusion

In this part of the series, we introduced how to apply another Lambda SnapStart priming technique. I call it API Gateway Request Event priming (or full priming). The goal was to even further improve the performance of our Lambda functions. We saw that by doing this kind of priming and writing even more additional (but simple) code, we could further reduce the Lambda cold start times compared to simply activating the SnapStart and doing DynamoDB request priming. It's once again especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could again significantly reduce the maximal value for the Lambda warm start times by preloading classes and doing some preinitialization work.

In the next part, we'll introduce another approach to reduce the cold start time of the Lambda function - GraalVM Native Image. We'll create the native image of our application and deploy it as a Lambda Custom Runtime.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 4 SnapStart and DSQL request priming

Vadym Kazulkin — Thu, 09 Apr 2026 15:14:36 +0000

Introduction

In part 3, we introduced AWS Lambda SnapStart as one of the approaches to reduce the cold start times of the Lambda function. We observed that by enabling the SnapStart on the Lambda function, the cold start time goes down significantly for both sample applications. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. The biggest impact of just enabling the SnapStart is on the application using the Hibernate.

In this part of our article series, we'll introduce how to apply Lambda SnapStart priming techniques. We'll start with the database (in our case, Aurora DSQL) request priming. The goal is to further improve the performance of our Lambda functions.

Sample application with JDBC and Hikari connection pool and the enabled AWS Lambda SnapStart using Aurora DSQL request priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

You can read more about the concepts behind the Lambda SnapStart in part 2.

SnapStart and runtime hooks offer you new possibilities to create your Lambda functions for low startup latency. With the pre-snapshot hook, we can prepare our Java application as much as possible for the first call. We load and initialize as much as possible that our Lambda function needs before the Lambda SnapStart creates the snapshot. The name for this technique is priming.

In this article, I will introduce you to the priming of database (in our case, Aurora DSQL) requests, which we implemented in the extra GetProductByIdWithDSQLPrimingHandler class.

public class GetProductByIdWithDSQLPrimingHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, Resource {

private static final ObjectMapper objectMapper = new ObjectMapper();
private static final ProductDao productDao= new ProductDao();

public GetProductByIdWithDSQLPrimingHandler () {
    Core.getGlobalContext().register(this);
}

@Override
 public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
      productDao.getProductById(0);
}

@Override
public void afterRestore(org.crac.Context<? extends Resource> context) throws Exception {       
}

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
      String id = requestEvent.getPathParameters().get("id");
      Optional<Product> optionalProduct = productDao.getProductById(Integer.valueOf(id));
      return new APIGatewayProxyResponseEvent()
                 .withStatusCode(HttpStatusCode.OK)                                    
          .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
....
}

We use Lambda SnapStart CRaC runtime hooks here. To do this, we need to declare the following dependency in pom.xml:

<dependency>
   <groupId>io.github.crac</groupId>
   <artifactId>org-crac</artifactId>
</dependency>

GetProductByIdWithDSQLPrimingHandler class additionally implements org.crac.Resource interface. The class registers itself as a CRaC resource in the constructor of this class. The priming itself happens in the method where we search for the product with the ID equal to 0 in the products table of the Aurora DSQL database. beforeCheckpoint method is a CRaC runtime hook that is invoked before creating the microVM snapshot. We are not even processing the result of the call to productDao.getProductById(0). The product with the ID equal to zero might not even exist in the database. But with this invocation, Java lazily loads and instantiates all the classes that it requires for this invocation. PreparedStatement, ResultSet, and many others are among such classes. We also instantiate everything required to establish the connection to the database via JDBC and process the request and response.

We can leave the afterRestore method empty. This is because we don't need to perform any action after the SnapStart snapshot has been restored.

Measurements of cold and warm start times of the Lambda function of the sample application with JDBC and Hikari connection pool

We'll measure the performance of the GetProductByIdJava25WithDSQLAndDSQLPriming Lambda function mapped to the GetProductByIdWithDSQLPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/productsWithAuroraPriming/1.

Please read part 2 for the description of how we designed the experiment.

To show the impact of the SnapStart with the Aurora DSQL database request priming, we'll also present the Lambda performance measurements from part 2 and part 3.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 17.150 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	2336	2453	2827	3026	3131	3132	4.84	5.29	5.73	8.88	195.38	531
SnapStart enabled but no priming applied, all	970	1058	1705	1726	1734	1735	4.92	5.33	5.86	9.84	198.52	1134
SnapStart enabled but no priming applied, last 70	901	960	1061	1212	1212	1212	4.84	5.29	5.77	9.54	196.94	719
SnapStart enabled and DSQL database request priming applied, all	879	980	1499	1515	1518	1518	4.84	5.25	5.77	9.54	163.96	914
SnapStart enabled and DSQL database request priming applied, last 70	803	912	996	1056	1056	1056	4.84	5.25	5.77	9.54	152.61	597

Sample application with Hibernate and Hikari connection pool and the enabled AWS Lambda SnapStart using Aurora DSQL request priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

We implemented the priming of the database (in our case, Aurora DSQL) request in the extra GetProductByIdWithDSQLPrimingHandler class.

The explanation of what we would like to achieve and how is exactly the same as in the first sample application above. The main difference is that we use the Hibernate framework on top and also preload and preinitialize its classes and abstractions.

Measurements of cold and warm start times of the Lambda function of the sample application with Hibernate and Hikari connection pool

We'll measure the performance of the GetProductByIdJava25WithHibernateAndDSQLAndDSQLPriming Lambda function mapped to the GetProductByIdWithDSQLPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/productsWithAuroraPriming/1.

Please read part 2 for the description of how we designed the experiment.

To show the impact of the SnapStart with the Aurora DSQL database request priming, we'll also present the Lambda performance measurements from part 2 and part 3.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 42.333 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	6243	6625	7056	8480	8651	8658	5.46	5.96	6.50	9.77	200.10	707
SnapStart enabled but no priming applied, all	1277	1360	3050	3103	3200	3201	5.50	6.01	6.45	10.16	196.94	2349
SnapStart enabled but no priming applied, last 70	1258	1320	1437	1634	1634	1634	5.42	5.91	6.40	10.08	195.94	1093
SnapStart enabled and DSQL database request priming applied, all	1030	1185	2310	2341	2345	2347	5.33	5.91	6.50	11.64	201.70	1607
SnapStart enabled and DSQL database request priming applied, last 70	970	1076	1226	1511	1511	1511	5.37	5.96	6.61	12.01	203.32	670

Conclusion

In this part of our article series, we introduced how to apply the Lambda SnapStart priming technique, such as Aurora DSQL request priming. The goal was to even further improve the performance of our Lambda functions. We saw that by doing this kind of priming and writing some additional code, we could additionally reduce the Lambda cold start times compared to simply activating the SnapStart. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could also reduce the maximal value for the Lambda warm start times by preloading classes (as Java lazily loads classes when they are required for the first time) and doing some preinitialization work (by invoking the method to retrieve the product from the Aurora DSQL products table by its ID). Previously, all this happened once during the first warm execution of the Lambda function.

In the next part of our article series, we'll introduce another Lambda SnapStart priming technique. I call it API Gateway Request Event priming (or full priming). We'll then measure the Lambda performance by applying it and comparing the results with other already introduced approaches.

Please also watch out for another series where I use a NoSQL serverless Amazon DynamoDB database instead of Aurora DSQL to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and DynamoDB - Part 4 SnapStart and DynamoDB request priming

Vadym Kazulkin — Tue, 07 Apr 2026 14:06:04 +0000

Introduction

In this part of our article series, we'll introduce how to apply Lambda SnapStart priming techniques, starting with DynamoDB request priming. The goal is to further improve the performance of our Lambda functions.

Sample application with the enabled AWS Lambda SnapStart using DynamoDB request priming

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2.

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

You can read more about the concepts behind the Lambda SnapStart in part 2.

In this article, I will introduce you to the priming of DynamoDB requests, which we implemented in the extra GetProductByIdWithDynamoDBPrimingHandler class.

public class GetProductByIdWithDynamoDBPrimingHandler implements 
                 RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>, Resource {

private static final ProductDao productDao = new ProductDao();
private static final ObjectMapper objectMapper = new ObjectMapper();

public GetProductByIdWithDynamoDBPrimingHandler () {
      Core.getGlobalContext().register(this);
}

@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
      productDao.getProduct("0");
}

@Override
public void afterRestore(org.crac.Context<? extends Resource> context) throws Exception {   

}

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
      String id = requestEvent.getPathParameters().get("id");
      Optional<Product> optionalProduct = productDao.getProduct(id);
      return new APIGatewayProxyResponseEvent()
                 .withStatusCode(HttpStatusCode.OK)                                    
          .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
....
}

We use Lambda SnapStart CRaC runtime hooks here. To do this, we need to declare the following dependency in pom.xml:

<dependency>
   <groupId>io.github.crac</groupId>
   <artifactId>org-crac</artifactId>
</dependency>

GetProductByIdWithDynamoDBPrimingHandler class additionally implements org.crac.Resource interface. The class registers itself as a CRaC resource in the constructor of this class. The priming itself happens in the method where we search for the product with the ID equal to 0 in the DynamoDB table. beforeCheckpoint method is a CRaC runtime hook that is invoked before creating the microVM snapshot. We are not even processing the result of the call to productDao.getProduct("0"). The product with the ID equal to zero might not even exist in the database. But with this invocation, Java lazily loads and instantiates all the classes that it requires for this invocation. GetItemRequest, GetItemResponse, and many others are among such classes. Also, the expensive one-time initialization of the HTTP Client (default is Apache HTTP Client) happens. The same is true for the initialization of the Jackson Marshaller for converting Java objects to JSON and vice versa. As the priming happens during the deployment phase of the Lambda function when SnapStart is activated and before the SnapStart snapshot is created, the snapshot will already contain all of this. After the fast snapshot restore phase during the Lambda invoke, we'll gain a lot in performance in case the cold start happens. We can leave the afterRestore method empty. We don't need to perform any action after the SnapStart snapshot has been restored.

By the way, we could also achieve the same result by sending nearly any other request to DynamoDB, for example, DescribeTable. However, I found it easier to reuse some already existing database operations. And we already implemented the getProduct by ID method in our DynamoDB DAO. This is a read request without any side effects.

Measurements of cold and warm start times of our application with Lambda SnapStart and DynamoDB request priming

We'll measure the performance of the GetProductByIdJava25WithDynamoDBAndDDBPriming Lambda function mapped to the GetProductByIdWithDynamoDBPrimingHandler shown above. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" https://{$API_GATEWAY_URL}/prod/productsWithDynamoDBPriming/1.

We designed the experiment exactly as described in part 2.

To show the impact of the SnapStart with the DynamoDB request priming, we'll also present the Lambda performance measurements from part 2 and part 3.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 13.796 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	3800	3967	4183	4411	4495	4499	5.55	6.15	7.00	12.18	56.37	4000
SnapStart enabled but no priming applied, all	2294	2366	3530	3547	3548	3551	5.68	6.30	7.33	13.43	44.74	2923
SnapStart enabled but no priming applied, last 70	2247	2324	2389	2637	2637	2637	5.68	6.35	7.39	13.65	44.03	2051
SnapStart enabled and DynamoDB request priming applied, all	778	817	1544	1572	1601	1602	5.50	6.10	6.99	12.01	34.74	933
SnapStart enabled and DynamoDB request priming applied, last 70	752	790	837	988	988	988	5.46	6.05	6.99	11.92	42.65	412

Conclusion

In this part of the series, we introduced how to apply Lambda SnapStart priming techniques and started with DynamoDB request priming. The goal was to even further improve the performance of our Lambda functions. We saw that by doing this kind of priming and writing some additional code, we could significantly further reduce the Lambda cold start times compared to simply activating the SnapStart. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. Moreover, we could significantly reduce the maximal value for the Lambda warm start times by preloading classes (as Java lazily loads classes when they are required for the first time) and doing some preinitialization work (by invoking the method to retrieve the product from the DynamoDB table by its ID). Previously, all this happened once during the first warm execution of the Lambda function.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Spring AI with Amazon Bedrock - Part 6 Adding AgentCore Observability

Vadym Kazulkin — Thu, 02 Apr 2026 14:45:07 +0000

Introduction

In part 5, we showed how to implement a Custom Agent written in Java with Spring AI and to use its MCP Client based on HTTP Streamable transport protocol. We deployed our agent on the Amazon Bedrock AgentCore Runtime. What we didn't show in that part was how to implement AgentCore Observability. And this is what we'll cover now.

Adding AgentCore Observability

If we follow the steps described in the articles AgentCore Runtime Observability and AgentCore Gateway Observability and activate logging and tracing for both AgentCore Gateway and Runtime, like this:

we'll only see the basic AgentCore metrics, but completely miss Sessions and Traces. The reason for this is that we provided the examples using the Strands Agents SDK. It works well with AgentCore Observability (baked by CloudWatch Generative AI Observability). We only had to add the dependency to aws-opentelemetry-distro and instrument our code, as shown below in the Docker file. Strands Agent has all the information on where to send the metrics and traces to the default OTEL provider, AWS CloudWatch. But how does it work for Java applications based on Spring AI and hosted on AgentCore Runtime?

To view the metrics in the CloudWatch Generative AI observability, we need to add the AWS Distro for Open Telemetry (ADOT) SDK to our agent code. ADOT is a secure, production-ready, AWS-supported distribution of the OpenTelemetry project. Part of the Cloud Native Computing Foundation, OpenTelemetry provides open source APIs, libraries, and agents to collect distributed traces and metrics for application monitoring. With ADOT, we can instrument our applications just once to send correlated metrics and traces to multiple AWS and Partner monitoring solutions. In our case, we will send the metrics to the CloudWatch GenAI Observability service.

AWS offers AWS Distro for OpenTelemetry Java with the AWS Distro for OpenTelemetry (ADOT). To get started, see the AWS Distro for OpenTelemetry Java documentation. We see there that we have to download the aws-opentelemetry-agent and run it as the Java agent to instrument the code on the fly:

ADD https://github.com/aws-observability/aws-otel-java-instrumentation/releases/latest/download/aws-opentelemetry-agent.jar /opt/aws-opentelemetry-agent.jar

ENV JAVA_TOOL_OPTIONS=-javaagent:/opt/aws-opentelemetry-agent.jar

The documentation also says that the second component is required to receive the metrics and traces: the AWS Distro for OpenTelemetry Collector. In all the examples AWS provides, the collector is a sidecar application deployed with Docker Compose. Unfortunately, it's not possible to use Docker Compose for the AgentCore Runtime. We only provide the reference to the image in the Amazon Elastic Container Registry (ECR) repository that the AgentCore Runtime pulls and runs for us.

It took me a while to figure out how to achieve this, and I even created the issue for it. There is a so-called collector-less Observability for the Amazon Bedrock AgentCore resources. As of now, unfortunately, not all parameters to be configured are described in this article. But I combined this information with the article Exporting collector-less telemetry using AWS Distro for OpenTelemetry (ADOT) SDK to achieve the goal.

For it, I updated my spring-ai-1.1-agent-demo application from part 5. I now use Java 25, Spring Boot 4.0.5, and Spring AI 1.1.3, though you can update to their recent versions. Spring AI 2.0 is currently not GA, so I'll update to it later.

The complete AgentCore Runtime observability configuration is provided in the Docker file:

ADD https://github.com/aws-observability/aws-otel-java-instrumentation/releases/latest/download/aws-opentelemetry-agent.jar /opt/aws-opentelemetry-agent.jar

ENV JAVA_TOOL_OPTIONS=-javaagent:/opt/aws-opentelemetry-agent.jar \
AGENT_OBSERVABILITY_ENABLED=true \
OTEL_RESOURCE_ATTRIBUTES=service.name=agentcore_runtime_spring_ai_demo,aws.log.group.names=/aws/bedrock-agentcore/runtimes/agentcore_runtime_spring_ai_demo-tD7f1W6RGi \
OTEL_EXPORTER_OTLP_LOGS_HEADERS=x-aws-log-group=/aws/bedrock-agentcore/runtimes/agentcore_runtime_spring_ai_demo-tD7f1W6RGi,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=bedrock-agentcore \
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf \
OTEL_TRACES_EXPORTER=otlp \
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://xray.us-east-1.amazonaws.com/v1/traces \
OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=http/protobuf \
OTEL_LOGS_EXPORTER=otlp \
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs.us-east-1.amazonaws.com/v1/logs

Besides the already described steps to download the aws-opentelemetry-agent and run it as the Java agent to instrument the code, we configured the following:

AGENT_OBSERVABILITY_ENABLED=true to indicate that we use Agent Observability and would like to view the traces in the CloudWatch Generative AI Observability and not in X-Ray.
OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_TRACES_PROTOCOL, and OTEL_EXPORTER_OTLP_LOGS_PROTOCOL to be all http/protobuf.
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT and OTEL_EXPORTER_OTLP_LOGS_ENDPOINT as regional endpoints for traces and logs. If you deploy your application in another region other than us-east-1, you need to adjust the URL.
OTEL_RESOURCE_ATTRIBUTES to be service.name=agentcore_runtime_spring_ai_demo,aws.log.group.names=/aws/bedrock-agentcore/runtimes/agentcore_runtime_spring_ai_demo-tD7f1W6RGi. Please adjust service.name value to how you named the service in AgentCore Runtime. I called it agentcore_runtime_spring_ai_demo. For the suffix of the aws.log.group.names use your AgentCore Runtime ID (in my case agentcore_runtime_spring_ai_demo-tD7f1W6RGi). AWS Log Group Name for AgentCore Runtime always follows the pattern: /aws/bedrock-agentcore/runtimes/{RUNTIME_ID}.
OTEL_EXPORTER_OTLP_LOGS_HEADERS to be x-aws-log-group=/aws/bedrock-agentcore/runtimes/agentcore_runtime_spring_ai_demo-tD7f1W6RGi,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=bedrock-agentcore. The same as above: for the suffix of the x-aws-log-group use your AgentCore Runtime ID again.

After rebuilding and redeploying the application, we can see similar metrics and traces as provided in the articles AgentCore Runtime Observability and AgentCore Gateway Observability. There are, of course, some differences in the collected metadata. This is because we use the AWS Open Telemetry Agent distribution for Java and not for Python, as in the articles above. Here are some selected screenshots taken from the CloudWatch GenAI Observability: Bedrock AgentCore Observability for the prompt "Give me an overview of the order with the id equals 210" (the order id exists in the database) which I sent :

Agent Sessions view:

Agent Traces view:

Traces trajectory view:

Traces timeline views:

Please note that our Spring AI application currently doesn't use short-term and long-term AgentCore Memory. We implemented both with Strands Agents but not Spring AI. So, there won't be any Memory metrics. I'll add AgentCore Memory later, when I cover Spring AI AgentCore, which is currently in preview.

Conclusion

In this article, we described how to configure AgentCore Observability in a collector-less way. This involves running the Java aws-opentelemetry-agent agent to instrument the code and set a bunch of environment variables in the Docker file. Please also make sure you have activated logging and tracing for both AgentCore Gateway and Runtime.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 3 Introducing Lambda SnapStart

Vadym Kazulkin — Tue, 31 Mar 2026 14:34:36 +0000

Introduction

In part 1, we introduced our sample application. In part 2, we measured the performance (cold and warm start times) of the Lambda function without any optimizations. We observed quite a large cold start time, especially if we use the Hibernate ORM framework. Using this framework also significantly increases the artifact size. In this article, we'll introduce AWS Lambda SnapStart as one of the approaches to reducing the cold start times of the Lambda function. We'll also provide the cold and warm start measurements of the sample application when the SnapStart is enabled for the Lambda function.

AWS Lambda SnapStart

As we saw in part 2, without any optimizations, Lambda performance measurements showed quite high values, especially for the cold start times. The article Understanding the Lambda execution environment lifecycle provides a good overview of this topic. Lambda SnapStart is one of the optimization approaches to reduce the cold start times.

Lambda SnapStart can provide a start time of a Lambda function of less than one second. SnapStart simplifies the development of responsive and scalable applications without provisioning resources or implementing complex performance optimizations.

The largest portion of startup latency (often referred to as cold start time) is the time Lambda spends initializing the function. This includes loading the function code, starting the runtime, and initializing the function code. With SnapStart, Lambda initializes our function when we publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment. Then it encrypts the snapshot and intelligently caches it to optimize retrieval latency.

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 invoke the function version, Lambda restores a new execution environment from the cached snapshot. This happens instead of initializing it from scratch, which improves startup latency. More information can be found in the article Reducing Java cold starts on AWS Lambda functions with SnapStart. You can find more information about the Lambda SnapStart in the article Under the hood: how AWS Lambda SnapStart optimizes function startup latency. I have published the whole series about Lambda SnapStart for Java applications.

Measurements of cold and warm start times of the Lambda function of the sample application with JDBC and Hikari connection pool

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2. We'll measure the performance of the GetProductByIdJava25WithDSQL Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/products/1 .

One important aspect is that we instantiate Jackson ObjectMapper and ProductDao directly in the static initializer block of the GetProductByIdHandler Lambda function:

public class GetProductByIdHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

private static final ObjectMapper objectMapper = new ObjectMapper();
private static final ProductDao productDao= new ProductDao();
...

When you create an ObjectMapper for the first time, it initializes a lot of other classes. As a part of this process, it instantiates a lot of singletons. It takes, depending on the hardware, more than a hundred milliseconds. If you create the second ObjectMapper in the same Java process, it takes only 1 millisecond because all the singletons are already there. By moving the ObjectMapper instantiation to the static initializer block of the Lambda function, we decrease the cold start time. The reason for that is that this initialized object becomes a part of the SnapStart snapshot.

The same is true for ProductDao, especially taking into account that we directly preinitialize DsqlDataSourceConfig there:

public class ProductDao {

private static final DsqlDataSourceConfig dsqlDataSourceConfig=new DsqlDataSourceConfig();

....

This, in turn, loads a lot of classes and creates the Hikari Data Source. Moreover, it creates the Hikari connection pool as well. The part of the process is to search for the available JDBC driver. In our case, the PostgreSQL database driver will be found and loaded. Then the initialization of the database connection to Aurora DSQL happens, and this connection is added to the connection pool. We configured the pool size to be 1, because this is enough for the single-thread Lambda function. That's why exactly one database connection will be created. With that, the database connection is ready to be reused. All of these become a part of the SnapStart snapshot:

public class DsqlDataSourceConfig {

private static final String AURORA_DSQL_CLUSTER_ENDPOINT = System.getenv("AURORA_DSQL_CLUSTER_ENDPOINT");

private static final String JDBC_URL = "jdbc:aws-dsql:postgresql://"
    + AURORA_DSQL_CLUSTER_ENDPOINT
     + ":5432/postgres?sslmode=verify-full&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory"
 + "&token-duration-secs=900";


private static HikariDataSource hds;
static {    
   var config = new HikariConfig();
   config.setUsername("admin");
   config.setJdbcUrl(JDBC_URL);
   config.setMaxLifetime(1500 * 1000); // pool connection expiration time in milli seconds, default 30
    config.setMaximumPoolSize(1); // default is 10
    hds = new HikariDataSource(config);
}

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

Please note that I measured only the performance of the Lambda function. On top of that comes also the latency of the trigger - in our case, the API Gateway REST API.

For all approximately 100 cold start times (labelled as all in the table)
For the last approximately 70 (labelled as last 70 in the table). With that, the effect of the snapshot tiered cache becomes visible to you. Depending on how often the respective Lambda function is updated and thus some layers of the cache are invalidated, a Lambda function can experience thousands or tens of thousands of cold starts during its life cycle, so that the first longer-lasting cold starts no longer carry much weight.

To show the impact of the SnapStart, we'll also present the Lambda performance measurements without SnapStart being activated from part 2.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 42.333 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	2336	2453	2827	3026	3131	3132	4.84	5.29	5.73	8.88	195.38	531
SnapStart enabled but no priming applied, all	970	1058	1705	1726	1734	1735	4.92	5.33	5.86	9.84	198.52	1134
SnapStart enabled but no priming applied, last 70	901	960	1061	1212	1212	1212	4.84	5.29	5.77	9.54	196.94	719

Measurements of cold and warm start times of the Lambda function of the sample application with Hibernate and Hikari connection pool

The same as mentioned above holds true for the sample application from part 1, using Hibernate instead of JDBC. We will measure the performance of our GetProductByIdJava25WithHibernateAndDSQL Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/products/1.

The most important difference is that in the ProductDao, we create the Hibernate Session Factory

public class ProductDao {
  private static final SessionFactory sessionFactory=   HibernateUtils.getSessionFactory();
....

In HibernateUtils, we set the same Hikari connection pool properties as in the example above. We then pass those properties to the Hibernate configuration along with the classes annotated as entities. The final part is to build a Hibernate session factory.

public final class HibernateUtils {

private static final String AURORA_DSQL_CLUSTER_ENDPOINT = System.getenv("AURORA_DSQL_CLUSTER_ENDPOINT");

private static final String JDBC_URL = "jdbc:aws-dsql:postgresql://"
   + AURORA_DSQL_CLUSTER_ENDPOINT
   + ":5432/postgres?sslmode=verify-full&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory"
   + "&token-duration-secs=900";

private static SessionFactory sessionFactory= getHibernateSessionFactory();

private HibernateUtils () {}

private static SessionFactory getHibernateSessionFactory () {           
   var settings = new Properties();
   settings.put("jakarta.persistence.jdbc.user", "admin");
   settings.put("jakarta.persistence.jdbc.url", JDBC_URL);
   settings.put("hibernate.connection.pool_size", 1);
   settings.put("hibernate.hikari.maxLifetime", 1500 * 1000);
   return new Configuration()
     .setProperties(settings)
     .addAnnotatedClass(Product.class)
     .buildSessionFactory();    
}

public static SessionFactory getSessionFactory() {
     return sessionFactory;
}
...

All these steps involve a lot of class loading and preinitialization: Hikari Data Source, Hibernate Configuration, and Session Factory. Moreover, it creates the Hikari connection pool as well. The part of the process is to search for the available JDBC driver. In our case, the PostgreSQL database driver will be found and loaded. Then the initialization of the database connection to Aurora DSQL happens, and this connection is added to the connection pool. We configured the pool size to be 1, because this is enough for the single-thread Lambda function. That's why exactly one database connection will be created. With that, the database connection is ready to be reused. All of these become a part of the SnapStart snapshot.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 42.333 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	6243	6625	7056	8480	8651	8658	5.46	5.96	6.50	9.77	200.10	707
SnapStart enabled but no priming applied, all	1277	1360	3050	3103	3200	3201	5.50	6.01	6.45	10.16	196.94	2349
SnapStart enabled but no priming applied, last 70	1258	1320	1437	1634	1634	1634	5.42	5.91	6.40	10.08	195.94	1093

Conclusion

In this article of the series, we introduced AWS Lambda SnapStart as one of the approaches to reduce the cold start times of the Lambda function. We observed that by enabling the SnapStart on the Lambda function, the cold start time goes down significantly for both sample applications. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. The biggest impact of just enabling the SnapStart is on the application using the Hibernate. But still, the cold start remains quite high. In the next article, we'll explore the first Lambda SnapStart priming technique. I call it the database (in our case, Aurora DSQL) request priming. The goal of applying priming is to preload and preinitialize as much as possible in the SnapStart snapshot during the deployment phase. With that, all those things will already be available directly after the SnapStart snapshot restore.

Please also watch out for another series where I use a NoSQL serverless Amazon DynamoDB database instead of Aurora DSQL to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and DynamoDB - Part 3 Introducing Lambda SnapStart

Vadym Kazulkin — Mon, 30 Mar 2026 15:08:46 +0000

Introduction

In part 1, we introduced our sample application. In part 2, we measured the performance (cold and warm start times) of the Lambda function without any optimizations. We observed quite a large cold start time. In this article, we'll introduce AWS Lambda SnapStart as one of the approaches to reducing the cold start times of the Lambda function. We'll also provide the cold and warm start measurements of the sample application when the SnapStart is enabled for the Lambda function.

AWS Lambda SnapStart

The largest portion of startup latency (often referred to as cold start time) is the time Lambda spends initializing the function, which includes loading the function code, starting the runtime, and initializing the function code. With SnapStart, Lambda initializes our function when we publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment. Then it encrypts the snapshot and intelligently caches it to optimize retrieval latency.

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 invoke the function version, Lambda restores a new execution environment from the cached snapshot, instead of initializing it from scratch, which improves startup latency. You can find more information about the Lambda SnapStart in the article Reducing Java cold starts on AWS Lambda functions with SnapStart. You can also read about the internals of the SnapStart in the article Under the hood: how AWS Lambda SnapStart optimizes function startup latency. I have published the whole series about Lambda SnapStart for Java applications.

Measurements of cold and warm start times of the Lambda function of the sample application

We'll reuse the sample application from part 1 and do exactly the same performance measurement as we described in part 2. We'll measure the performance of the GetProductByIdJava25WithDynamoDB Lambda function mapped to the GetProductByIdHandler. We will trigger it by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" https://{$API_GATEWAY_URL}/prod/products/1.

One important aspect is that we instantiate Jackson ObjectMapper and ProductDao directly in the static initializer block of the GetProductByIdHandler Lambda function:

public class GetProductByIdHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

private static final ObjectMapper objectMapper = new ObjectMapper();
private static final ProductDao productDao= new ProductDao();
...

The same is true for ProductDao, especially taking into account that we directly create the instance of the DynamoDbClient there:

public class ProductDao {

private static final DynamoDbClient dynamoDbClient = DynamoDbClient.builder()
  .credentialsProvider(DefaultCredentialsProvider.builder().build())
  .region(Region.of(REGION.toLowerCase()))
  .overrideConfiguration(ClientOverrideConfiguration.builder().build())
  .build();
....

This, in turn, loads a lot of classes, which also become a part of the SnapStart snapshot.

Also, please make sure that we have enabled Lambda SnapStart in template.yaml as shown below:

Globals:
  Function:
    Handler: 
    SnapStart:
      ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

Please note that I measured only the performance of the Lambda function. On top of that comes also the latency of the trigger - in our case, the API Gateway REST API.

Please also note the effect of the Lambda SnapStart snapshot tiered cache. This means that in the case of SnapStart activation, we get the largest cold starts during the first measurements. Due to the tiered cache, the subsequent cold starts will have lower values. For more details about the technical implementation of AWS SnapStart and its tiered cache, I refer you to the presentation by Mike Danilov: "AWS Lambda Under the Hood" and already mentioned article Under the hood: how AWS Lambda SnapStart optimizes function startup latency. Therefore, I will present the Lambda performance measurements with SnapStart being activated for all approx. 100 cold start times (labelled as all in the table), but also for the last approx. 70 (labelled as last 70 in the table), so that the effect of the snapshot tiered cache becomes visible to you. Depending on how often the respective Lambda function is updated and thus some layers of the cache are invalidated, a Lambda function can experience thousands or tens of thousands of cold starts during its life cycle, so that the first longer-lasting cold starts no longer carry much weight.

To show the impact of the SnapStart, we'll also present the Lambda performance measurements without SnapStart being activated from part 2.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 13.796 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	3800	3967	4183	4411	4495	4499	5.55	6.15	7.00	12.18	56.37	4000
SnapStart enabled but no priming applied, all	2294	2366	3530	3547	3548	3551	5.68	6.30	7.33	13.43	44.74	2923
SnapStart enabled but no priming applied, last 70	2247	2324	2389	2637	2637	2637	5.68	6.35	7.39	13.65	44.03	2051

Conclusion

In this article of the series, we introduced AWS Lambda SnapStart as one of the approaches to reduce the cold start times of the Lambda function. We observed that by enabling the SnapStart on the Lambda function, the cold start time goes down. It's especially noticeable when looking at the "last 70" measurements with the snapshot tiered cache effect. But still, the cold start remains quite high. In the next article, we'll explore the first Lambda SnapStart priming technique. I call it the database (in our case, DynamoDB) request priming. The goal of applying priming is to preload and preinitialize as much as possible in the SnapStart snapshot during the deployment phase. With that, all those things will already be available directly after the SnapStart snapshot restore.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Micronaut 4 application on AWS Lambda- Part 8 Measuring Lambda cold and warm starts with REST API application

Vadym Kazulkin — Fri, 27 Mar 2026 14:26:08 +0000

In part 6, we learned how to develop a pure Micronaut REST application and deploy it on AWS Lambda.

For the preparation of my talk about developing Serverless Java REST applications on AWS using frameworks such as Micronaut, I found time to measure the performance of the Lambda function with the different approaches (see below). I refer to my articles where we didn't use the Micronaut REST controllers directly, but the pure AWS Lambda functions, to see how we implemented the SnapStart and priming approaches. They look completely the same when using Micronaut REST controllers.

No SnapStart. Please read the article Introduction to the sample application and first Lambda performance measurements.
SnapStart enabled, but no priming applied. Please read the article Reducing Lambda cold starts with Lambda SnapStart.
SnapStart enabled, and DynamoDB request priming applied. Please read the article Reducing Lambda cold starts with SnapStart and DynamoDB request priming.
SnapStart enabled, and API Gateway request event priming applied. Please read the article Reducing Lambda cold starts with SnapStart and API Gateway request event priming.

Please review the sample application where I provided the implementation of the SnapStart priming approaches, similar to the sample application, where we didn't use the Micronaut REST controllers. The business logic for it is in the package. But you also have to adjust the SAM template accordingly, as I described in the above-mentioned references.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Scenario Number	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	5496	5646	5894	6239	6378	6383	8.00	9.68	13.51	29.40	68.19	1817
SnapStart enabled but no priming applied, all	2064	2116	2185	2260	4007	4009	8.00	9.23	11.34	23.54	49.64	3201
SnapStart enabled but no priming applied, last 70	2042	2100	2166	2262	2262	2262	8.13	9.53	12.09	24.30	48.86	1742
SnapStart enabled and DynamoDB request priming applied, all	849	911	1856	1892	11951	1951	7.75	8.88	10.41	22.19	52.47	1115
SnapStart enabled and DynamoDB request priming applied, last 70	827	862	923	1151	1151	1151	7.87	9.09	10.66	22.73	48.06	449
SnapStart enabled and API Gateway request event priming applied, all	693	741	1443	1457	1460	1461	8.07	9.54	11.73	22.37	61.04	685
SnapStart enabled and API Gateway request event priming applied, last 70	685	728	773	893	893	893	8.33	10.00	12.30	23.28	52.47	240

What we observe is that both cold and warm start times of the sample application using Micronaut REST controllers are generally higher when using the pure AWS Lambda functions. I suspect the reason for it lies in an extra adapter layer used to convert the Lambda request to the REST controller. This adapter uses several extra dependencies, which leads to a much bigger artifact size, which is also one of the factors of the increased cold start times. The advantage of using the REST controller is the ability to more easily migrate the business logic from AWS Lambda to EC2 or Containers.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Quarkus 3 application on AWS Lambda- Part 10 Measuring Lambda cold and warm starts with REST API application

Vadym Kazulkin — Thu, 26 Mar 2026 16:16:56 +0000

Measurements of cold and warm start times of our application

In part 8, we learned how to develop a pure Quarkus REST application and deploy it on AWS Lambda.

For the preparation of my talk about developing Serverless Java REST applications on AWS using frameworks such as Quarkus, I found time to measure the performance of the Lambda function with the different approaches (see below). I refer to my articles where we didn't use the Quarkus REST controllers directly, but the pure AWS Lambda functions, to see how we implemented the SnapStart and priming approaches. They look completely the same when using Quarkus REST controllers.

No SnapStart. Please read the article Introduction to the sample application and first Lambda performance measurements.
SnapStart enabled, but no priming applied. Please read the article Reducing Lambda cold starts with Lambda SnapStart.
SnapStart enabled, and DynamoDB request priming applied. Please read the article Reducing Lambda cold starts with SnapStart and DynamoDB request priming.
SnapStart enabled, and API Gateway request event priming applied. Please read the article Reducing Lambda cold starts with SnapStart and API Gateway request event priming.

Please review the sample application where I provided the implementation of the SnapStart priming approaches, similar to the sample application, where we didn't use the Quarkus REST controllers. The business logic for it is in the package. But you also have to adjust the SAM template accordingly, as I described in the above-mentioned references.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Scenario Number	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	4586	4697	4855	5073	5384	5389	6.51	7.39	9.08	22.45	101.41	1747
SnapStart enabled but no priming applied, all	1979	2049	2816	2916	2990	2991	6.51	7.51	9.08	22.09	106.35	2134
SnapStart enabled but no priming applied, last 70	1953	2016	2098	2278	2278	2278	6.51	7.51	9.08	22.09	78.66	1673
SnapStart enabled and DynamoDB request priming applied, all	1017	1057	2013	2041	2043	2045	6.30	7.27	8.94	21.07	56.36	1273
SnapStart enabled and DynamoDB request priming applied, last 70	1017	1040	1095	1177	1177	1177	6.30	7.27	8.94	21.07	47.44	629
SnapStart enabled and API Gateway request event priming applied, all	747	801	1092	1258	1310	1311	6.51	7.63	9.53	21.75	62.00	304
SnapStart enabled and API Gateway request event priming applied, last 70	735	766	841	1061	1061	1061	6.51	7.63	9.34	21.75	55.48	261

What we observe is that both cold and warm start times of the sample application using Quarkus REST controllers are generally higher when using the pure AWS Lambda functions. I suspect the reason for it lies in an extra adapter layer used to convert the Lambda request to the REST controller. This adapter uses several extra dependencies, which leads to a much bigger artifact size, which is also one of the factors of the increased cold start times. The advantage of using the REST controller is the ability to more easily migrate the business logic from AWS Lambda to EC2 or Containers.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 2 Initial performance measurements

Vadym Kazulkin — Tue, 24 Mar 2026 15:27:00 +0000

Introduction

In part 1, we introduced our 2 sample applications (one using JDBC directly and one using Hibernate). In this article, we'll measure the performance (cold and warm start times) of the Lambda function in both applications without any optimizations.

Measurements of cold and warm start times of the Lambda function of the sample application with JDBC and Hikari connection pool

In the following, we will measure the performance of our GetProductByIdJava25WithDSQL Lambda function mapped to the GetProductByIdHandler, which we will trigger by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/products/1. I assume that you have already created some products as described in part 1. Two aspects are important to us in terms of performance: cold and warm start times. It is known that Java applications, in particular, have a very high cold start time. The article Understanding the Lambda execution environment lifecycle provides a good overview of this topic.

The results of the experiment are based on reproducing more than 100 cold starts and about 100,000 warm starts with the Lambda function GetProductByIdJava25WithDSQL. We retrieve the already existing product with ID=1 for the duration of about 1 hour. We send several hundred requests in parallel with some pauses in between. With that, the existing execution environments will be destroyed, and we will experience new Lambda cold starts. We give the Lambda function 1024 MB of memory, which is a good trade-off between performance and cost. We also use (default) x86 Lambda architecture. For the load tests, I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.

With AWS Lambda now supporting Java 25, there have been some changes for the Java compilation options, especially tiered compilation. Java’s tiered compilation is a just-in-time (JIT) optimization strategy that employs multiple compiler tiers to enhance the performance of frequently executed code progressively using runtime profiling data. Since Java 17, AWS Lambda has modified the default JVM behavior by stopping compilation at the C1 tier (client compiler). This minimizes cold start times for function invocations for most functions. Although for compute-intensive functions with a long duration, customers can benefit from tuning tiered compilation to their workload. Starting with Java 25, Lambda no longer stops tiered compilation at C1 for SnapStart and Provisioned Concurrency. This improves performance in these cases without incurring a cold start penalty. This is because tiered compilation occurs outside of the invoke path in these cases.

I've found out that stopping compilation at the C1 tier (client compiler) provides the best trade-off for this type of application. This is also true when using SnapStart and priming techniques, which we'll cover in the next article. But this may not be the best choice for other applications. I also show the Lambda performance measurements with the default compilation behavior described above in one of the next articles.

That's why we set XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation option. To do so, we have to set it in template.yaml in the JAVA_OPTIONS environment variable as follows:

Globals:
  Function:
    Handler: 
    #SnapStart:
      #ApplyOn: PublishedVersions 
    ....
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

Also, please make sure that SnapStart isn't configured or disabled as shown above for the initial measurement. We'll cover it in the next articles.

Please note that I measured only the performance of the Lambda function. On top of that comes also the latency of the trigger - in our case, the API Gateway REST API.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 17.150 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	2336	2453	2827	3026	3131	3132	4.84	5.29	5.73	8.88	195.38	531

Measurements of cold and warm start times of the Lambda function of the sample application with Hibernate and Hikari connection pool

The same holds true for this application, but for the application aws-lambda-java-25-hibernate-aurora-dsql. We will measure the performance of our GetProductByIdJava25WithHibernateAndDSQL Lambda function mapped to the GetProductByIdHandler, which we will trigger by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/products/1.

I did the measurements with java:25.v19 Amazon Corretto version, and the deployed artifact size of this application was 42.333 KB.

Cold (c) and warm (w) start time with -XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation in ms:

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
No SnapStart enabled	6243	6625	7056	8480	8651	8658	5.46	5.96	6.50	9.77	200.10	707

Conclusion

In this article, we made the first Lambda performance measurements (cold and warm start times) of both of our sample applications. We observed quite a large cold start time, especially if we use the Hibernate ORM framework. Using this framework also significantly increases the artifact size. In the next parts of the series, we'll introduce approaches and techniques to reduce the Lambda cold start time with AWS Lambda SnapStart (including various priming techniques) and GraalVM Native Image, and also measure their impact on the Lambda warm start time for both sample applications. Stay tuned!

Please also watch out for another series where I use a NoSQL serverless Amazon DynamoDB database instead of Aurora DSQL to do the same Lambda performance measurements.

If you like my content, please follow me on GitHub and give my repositories a star!

Please also check out my website for more technical content and upcoming public speaking activities.