Forem: Vadym Kazulkin

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.

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.

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.

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

Vadym Kazulkin — Mon, 23 Mar 2026 15:45:18 +0000

Introduction

In part 1 of the series, we introduced our sample application. In this article, we'll measure the performance (cold and warm start times) of the Lambda function without any optimizations.

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

In the following, we will measure the performance of our GetProductByIdJava25WithDynamoDB Lambda function mapped to the GetProductByIdHandler, which we will trigger by invoking curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" 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 GetProductByIdJava25WithDynamoDB. 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 and default Apache HTTP 4.5 Client to talk to DynamoDB. For the load tests, I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.

I've found out that stopping compilation at the C1 tier (client compiler) provides the best trade-off for this type of application, also when using SnapStart and priming techniques (which we'll cover in the next article), but may not be the best choice for others. So you simply need to measure to find the right compilation settings for your application. 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 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

Conclusion

In this article, we made the first Lambda performance measurements (cold and warm start times) of our sample application. We observed quite a large cold start time. 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. Stay tuned!

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 1 Sample applications

Vadym Kazulkin — Mon, 16 Mar 2026 15:31:43 +0000

Introduction

In this article series, we'll explain how to implement a serverless application on AWS using Lambda with the support of the released Java 25 version. We'll also use API Gateway, relational Serverless database Aurora DSQL, and AWS SAM for the Infrastructure as Code. After it, we'll measure the performance (cold and warm start times) of the Lambda function without any optimizations. Hereafter, we'll introduce various cold start time reduction approaches like Lambda SnapStart with priming techniques and GraalVM Native Image. In this article, we'll introduce our sample application.

Sample applications and their architecture

You can find a code example of our 2 sample applications in my GitHub repositories:

aws-lambda-java-25-aurora-dsql. Here we use JDBC with Hikari connection pool.
aws-lambda-java-25-hibernate-aurora-dsql. Here we use Hibernate ORM framework with Hikari connection pool. I think that Hibernate JPA is mostly in use together with frameworks like Spring Boot, Quarkus, or Micronaut (this is the topic of my future article series). But I'd like to show you the implications of adding such a framework to Lambda performance.

For both applications, we'll use Aurora DSQ JDBC connector, which simplifies dealing with passwords. See my article about this topic.

The architecture of both sample applications is shown below:

In this application, we will create products and retrieve them by their ID, and use Amazon Aurora DSQL as a relational serverless database for the persistence layer. We use Amazon API Gateway, which makes it easy for developers to create, publish, maintain, monitor, and secure APIs. Of course, we rely on AWS Lambda to execute code without the need to provision or manage servers. We also use AWS SAM, which provides a short syntax optimised for defining infrastructure as code (hereafter IaC) for serverless applications. For this article, I assume a basic understanding of the mentioned AWS services, serverless architectures on AWS, and AWS SAM. The application is intentionally fairly simple. The goal is to demonstrate the general development concepts and cover approaches to reduce the cold start time of the Lambda. Please also watch out for another series where I use No SQL serverless Amazon DynamoDB instead of Aurora DSQL to do the same Lambda performance measurements.

To build and deploy the sample application, we need the following local installations: Java 25, Maven, AWS CLI, and SAM CLI. Later, we'll also need GraalVM, including its Native Image capabilities. Using it, we'll build a native image of our application to deploy it on AWS Lambda using the Custom Runtime.

Sample application with JDBC and Hikari connection pool

Let's first start with aws-lambda-java-25-aurora-dsql application, which uses JDBC with Hikari connection pool.

First, we cover the Infrastructure as Code (IaC) part described in AWS SAM template.yaml. We'll focus only on the parts relevant to the definitions of the Lambda functions there.

In the global section, we define the common properties valid for all defined Lambda functions. To such properties belong code URI, runtime (in our case Java 25), Snapstart usage yes/no, timeout, memory size, and environment variables:

Globals:
  Function:
    CodeUri: ....
    Runtime: java25
    #SnapStart:
      #ApplyOn: PublishedVersions 
    Timeout: 30 
    MemorySize: 1024
    Architectures:
      - x86_64  
    Environment:
      Variables:
         AURORA_DSQL_CLUSTER_ENDPOINT: !Sub ${DSQL}.dsql.${AWS::Region}.on.aws
        ...

Below is an example of the definition of the Lambda function with the name GetProductByIdJava25WithDSQL. We define the handler: a Java class and method that will be invoked. We also give this Lambda function access to the Aurora DSQL cluster that we create within this template. At the end, we define the event to invoke this particular Lambda function. As we use a REST application and API Gateway in front, we define the HTTP method get and the path /products/{id} for it. This means that the invocation of this Lambda function occurs when an HTTP GET request comes in to retrieve the product by its id.

  GetProductByIdFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdJava25WithDSQL
      AutoPublishAlias: liveVersion 
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest
      Policies:
        - Version: '2012-10-17' # Policy Document
          Statement:
            - Effect: Allow
              Action:
                - dsql:DbConnectAdmin
              Resource: 
                 - !Sub arn:${AWS::Partition}:dsql:${AWS::Region}:${AWS::AccountId}:cluster/${DSQL}

      Events:
        GetRequestById:
          Type: Api
          Properties:
            RestApiId: !Ref MyApi
            Path: /products/{id}
            Method: get

The definition of another Lambda function PostProductJava25WithDSQL is similar.

Now let's look at the source code of the GetProductByIdHandler Lambda function that will be invoked when the Lambda function with the name GetProductByIdJava25WithDSQL gets invoked. This Lambda function determines the product based on its ID and returns it:

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
   var id = requestEvent.getPathParameters().get("id");
   var optionalProduct = productDao.getProductById(Integer.valueOf(id));
   if (optionalProduct.isEmpty()) {
      return new APIGatewayProxyResponseEvent()
           .withStatusCode(HttpStatusCode.NOT_FOUND)
       .withBody("Product with id = " + id + " not found");
    }
    return new APIGatewayProxyResponseEvent()
         .withStatusCode(HttpStatusCode.OK)                    
         .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
 }

The only method handleRequest receives an object of type APIGatewayProxyRequestEvent as input, as APIGatewayRequest invokes the Lambda function. From this input object, we retrieve the product ID by invoking requestEvent.getPathParameters().get("id") and ask our ProductDao to find the product with this ID in the Aurora DSQL by invoking productDao.getProduct(id). Depending on whether the product exists or not, we wrap the Jackson serialised response in an object of type APIGatewayProxyResponseEvent and send it back to Amazon API Gateway as a response. The source code of the Lambda function CreateProductHandler, which we use to create and persist products, looks similar.

The source code of the Product entity looks very simple:

public record Product(String id, String name, BigDecimal price) {}

The implementation of the ProductDao persistence layer uses JDBC to write to or read from the Aurora DSQL database. Here is an example of the source code of the getProductById method, which we used in the GetProductByIdHandler Lambda function described above:

public Optional<Product> getProductById(int id) throws Exception {
   try (var con = getConnection();
      var pst = this.getProductByIdPreparedStatement(con, id);
      var rs = pst.executeQuery()) {
      if (rs.next()) {
          var name = rs.getString("name");
          int price = rs.getInt("price");
          var product = new Product(id, name, price);
           return Optional.of(product);
          } else {
            return Optional.empty();
             }
     }

Here, we use the plain Java JDBC API to talk to the database. We use the Hikari connection pool to manage the connection to the database, as creating such a connection is not free. We set up the Hikari pool in the DsqlDataSourceConfig directly in the static initializer block:

   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);
}

Here we set the use name, JDBC_URL, which is constructed with the help of through Lambda exposed environment variable AURORA_DSQL_CLUSTER_ENDPOINT. We also set max life time of the pool and the maximum connection size to 1. This is enough, as only one Lambda function is executed within the microVM, and we have a single-threaded application. Aurora DSQL JDBC connector handles the logic to retrieve a short-lived token and set it as a password behind the scenes. Each time we invoke getConnection method in the ProductDao, the Hikari Datasource is responsible for obtaining the connection:

public static Connection getPooledConnection() throws SQLException {
   return hds.getConnection();
}

Now we have to build the application with mvn clean package and deploy it with sam deploy -g. We will see our customised Amazon API Gateway URL in the return. After it, you need to connect to the create Aurora DSQL cluster and execute these 2 statements to create the table and the sequence:

CREATE TABLE products (id int PRIMARY KEY, name varchar (256) NOT NULL, price int NOT NULL); CREATE SEQUENCE product_id CACHE 1;

We can use it to create products and retrieve them by ID. The interface is secured with the API key. We have to send the following as an HTTP header: "X-API-Key: a6ZbcDefQW12BN56WEDQ25", see MyApiKey definition in template.yaml. To create the product, we can use the following curl query:

curl -m PUT -d '{"name": "Print 10x13", "price": 0.15 }' -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/products

Our application uses the next value of the sequence with the name product_id to generate the product id. The output of this request contains this product. To query the existing product with ID=1, we can use the following curl query:

curl -H "X-API-Key: a6ZbcDefQW12BN56WEDQ25" https://{$API_GATEWAY_URL}/prod/products/1

Sample application with Hibernate and Hikari connection pool

Let's now look at aws-lambda-java-25-hibernate-aurora-dsql application, which uses the Hibernate ORM framework with the Hikari connection pool.

The code of the SAM template and Java handler to execute the Lambda functions looks similar to the first example above. So we won't cover those parts.

The source code of the Product entity looks like this:

@Entity
@Table(name = "products")
public class Product implements Serializable {

  @Id
  @GeneratedValue(strategy = GenerationType.SEQUENCE)
  @SequenceGenerator(sequenceName = "product_id", allocationSize = 1)
  private int id;
  private String name;
  private int price;

  public Product() {
  }

  public int getId() {
    return this.id;
  }

  public void setId(int id) {
    this.id = id;
  }

...

We can't use the Java record for Hibernate entities, that's why we have setters and getters for the attributes like id, name, and price. Additionally, we annotate the class with @ Entity and @Table annotations and provide the table name to store the products. We annotate the attribute id with the @ Id, @GeneratedValue, and @SequenceGenerator to define that we use the generated value by the sequence with the name product_id to set the id.

Then we implement HibernateUtils to create a Hibernate SessionFactory, which we use in the ProductDao later:

  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();    
    }
...

Here, we set the same Hikari connection pool properties as in the first example. 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.

The implementation of the ProductDao persistence layer uses the Hibernate session factory to open the session, start, and commit the transaction, and also persist the entities and find them by their id:

public class ProductDao {

  private static final SessionFactory sessionFactory= HibernateUtils.getSessionFactory();

  public int createProduct(Product product) throws Exception {
     var session= sessionFactory.openSession(); 
     var transaction =  session.beginTransaction();
     session.persist(product);
     transaction.commit();
     return product.getId(); 
   }

   public Optional<Product> getProductById(int id) throws Exception {
     var session= sessionFactory.openSession(); 
     return Optional.ofNullable(session.find(Product.class, id));
   }
}

Similar to the first example, we now have to build the application with mvn clean package and deploy it with sam deploy -g. We will see our customised Amazon API Gateway URL in the return. After it, you need to connect to the create Aurora DSQL cluster and execute these 2 statements to create the table and the sequence:

CREATE TABLE products (id int PRIMARY KEY, name varchar (256) NOT NULL, price int NOT NULL); CREATE SEQUENCE product_id CACHE 1;

We can use it to create products and retrieve them by ID. The interface is secured with the API key. We have to send the following as an HTTP header: "X-API-Key: a6ZbcDefQW12BN56WEHADQ25", see MyApiKey definition in template.yaml. To create the product, we can use the following curl query:

curl -m PUT -d '{"name": "Print 10x13", "price": 0.15 }' -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/products

curl -H "X-API-Key: a6ZbcDefQW12BN56WEHADQ25" https://{$API_GATEWAY_URL}/prod/products/1

Conclusion

In this article, we introduced our sample applications (with and without the usage of the Hibernate ORM framework). In the next article, we'll measure the performance (cold and warm start times) of the Lambda function in both applications without any optimizations.

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 using Lambda with Java 25, API Gateway and DynamoDB - Part 1 Sample application

Vadym Kazulkin — Mon, 16 Mar 2026 15:31:30 +0000

Introduction

In this article series, we'll explain how to implement a serverless application on AWS using Lambda with the support of the released Java 25 version. We'll also use API Gateway, DynamoDB, and AWS SAM for the Infrastructure as Code. After it, we'll measure the performance (cold and warm start times) of the Lambda function without any optimizations. Hereafter, we'll introduce various cold start time reduction approaches like Lambda SnapStart with priming techniques and GraalVM Native Image. In this article, we'll introduce our sample application.

Sample application and its architecture

You can find a code example of our sample application in my GitHub aws-lambda-java-25-dynamodb.

The architecture of our sample application is shown below:

In this application, we will create products and retrieve them by their ID and use Amazon DynamoDB as a NoSQL database for the persistence layer. We use Amazon API Gateway, which makes it easy for developers to create, publish, maintain, monitor, and secure APIs. Of course, we rely on AWS Lambda to execute code without the need to provision or manage servers. We also use AWS SAM, which provides a short syntax optimised for defining infrastructure as code (hereafter IaC) for serverless applications. For this article, I assume a basic understanding of the mentioned AWS services, serverless architectures on AWS, and AWS SAM. The application is intentionally fairly simple. The goal is to demonstrate the general development concepts and cover approaches to reduce the cold start time of the Lambda. Please also watch out for another series where I use relational serverless Amazon Aurora DSQL database and additionally Hibernate ORM framework instead of DynamoDB to do the same Lambda performance measurements.

Let's start by covering the IaC part described in AWS SAM template.yaml. We'll focus only on the parts relevant to the definitions of the Lambda functions there.

Globals:
  Function:
    CodeUri: ....
    Runtime: java25
    #SnapStart:
      #ApplyOn: PublishedVersions 
    Timeout: 30 
    MemorySize: 1024
    Architectures:
      - x86_64  
    Environment:
      Variables:
        REGION: !Sub ${AWS::Region}
        PRODUCT_TABLE_NAME: !Ref ProductsTable
        ...

Below is an example of the definition of the Lambda function with the name GetProductByIdJava25WithDynamoDB. We define the handler: a Java class and method that will be invoked. We also give this Lambda function read access to the DynamoDB table with the name ProductsTable. At the end, we define the event to invoke this particular Lambda function. As we use a REST application and API Gateway in front, we define the HTTP method get and the path /products/{id} for it. This means that the invocation of this Lambda function occurs when an HTTP GET request comes in to retrieve the product by its id.

  GetProductByIdFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdJava25WithDynamoDB
      AutoPublishAlias: liveVersion 
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest
      Policies:
        - DynamoDBReadPolicy:
            TableName: !Ref ProductsTable
      Events:
        GetRequestById:
          Type: Api
          Properties:
            RestApiId: !Ref MyApi
            Path: /products/{id}
            Method: get

The definition of another Lambda function PostProductJava25WithDynamoDB is similar.

Now let's look at the source code of the GetProductByIdHandler Lambda function that will be invoked when the Lambda function with the name GetProductByIdJava25WithDynamoDB gets invoked. This Lambda function determines the product based on its ID and returns it:

@Override
public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
   var id = requestEvent.getPathParameters().get("id");
   var optionalProduct = productDao.getProduct(id);
   if (optionalProduct.isEmpty()) {
      return new APIGatewayProxyResponseEvent()
           .withStatusCode(HttpStatusCode.NOT_FOUND)
       .withBody("Product with id = " + id + " not found");
    }
    return new APIGatewayProxyResponseEvent()
         .withStatusCode(HttpStatusCode.OK)                    
         .withBody(objectMapper.writeValueAsString(optionalProduct.get()));
 }

The only method handleRequest receives an object of type APIGatewayProxyRequestEvent as input, as APIGatewayRequest invokes the Lambda function. From this input object, we retrieve the product ID by invoking requestEvent.getPathParameters().get("id"). Then we ask our ProductDao to find the product with this ID in the DynamoDB by invoking productDao.getProduct(id). Depending on whether the product exists or not, we wrap the Jackson serialised response in an object of type APIGatewayProxyResponseEvent and send it back to Amazon API Gateway as a response. The source code of the Lambda function CreateProductHandler, which we use to create and persist products, looks similar.

The source code of the Product entity looks very simple:

public record Product(String id, String name, BigDecimal price) {}

The implementation of the ProductDao persistence layer uses AWS SDK for Java 2.0 to write to or read from the DynamoDB. Here is an example of the source code of the getProductById method, which we used in the GetProductByIdHandler Lambda function described above:

  public Optional<Product> getProduct(String id) {
    GetItemResponse getItemResponse= dynamoDbClient.getItem(GetItemRequest.builder()
      .key(Map.of("PK", AttributeValue.builder().s(id).build()))
      .tableName(PRODUCT_TABLE_NAME)
      .build());
    if (getItemResponse.hasItem()) {
      return Optional.of(ProductMapper.productFromDynamoDB(getItemResponse.item()));
    } else {
      return Optional.empty();
    }
  }

Here, we use the instance of the DynamoDbClient to build a GetItemRequest to query the DynamoDB table. We get the name of the table from an environment variable (which we will set in the AWS SAM template) by invoking System.getenv("PRODUCT_TABLE_NAME"), for the product based on its ID. If the product is found, we use the custom-written ProductMapper to map the DynamoDB item to the attributes of the product entity.

Now we have to build the application with mvn clean package and deploy it with sam deploy -g. We will see our customised Amazon API Gateway URL in the return. We can use it to create products and retrieve them by ID. The interface is secured with the API key. We have to send the following as an HTTP header: "X-API-Key: a6ZbcDefQW12BN56WEVDDB25", see MyApiKey definition in template.yaml. To create the product with ID=1, we can use the following curl query:

curl -m PUT -d '{ "id": 1, "name": "Print 10x13", "price": 0.15 }' -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" https://{$API_GATEWAY_URL}/prod/products

For example, to query the existing product with ID=1, we can use the following curl query:

curl -H "X-API-Key: a6ZbcDefQW12BN56WEVDDB25" https://{$API_GATEWAY_URL}/prod/products/1

Conclusion

In this article, we introduced our sample application. In the next article, we'll measure the performance (cold and warm start times) of the Lambda function without any optimizations.

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.

AWS Lambda Managed Instances with Java 25 and AWS SAM – Part 6 Lambda function performance improvement approaches

Vadym Kazulkin — Mon, 09 Mar 2026 15:52:47 +0000

Introdcution

In part 5 of this series, we measured the initial Lambda function performance (the Java code was intentionally not optimized). Still, we saw a quite noticeable cold start when the request to the Lambda function reached the underlying EC2 instance for the first time. We found that a Lambda function with the Lambda Managed Instances compute type can't eliminate the behavior of the programming language, such as a JVM warm-up period.
In this article, we'll optimize our Lambda function to improve the cold start time significantly.

Lambda function performance improvement approaches

The first thing that we notice during the deployment phase (in case we initially deploy or re-deploy the Lambda function) is that the handler class, for example, for GetProductByIdHandler for the GetProductByIdHandler Lambda function will be initialized. We can prove it by adding some log statements to the static initializer block of this Java class. With this, we know that the static code will be executed before we even invoke our Lambda function. So our goal is to preload as much as possible in the static initializer block of the Lambda handler class.

The first thing that we notice is that we instantiate the ObjectMapper (to convert JSON representation of the Product into the Product class) for each invocation (within the handleRequest method) of the Lambda function:

@Override
public APIGatewayProxyResponseEvent  handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
   var productDao = new DynamoProductDao();
   var objectMapper = new ObjectMapper();
....

This is suboptimal because we can reuse this object, so let's move it to the static initializer block of the GetProductByIdHandler :

public class GetProductByIdHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

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

Now let's redeploy our application and send a first request to this Lambda function, for example, via API Gateway GET HTTP request. Let's then look into the CloudWatch metrics of this Lambda function :

{
    "time": "2026-02-25T16:23:36.676Z",
    "type": "platform.report",
    "record": {
        "requestId": "3581bb16-29a9-4a5e-9d7d-119700366693",
        "metrics": {
            "durationMs": 1419.352
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-25T16:23:35.258Z",
                "durationMs": 1416.915
            },
            {
                "name": "responseDuration",
                "start": "2026-02-25T16:23:36.675Z",
                "durationMs": 1.199
            }
        ],
        "status": "success"
    }
}

We see that the response latency of this Lambda function is 1579 milliseconds. You might observe a different latency, because it also depends on the type of EC2 instance itself. But it decreased by roughly 165 milliseconds compared to the initial version. Why? Generally speaking, when you create an ObjectMapper for the first time, there will be a lot of classes that will be loaded for the first time, and also many singletons that need to be instantiated only once. It takes, depending on the hardware, more than a hundred milliseconds. If you create the second ObjectMapper in the same Java process, it takes 1 millisecond. By moving the ObjectMapper instantiation to the static initializer block of the Lambda function, which will be executed during the deployment phase, we saved a bunch of time, and the first invocation of the Lambda function on
the EC2 instance became quicker.

Let's move on. We also so that we instatiate DynamoProductDao for each invocation (within the handleRequest method) of the Lambda function (see the code above). With that, we also instantiate DynamoDBClient in each Lambda request. This is suboptimal as well, because we can reuse this object, so let's move it to the static initializer block of the GetProductByIdHandler :

public class GetProductByIdHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

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

....

{
    "time": "2026-02-25T16:31:40.163Z",
    "type": "platform.report",
    "record": {
        "requestId": "ce83c152-c536-42a0-9462-39d1c0aca3e8",
        "metrics": {
            "durationMs": 692.023
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-25T16:31:39.472Z",
                "durationMs": 690.665
            },
            {
                "name": "responseDuration",
                "start": "2026-02-25T16:31:40.162Z",
                "durationMs": 0.204
            }
        ],
        "status": "success"
    }
}

This optimization is huge: response latency went down to 691 milliseconds. The key is also preloading a bunch of classes and instantiating DynamoDBClient during the deployment phase.

Ok, this was an easy part. We're not done yet. I wrote a lot of articles about Lambda SnapStart and the Lambda cold start optimization strategies using priming techniques. The truth is that we don't require implementing the CRaC API for such priming. The first priming approach that we'll apply now is DynamoDB (request) priming. The idea is to make a call to the DynamoDB table to do the following.

Preload all classes required for such a request and delivering response.
To instantiate the HTTP Client (the default one is Apache 4.5, but you can set others). An HTTP client is required to talk to the DynamoDB, and its initialization is an expensive one-time operation.
To use ObjectMapper to convert the JSON result to Product, which will also involve some expensive one-time operations.

How can we do it? Let's look at the example:

public class GetProductByIdHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

  private static final ProductDao productDao = new DynamoProductDao();
  private static final ObjectMapper objectMapper = new ObjectMapper();
  static {
     productDao.getProduct("0"); 
  }     
....

We simply use the static initialization block to get the product by id 0. We are not even considering the result (the product with id 0 might not even exist in the database), but only in the 3 things I mentioned previously.

Now let's redeploy our application again and send a first request to this Lambda function, for example, via API Gateway GET HTTP request. Let's then look into the CloudWatch metrics of this Lambda function :

{
    "time": "2026-02-25T16:47:26.281Z",
    "type": "platform.report",
    "record": {
        "requestId": "6e608d71-aa35-4784-afa4-c945fb6eebf3",
        "metrics": {
            "durationMs": 79.102
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-25T16:47:26.204Z",
                "durationMs": 75.445
            },
            {
                "name": "responseDuration",
                "start": "2026-02-25T16:47:26.279Z",
                "durationMs": 1.415
            }
        ],
        "status": "success"
    }
}

This is another huge win, and the response latency is now down to 75 milliseconds. We had to write only a few lines of code to achieve this. Please find the full code in GetProductByIdWithDynamoDBPrimingHandler, and I provided an extra /productsWithDynamoDBPriming/{id} endpoint in the API Gateway. We can basically stop here, because the latency is nearly acceptable for most use cases.

But there is a bit of latency that you can still save. I forward you to please read my article Using insights from AWS Lambda Profiler Extension for Java to reduce Lambda cold starts, how I came to this idea, and what needs to be done for it. There is a lot more code that we need to write, though, to prime more things. Please find the full code in GetProductByIdWithFullPrimingHandler, and I provided an extra /productsWithFullPriming/{id} endpoint in the API Gateway :


public class GetProductByIdWithFullPrimingHandler implements 
                 RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>{

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

   static {
     APIGatewayProxyRequestEvent requestEvent =   
    LambdaEventSerializers.serializerFor (APIGatewayProxyRequestEvent.class, GetProductByIdWithFullPrimingHandler.class.getClassLoader())
    .fromJson(getAPIGatewayProxyRequestEventAsJson());  
     handleRequestInternal(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);      
    }

   private static APIGatewayProxyResponseEvent  handleRequestInternal(APIGatewayProxyRequestEvent requestEvent, Context context) {
        String id = requestEvent.getPathParameters().get("id");
        Optional<Product> optionalProduct = productDao.getProduct(id);
        ...
    }

   @Override
   public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) {
        return handleRequestInternal(requestEvent, context);
   }

I gave the explanation in my article mentioned above. Now let's redeploy our application from the last time and send a first request to this Lambda function, for example, via API Gateway GET HTTP request. Let's then look into the CloudWatch metrics of this Lambda function :

{
    "time": "2026-02-25T16:51:33.162Z",
    "type": "platform.report",
    "record": {
        "requestId": "78aa223d-3e0d-4fd1-aa1a-b59f809d2b04",
        "metrics": {
            "durationMs": 62.126
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-25T16:51:33.102Z",
                "durationMs": 60.214
            },
            {
                "name": "responseDuration",
                "start": "2026-02-25T16:51:33.162Z",
                "durationMs": 0.191
            }
        ],
        "status": "success"
    }
}

We saved another 20 milliseconds of the response latency, which is now only 60 milliseconds. There is still some internal work to be done by the Lambda client deployed on EC2 before the handleRequest method is invoked, and we can't optimize it. I'd stop by doing DynamoDB (request priming), as I'm pretty happy to have the responseLatency below 100 milliseconds.

Conclusion

In this article, we optimized our Lambda function in multiple steps to decrease the cold start time (response latency of the first request) significantly.

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.

AWS Lambda Managed Instances with Java 25 and AWS SAM – Part 5 Lambda function initial performance measurements

Vadym Kazulkin — Thu, 05 Mar 2026 15:34:54 +0000

In part 1 of the series, we explained the ideas behind AWS Lambda Managed Instances and introduced our sample application. In part 2, we explained what a Lambda Capacity Provider is and how to create it using AWS SAM. Part 3 was about how to create Lambda functions and attach them to a capacity provider. In part 4, we talked about monitoring, currently unsupported features, current challenges, and pricing of LMI. In this article, we'll measure the initial Lambda function performance.

Lambda function initial performance measurements

Let's first start by measuring the performance of the GetProductById function, whose implementation we can find here. We first implemented this Lambda function in a not very optimal way. More about its optimization potential in the next article. Let's send a first request to this Lambda function, for example, via API Gateway GET HTTP request to products/1 (assuming we've already created a product with id 1). Let's then look into the CloudWatch metrics of this Lambda function. We find something similar to :

{
    "time": "2026-02-24T06:54:10.882Z",
    "type": "platform.report",
    "record": {
        "requestId": "3c16579f-33eb-42b6-aae0-f204872d7ebd",
        "metrics": {
            "durationMs": 1581.56
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-24T06:54:09.302Z",
                "durationMs": 1579.247
            },
            {
                "name": "responseDuration",
                "start": "2026-02-24T06:54:10.881Z",
                "durationMs": 1.222
            }
        ],
        "status": "success"
    }
}

We see the responseLatency of this Lambda function is 1579 milliseconds. You might observe a different latency, because it also depends on the type EC2 instance itself. In part 2, we defined the following allowed EC2 types within the Capacity Provider: m7a.large, m6a.large. Let's send the same request once again and look into the CloudWatch metrics of this Lambda function. We likely (in case we hit the same EC2 instance behind) find something similar to :

{
    "time": "2026-02-24T06:57:03.768Z",
    "type": "platform.report",
    "record": {
        "requestId": "371879fb-588f-4c7f-b80a-8586abaf547d",
        "metrics": {
            "durationMs": 41.937
        },
        "spans": [
            {
                "name": "responseLatency",
                "start": "2026-02-24T06:57:03.727Z",
                "durationMs": 40.681
            },
            {
                "name": "responseDuration",
                "start": "2026-02-24T06:57:03.768Z",
                "durationMs": 0.461
            }
        ],
        "status": "success"
    }
}

We see the responseLatency of this Lambda function being 41 milliseconds only. What's going on here? The article Introducing AWS Lambda Managed Instances: Serverless simplicity with EC2 flexibility clearly states: Lambda automatically routes requests to preprovisioned execution environments on the instances, eliminating cold starts that can affect first-request latency. Do we still have cold starts? They are much lower than measured (with Java 21) for the default Lambda, which were more than 3 seconds, but still.

The truth is that if we look into the Lambda execution environment lifecycle, the usage of the Lambda Managed Instances compute type with the preprovisioned execution environments on the instances eliminates the following initializations:

Lambda extension (if you have it)
Execution runtime (in our case, JVM startup with Java 25 version)
Lambda Function initialization

What LMI can't eliminate is the behavior of the particular programming language, like a JVM warm-up period. This warm-up period can usually be attributed to lazy class loading and just-in-time compilation, which optimize the JVM for subsequent requests that execute identical code. There are a lot of articles about How to Warm Up the JVM
or talks like Keeping Your Java Hot by Solving the JVM Warmup Problem in general, but please keep the following in mind:

Amazon Corretto doesn't support [CRaC].(https://openjdk.org/projects/crac/)
LMI doesn't support [SnapStart].(https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)
We don't have access to the underlying EC2 instance to experiment with CDS and AOT cache.

If you're already happy with this cold start, which only occurs when the Lambda function first reaches a particular EC2 instance (due to your autoscaling policy, new EC2 instances may be started), you don't need to do anything. Otherwise, in the next article, we'll optimize our Lambda function to improve this cold start time.

Conclusion

In this article, we measured the initial Lambda function performance (the Java code was intentionally not optimized) and still saw a quite noticeable cold start when the request to the Lambda function reached the underlying EC2 instance for the first time. We found out that a Lambda function with the Lambda Managed Instances compute type can't eliminate the behavior of the particular programming language, like a JVM warm-up period. In the next article, we'll optimize our Lambda function to improve this cold start time significantly.

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.

AWS Lambda Managed Instances with Java 25 and AWS SAM – Part 4 Monitoring, unsupported features, challenges and pricing

Vadym Kazulkin — Mon, 02 Mar 2026 15:21:44 +0000

Introduction

In part 1 of the series, we explained the ideas behind AWS Lambda Managed Instances and introduced our sample application. In part 2, we explained what a Lambda Capacity Provider is and how to create it using AWS SAM. Part 3 was about how to create Lambda functions and attach them to a capacity provider. In this article, we’ll cover the following topics: monitoring, currently unsupported features, current challenges, and pricing.

Capacity Provider Monitoring

Capacity Provider provides various metrics. To see them, you can select the Capacity Provider by name and go to the “Monitoring” tab, or select the metrics from CloudWatch:

The following metrics are provided:

Capacity provider CPU utilization
Capacity provider memory utilization
Capacity provider allocated utilization
Execution environment CPU utilization per function
Execution environment memory utilization per function
Execution environment count per function
Capacity provider instance counts

Unsupported Features

These Lambda features, which we know from the default compute type, are currently unsupported:

SnapStart
Provisioned concurrency
Reserved concurrency

They all made sense when used with Firecracker microVM-based execution environment, and don’t make sense with (pre-provisioned) EC2-based LMIs, which don’t suffer from the cold starts.

Currently, not all instance types are supported:

No GPU support
No t-family (t2, t3, t4g) support

For a list of supported instance types, go to the AWS Lambda Pricing page and select our AWS Region.

Current challenges

It’s not possible to switch between Lambda Default and Lambda Managed Instances, also due to different concurrency models. I personally would find it better if there were such an easy switch possibility between both compute types, because at the beginning and at the low scale, Lambda default compute time is nearly always a preferable and cheaper choice (even with the purchased saving plans or reserved instance). The switch to LMI compute type makes sense in the future, at some point in time, and only for certain workloads (for example, for those which have reached high-traffic, steady-state workloads)
It’s not possible to cost-effectively set up Lambda with LMI compute type for staging and test environments with low consumption or for test purposes only. The possible workaround is to set min and max execution environments to 0 when starting to invoke a Lambda function, reset those values (for example, to min=1 and max=2), after end using it, set min and max execution environments back to 0. This requirement changes in IaC and re-deploying the stack multiple times, which takes time and impedes the user experience. It would be better if the min execution environment value could be set to 0, independent of the max value, and scale the execution environment down to 0 is possible (with explicit choice in the IaC) in case there was no usage for a long (configurable) period of time.

Lambda Managed Instance pricing

Lambda Managed Instances pricing has three components:

Request charges: $0.20 per million requests
Compute management fee: 15% premium on the EC2 on-demand instance price for the instances provisioned and managed by Lambda (Premium for each instance type provided below)
EC2 instance charges: Standard EC2 instance pricing applies for the instances provisioned in your capacity provider. You can reduce costs by using Compute Savings Plans, Reserved Instances, or other EC2 pricing options

Note that Lambda Managed Instances functions will not pay separately for the execution duration of each request, unlike Lambda (default) compute type functions.

Event Source Mappings: For workloads using provisioned Event Poller Units (EPUs) with event sources like Kafka or SQS, standard EPU pricing applies.

Conclusion

In this article, we covered the following topics: monitoring, currently unsupported features, current challenges, and pricing.

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.