DEV Community: Vadym Kazulkin

AWS Lambda Managed Instances with Java 25 and AWS SAM – Part 7 Implement scheduled scaling

Vadym Kazulkin — Mon, 01 Jun 2026 15:36:09 +0000

Implement scheduled scaling

Recently, Amazon EventBridge Scheduler added 619 new SDK API actions. One of these actions adjusts the Lambda function's minimum and maximum execution environments for Lambda Managed Instances (LMI) on a recurring or one-time schedule. This is useful for predictable traffic patterns, such as scaling up before peak hours and scaling down during off-peak hours. We can use CloudFormation or the latest versions of AWS CDK or AWS CLI to perform this action. In our example, we'll use AWS CLI to adjust the Lambda Function Scaling Configuration, for which we'll use the PutFunctionScalingConfig API as a universal target. We'll use the Lambda function with the name GetProductByIdJava25WithLMI, which we introduced in part 1.

First of all, let's create an SQS dead-letter queue, which we'll use for our action:

aws sqs create-queue --queue-name scheduler-dlq

Next, let's create an EventBridge Scheduler IAM execution role with the name scale-lambda-managed-instances-eventbridge-scheduler-role. This role grants permission to call the lambda:PutFunctionScalingConfig and send the message to the dead-letter queue on our target function.

This is how the trusted policy looks for the IAM role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "scheduler.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

And this is how the IAM policy looks (use the ARNs of the Lambda function and SQS dead-letter queue here):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "lambda:PutFunctionScalingConfig"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:lambda:{aws_region}:{aws_account_id}:function:GetProductByIdJava25WithLMI:$LATEST.PUBLISHED"
        },
        {
            "Effect": "Allow",
            "Action": [
                "sqs:SendMessage"
            ],
            "Resource": [
                "arn:aws:sqs:{aws_region}:{aws_account_id}:scheduler-dlq"
            ]
        }
    ]
}

Please replace the values of {aws_region} and {aws_account_id} with your own values, and adjust the Lambda function and SQS Queue names if needed.

Now, let's create the scheduler:

aws scheduler create-schedule \
  --name "ScaleLambdaManagedInstances" \
  --schedule-expression "at(2026-05-18T08:10:00)" \
  --flexible-time-window '{"Mode": "OFF"}' \
  --target '{
     {"DeadLetterConfig": {"Arn": "arn:aws:sqs:{aws_region}:{aws_account_id}:scheduler-dlq"},
    "Arn": "arn:aws:scheduler:::aws-sdk:lambda:PutFunctionScalingConfig",
    "RoleArn": "arn:aws:iam::{aws_account_id}:role/scale-lambda-managed-instances-eventbridge-scheduler-role",
    "Input": "{\"FunctionName\": \"GetProductByIdJava25WithLMI\", \"Qualifier\": \"$LATEST.PUBLISHED\", \"FunctionScalingConfig\": {\"MinExecutionEnvironments\": 5, \"MaxExecutionEnvironments\": 10}}"
  }'

Let's explain what happens here:

First, we create the schedule with the name ScaleLambdaManagedInstances using a one-time schedule (executes at 08:10 on May 18, 2026). You can use other Schedule types in EventBridge Scheduler, like cron-based expressions.
Then, we target the PutFunctionScalingConfig Scheduler API as a universal target.
Next, we specify the SQS dead-letter queue ARN created above
Then, we specify the IAM execution Role ARN created above
Next, we specify the new MinExecutionEnvironments and MaxExecutionEnvironments values in the Input payload
Finally, as the scheduler input, we specify the name of the Lambda function and its qualifier (usually $LATEST.PUBLISHED), for which we'd like to change the Function Scaling Configuration. In our case, we set MinExecutionEnvironments to 5 and MaxExecutionEnvironments to 10.
We can also optionally set the retry policy and encryption.

After creating the schedule, we'll see something similar in the Amazon EventBridge Scheduler Service:

After the scheduler has run, we can verify that the Lambda function Scaling Configuration has changed:

It's also very important to configure the dead-letter queue. First, I didn't do it, and configured the Lambda function Resource ARN in the IAM policy like arn:aws:lambda:{aws_region}:{aws_account_id}:function:GetProductByIdJava25WithLMI. I observed that the scheduler hasn't been invoked and saw the errors in Amazon CloudWatch.
By configuring the dead-letter queue, I saw the exact error message:

ERROR_CODE: AccessDeniedException
ERROR_MESSAGE :

User: arn:aws:sts::{aws_account_id}:assumed-role/scale-lambda-managed-instances-eventbridge-scheduler-role/f375e2c757da339a8d593587ce800265 
is not authorized to perform: lambda:PutFunctionScalingConfig on resource: 
arn:aws:lambda:{aws_region}:{aws_account_id}:function:GetProductByIdJava25WithLMI:$LATEST.PUBLISHED 
because no identity-based policy allows the lambda:PutFunctionScalingConfig action

With that, it was clear to me that I needed to append $LATEST.PUBLISHED to the ARN of the Lambda function. Please also use Troubleshooting Amazon EventBridge Scheduler, in case you experience some issues.

Here, we scaled up the capacity at the given time, the same way we can scale it down. Things to pay attention to:

For workloads with predictable peaks, create multiple schedules to match your traffic pattern: one to scale up your function before peak hours, and another to scale down after peak hours. Each schedule follows the same pattern with updated MinExecutionEnvironments and MaxExecutionEnvironments values.
Scheduled scaling adjusts the provisioned floor and ceiling of execution environments, but actual scaling between min and max still responds to CPU utilization and concurrency saturation.
If your traffic more than doubles within 5 minutes of a scheduled scale-up, you might still experience throttling as capacity is provisioned.
When scaling to zero to deactivate a function, remember that reactivation requires an explicit PutFunctionScalingConfig call with non-zero values.

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 5 Deploy MCP client for Conference application on AgentCore Runtime

Vadym Kazulkin — Tue, 26 May 2026 14:40:49 +0000

Introduction

In part 2, we explained how to deploy and run our conference search application on the Amazon Bedrock AgentCore Runtime as the MCP server. In this article, we'll develop the (MCP-) client, capable of talking to our application running on AgentCore Runtime. Later, in part 3, we developed the (MCP-) client, capable of talking to our application running on AgentCore Runtime. In part 4, we looked at how to provide the MCP Tools for the Conference application via AgentCore Gateway in a centralized way.

As we saw in previous articles, the local MCP client for the Conference application, to talk to AgentCore Runtime or Gateway, became quite big. If we have many customers using such a client, changing and operating it can become quite challenging. That's why, in this article, we look at how to deploy and run our MCP client on AgentCore Runtime.

Implement the MCP client for the Conference application to be deployable on AgentCore Runtime

We'll reuse the MCP client based on Spring AI that we implemented in parts 3 and 4. But as we need to make some small changes to deploy it on AgentCore Runtime, I created a new spring-ai-1.1-conference-app-agent-bedrock-agentcore-runtime. It consists of the agent and Infrastructure as Code subfolders.

Let's first look at the changes that we need to make to the client. AgentCore Runtime also supports the HTTP protocol contract, which we'll use to deploy our MCP client and talk to it. This contract puts some requirements on the client:

Container requirements:

Host : 0.0.0.0
Port : 8080 - Standard port for HTTP-based agent communication
Platform : ARM64 Docker container - Required for compatibility with the AgentCore Runtime environment. I usually borrow t4g small EC2 instance on AWS to build it.

Path requirements:

/invocations endpoint: POST endpoint for agent interactions
/ping endpoint: GET endpoint for health checks

You can read more about this topic in the HTTP protocol contract article.

The only changes we need to make to our REST Controller are to implement these path requirements. If we use asynchronous communication, the entry point looks like:

@PostMapping(value = "/invocations", consumes = { "*/*" })
public Flux<String> invocations(@RequestBody String prompt) {
   var token = getAuthTokenViaHttpClient();
   var client = McpClient.async(getMcpClientTransport(token)).build();
   ...
  var toolCallbacks = concatWithStream(asyncMcpToolCallbackProvider
 .getToolCallbacks(), ToolCallbacks.from(new DateTimeTools()));

  return this.chatClient.prompt().user(prompt)
    .toolCallbacks(toolCallbacks)
        .stream().content();
}

For synchronous communication, the entry point looks like:

@PostMapping(value = "/invocations", consumes = { "*/*" })
public String invocations(@RequestBody String prompt) {
   var token = getAuthTokenViaHttpClient();
   var client = McpClient.async(getMcpClientTransport(token)).build();
   ...
  var toolCallbacks = concatWithStream(asyncMcpToolCallbackProvider
 .getToolCallbacks(), ToolCallbacks.from(new DateTimeTools()));

  return this.chatClient.prompt().user(prompt)
    .toolCallbacks(toolCallbacks)
        .call().content();
}

For adding the path to /ping, we have different options. We can either add such a simple method:

@GetMapping("/ping")
public String ping() {
   return "{\"status\": \"healthy\"}";
}

Or use Spring Boot Actuator service and add some properties to the application.properties:

management.endpoints.web.exposure.include=health
management.endpoints.web.base-path=/
management.endpoints.web.path-mapping.health=ping

As we need to deploy our MCP client as an ARM64 Docker container, I also added a simple Docker file:

FROM amazoncorretto:25

COPY target/spring-ai-1.1-conference-app-agent-bedrock-agentcore-runtime-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

Let's build the Docker file and upload it to the Amazon Elastic Container Registry:

# build the application
mvn clean package 

# build the Docker image
sudo docker build --no-cache -t spring-ai-conference-app-agent-bedrock-agentcore-runtime:v1 

# Login to ECR
aws ecr get-login-password --region {region} | sudo docker login --username AWS --password-stdin {account_id}.dkr.ecr.{region}.amazonaws.com  

# Create ECR repository (if it doesn't exist)
aws ecr create-repository --repository-name spring-ai-conference-app-agent-bedrock-agentcore-runtime --image-scanning-configuration scanOnPush=true --region {region}  

# Tag the Docker image
sudo docker tag spring-ai-conference-app-agent-bedrock-agentcore-runtime:v1 {account_id}.dkr.ecr.{region}.amazonaws.com/spring-ai-conference-app-agent-bedrock-agentcore-runtime:v1

# Push the Docker Image to the ECR repository
sudo docker push {account_id}.dkr.ecr.{region}.amazonaws.com/spring-ai-conference-app-agent-bedrock-agentcore-runtime:v1

Please replace AWS {account_id} and {region} with our own values. Also, your version may not be v1 but a different one.

We can also build the Docker image by using Buildpack support built into Spring instead of a Dockerfile. Just use the Maven task spring-boot:build-image.

We don't need to make any other changes on the MCP client itself.

Let's now cover the IaC part with CDK for Java, which I implemented in RuntimeWithMCPStack stack. We've already covered many steps in creating the CDK App and Stack, and even the AgentCore Runtime with the MCP protocol, in part 2. For a more detailed explanation, I refer to this article.

First, let's take a look at the creation of the AgentCore Runtime:

 Runtime.Builder.create(this, "MCPRuntime-125")
   .runtimeName(appName.replace("-", "_")+ "_runtime")
   .protocolConfiguration(ProtocolType.HTTP)
   .description("AgenCore Runtime with MCP protocol for running conference app")
      ...
   .build();

Here we set some common properties, such as the runtime name, description, and protocol (in our case, HTTP).

Now let's look at the relevant code parts to assign this code artifact to the AgentCore Runtime:

var ecrImageURI= ConventionalDefaults.
    getContextVariableValueWithReplacedAccountId(this, "ecrImageURIForConferenceSearchAndApplicationAgent");            

var agentRuntimeArtifact =    
    AgentRuntimeArtifact.fromImageUri(ecrImageURI);
   ....

Runtime.Builder.create(this, "MCPRuntime-125")
    .agentRuntimeArtifact(agentRuntimeArtifact)
    ...
    .build();

First, we get the value of the variable ecrImageURI, which points to the imageURI in the ECR we pushed previously. This is typically done in the cdk.json:

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      ""ecrImageUR": "{AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/spring-ai-conference-app-agent-bedrock-agentcore-runtime:v1"
 }
}

Please adjust the value so that it matches your imageURI. We use the placeholder {AWS_ACCOUNT_ID} there. The reason for it is that I don't want to expose the AWS account ID publicly. That's why I wrote the following utility method getContextVariableValueWithReplacedAccountId in the ConventionalDefaults class to replace the placeholder with the real value:

static String getContextVariableValueWithReplacedAccountId(Stack stack, String contextVariableName) {
   var awsAccountId=(String)stack.getNode().tryGetContext("awsAccountId");
   if(awsAccountId == null || awsAccountId.trim().isEmpty()) {
      System.out.println("please provide your aws account id as as content to the call, for example: cdk deploy -c awsAccountId=1234567890101");
    }
   var contextVariableValue= getContextVariableValue(stack, contextVariableName);
   return replaceAWSAccountID(contextVariableValue, awsAccountId);
 }

static String getContextVariableValue(Stack stack, String contextVariableName) {
   return (String)stack.getNode().tryGetContext(contextVariableName);
 }

private static String replaceAWSAccountID(String configParam, String awsAccountId) {
   return configParam.replace("{AWS_ACCOUNT_ID}", awsAccountId);
}

Then we create AgentRuntimeArtifact from the image URI and set it as AgentCore Runtime agentRuntimeArtifact property.

Now let's cover the next part - defining the IAM execution role. It's very difficult to automate this part as it takes plenty of time. If I find it, I'll provide the IaC part in the future :). I refer you to the article IAM Permissions for AgentCore Runtime for more information. You can also read my article Amazon Bedrock AgentCore Runtime - Part 2 Using Bedrock AgentCore Runtime Starter Toolkit with Strands Agents SDK, where I explained this part. In that article, we developed the agent in Python with the Strands Agents framework and deployed it on AgentCore Runtime.

Once we have defined the IAM role, we need to configure it in the cdk.json:

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "roleArnForTheAgentCoreRuntime": "arn:aws:iam::{AWS_ACCOUNT_ID}:role/service-role/spring-ai-conference-search-application-agentcore-runtime-role",
    ....
   }
}

We use the placeholder for the AWS account ID as explained above. Here is the relevant code to grab the value of the roleArnForTheAgentCoreRuntime variable and set it to the execution role of the Runtime from the RuntimeWithMCPStack:

var roleArnForTheAgentCoreRuntime=ConventionalDefaults
   .getContextVariableValueWithReplacedAccountId(this, "roleArnForTheAgentCoreRuntime");

var role=Role.fromRoleArn(this,"roleArnForTheAgentCoreRuntimeRole", roleArnForTheAgentCoreRuntime);

Runtime.Builder.create(this, "MCPRuntime-123")
   .runtimeName(appName.replace("-", "_")+ "_runtime")
   ...
  .executionRole(role)
  .authorizerConfiguration(RuntimeAuthorizerConfiguration.usingIAM())
  .build();

Here, we also use an IAM authorizer for the inbound AgentCore Runtime authentication. This is the default authentication and authorization mechanism that works automatically without additional configuration. You can also use JSON Web Tokens (JWT) as we showed in part 2.

Now we are ready to deploy our MCP client on the AgentCore Runtime. The command to do it is:

cdk deploy -c awsAccountId={YOUR_AWS_ACCOUINT_ID}

Here is how the AgentCore Runtime looks in the console after its creation:

We'll need the Runtime ARN, which we see in the output of this command. Or we can grab it in the service console.

Now we still need to write a client that communicates with our MCP client on the Runtime. I provided such an InvokeRuntimeAgent client written in Java, but you can use any programming language for which AWS provides a (bedrockagentcore) SDK:

private static final String AGENT_RUNTIME_ARN="arn:aws:bedrock-agentcore:us-east-1:{AWS_ACCOUNT_ID}:runtime/spring_ai_conference_search_application_runtime-143wvBghklZ";

void main() throws Exception {

 String payload =
   "{\"prompt\":\"Please provide me with the list of conferences, including their IDs, 
with the Java topic happening in 2027, with the call for papers open today. 
Also, provide me with the list of my talks with this topic in the title. 
Finally, for each conference and talk retrieved, apply individually for the conference.\"}";

  var httpClient=ApacheHttpClient.builder()
      .connectionTimeout(Duration.ofMinutes(5))
      .socketTimeout(Duration.ofMinutes(5))
      .build();

  var bedrockAgentCoreClient = BedrockAgentCoreClient.builder()
      .region(Region.US_EAST_1)
      .httpClient(httpClient)
      .build();

  var invokeAgentRuntimeRequest = InvokeAgentRuntimeRequest.builder()                 
     .agentRuntimeArn(replaceAWSAccountID(AGENT_RUNTIME_ARN))                               
     .qualifier("DEFAULT")
     .contentType("application/json")
     .payload(SdkBytes.fromUtf8String(payload)).build();
      try (var responseStream = bedrockAgentCoreClient
     .invokeAgentRuntime(invokeAgentRuntimeRequest)) {
     var text = new String(responseStream.readAllBytes(), StandardCharsets.UTF_8); 
        System.out.println(text);
}

Let's go step-by-step through it. First of all, we define RUNTIME_ARN, which we deployed in the step before. Please still use the {AWS_ACCOUNT_ID} placeholder, which will be dynamically replaced with your AWS Account ID. When we create BedrockAgentCoreClient. We also explicitly set the Apache HTTP client with the extended connection and socket timeouts. Default 30-second timeouts maybe to short for communication with the Runtime. Then we create InvokeAgentRuntimeRequest and set the agent Runtime ARN, qualifier (always DEFAULT), content type, and payload. The payload is our prompt. You can see the examples of the prompts in part 4 as we're communicating with the same MCP client, but deployed elsewhere. When we invoke the invokeAgentRuntime method on the bedrockAgentCoreClient by providing the invokeAgentRuntimeRequest and convert the agent response to a string.

Conclusion

In this article, we looked at how to deploy and run our MCP client on AgentCore Runtime. With that, our MCP client now scales nicely within the Runtime.

Of course, you can create a nicer client by providing UI for entering the prompt and providing the agent response as a result. My goal was only to demonstrate how to implement such a client. Now we can change and redeploy our MCP client based on Spring AI on the AgentCore Runtime as often as we want. The client code remains unchanged as long as the Runtime ARN remains unchanged.

Starting from the next article, we'll look at the Spring AI AgentCore functionality. Spring AI AgentCore SDK is an open-source library that brings Amazon Bedrock AgentCore capabilities into Spring AI through familiar patterns: annotations, auto-configuration, and composable advisors.

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.

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 4 Provide MCP tools for Conference application via AgentCore Gateway

Vadym Kazulkin — Mon, 18 May 2026 14:09:12 +0000

Introduction

In part 2, we explained how to deploy and run our conference search application on the Amazon Bedrock AgentCore Runtime as the MCP server. In this article, we'll develop the (MCP-) client, capable of talking to our application running on AgentCore Runtime. Later, in part 3, we developed the (MCP-) client, capable of talking to our application running on AgentCore Runtime. In this article, we'll look at another alternative to AgentCore Runtime to host MCP servers on AgentCore - AgentCore Gateway.

Provide the MCP Tools for the Conference application via AgentCore Gateway

Let's imagine a hypothetical situation: we not only want to search for the conferences, but also create, search, and apply for the talks for them. With this, our conference application now supports not only the attendee role but also the speakers. This is the reason why I added functionality to support conference search by the open call for papers criteria, see part 2. This is required for the conference speakers to determine whether it's still possible to apply for the conference with their talks.

When searching for conferences, we didn't have a public API, which is why we created MCP. On the other hand, for creating, searching, and applying the talks for the conferences, we indeed have a public API. Let's assume this API is hosted on the Amazon API Gateway. But it could also be any external application that exposes an OpenAPI specification. How to implement such a use case? Of course, we can use Amazon Bedrock AgentCore Gateway to securely connect our API to the AgentCore Gateway. The AgentCore Gateway can expose API functionality as MCP tools. But with this, we'll need to authenticate and hold the connection to multiple sources: AgentCore Runtime and Gateway. Without a centralized approach, customers face significant challenges: discovering and sharing tools across organizations becomes fragmented, managing authentication across multiple MCP servers grows increasingly complex, and maintaining separate gateway instances for each server quickly becomes unmanageable.

The centralized approach, which exposes all the tools from the central (MCP server) endpoint, would be a much better solution for our use case. Luckily, AgentCore Gateway helps to solve these challenges by treating existing MCP servers as native targets. This gives us a single point of control for routing, authentication, and tool management. It makes it as simple to integrate MCP servers as to add other targets to the gateway. AgentCore made it possible by supporting multiple targets. Those are, as of now: OpenAPI, Smithy, Amazon API Gateway, AWS Lambda, MCP Servers, and Integrations:

Conference Talks and Applications Demo

For creating, searching, and applying the talks for the conferences, I implemented a small conference-talks-and-applications-demo:

I currently don't use any database to store the talks and conference applications for simplicity reasons. My goal is only to demonstrate the approach.

I maintain a static list of the talks in the GetConferenceTalksByTitleSubstring class. The search consists of looking for the provided substring of the title.
When creating a new talk, I generate its random ID between 1 and 100 in CreateConferenceTalk class and return the talk with ID, title, and description.
When applying for a talk for a specific conference, I simply acknowledge that the application is created in CreateConferenceTalk class.

I prefer to use AWS SAM as IaC for pure Serverless applications. Unfortunately, AWS SAM doesn't provide any IaC for Amazon Bedrock AgentCore yet. Also, SAM has some limitations, as it's, for example, not possible to create the response codes for each API. And those response codes are required by the OpenAPI specification to be present. That's why I created OpenAPI spec on my own for it. We can refer to this specification when defining the API like this:

MyApi:
  Type: AWS::Serverless::Api
  Properties:
    StageName: !Ref Stage
    DefinitionBody:
        Fn::Transform
           Name: AWS::Include
           Parameters:
             Location: ConferenceTalksAndApplicationsAppAPI-OpenAPISpec.yaml

We also secured our API with an API key, whose value is by definition passed as the HTTP header parameter "x-api-key". This will play a role when we configure the outbound authentication of the AgentCore Gateway API Gateway target:

MyApiKey: 
  Type: AWS::ApiGateway::ApiKey
  ....
  Properties: 
    Name: "ConferenceTalksAndApplicationsAppAPIKey"
    Description: "ConferenceTalksAndApplicationsApp API Key"
    Enabled: true
    GenerateDistinctId: false
    Value: a6ZbcDgjkQW10BN56ASR25
    ...

We also defined an API stage with the name prod. Now, we can deploy this application by executing sam deploy -g, and we will see the individual URL in the response. For example, https://k370s19lk3.execute-api.us-east-1.amazonaws.com/prod. We'll need the REST API ID, which is in our case k370s19lk3, later when creating the IaC for the AgentCore Gateway.

Create AgentCore Gateway with different targets

In part 2, we started to create the IaC for the Conference (Search) application. It consisted mainly of the AgentCore Runtime with the MCP protocol and everything needed for that, like the Cognito User (Client) Pool. We used CDK for Java for it. We'll now call this application the Conference application, as we are extending its functionality beyond the search. Our goal is now to create AgentCore Gateway with 2 targets:

existing AgentCore Runtime with MCP protocol for the conference search (MCP) tools
conference talks and applications demo deployed on Amazon Gateway API to expose all its APIs as (MCP) tools.

You can find the full source code in the GatewayTargetStack class.

Let's go step-by-step through it. We first create the AgentCore Gateway itself:

var gateway= Gateway.Builder.create(this, "Gateway-123")
      .gatewayName(appName.replace("_", "-")+ "-gateway")
      .authorizerConfiguration(CustomJwtAuthorizer.Builder
        .create().allowedClients(
          List.of(UserClientPoolStack.
               userPoolClient.getUserPoolClientId()))
      .discoveryUrl(UserClientPoolStack.COGNITO_DISCOVERY_URL).build())
            .role(RuntimeWithMCPStack.role)
            .description("AgenCore Runtime with MCP protocol for running conference search app")
           .build();

The most interesting part is configuring the custom JWT authorizer as an inbound authentication. Here we reuse the Cognito User (Client) Pool created in part 2. We set the same user client pool ID and discovery URL. We also reuse the same AWS IAM role that we used to create AgentCore Runtime in part 2. Please also read the Getting started with Policy in AgentCore in addition to the resources from part 2 on how to create one.

Now, let's create the AgentCore Gateway target of our MCP Server running on AgentCore Runtime:

GatewayTarget.Builder.create(this, "MCP-Target-123")           
     .targetConfiguration(McpServerTargetConfiguration.create(endpoint))         
     .credentialProviderConfigurations(oauthCredentialProviderConfigs)
         .gatewayTargetName("mcp-target")
         .description("AgentCore Runtime MCP Server Target ")
         .gateway(gateway)
         .build();

We set McpServerTargetConfiguration, which defines that the Gateway target is the MCP Server running on AgentCore Runtime. Also, we set the target name and description, and provide the AgentCore Gateway to which this target belongs. We need to set the endpoint URL, which always follows the same schema:

var endpoint="https://bedrock-agentcore."+region + 
        ".amazonaws.com/runtimes/" +
        RuntimeWithMCPStack.runtime.getAgentRuntimeId()+
       "/invocations? 
       qualifier=DEFAULT&accountId="+Stack.of(this).getAccount();

We obtain the runtime ID property from the created AgentCore Runtime in the RuntimeWithMCPStack stack. The next part is to configure the outbound authentication. This means to configure how the Agentcore Gateway MCP target authenticates with the AgentCore Runtime with the MCP protocol. For this, we need to use AgentCore Identity.
As described in the following issue, it's currently not possible to create the AgentCore Identity with CloudFormation. That's why CDK also can't provide this functionality. That's why we need to create it manually and then provide the configuration for this stack. Let's secure it with the existing OAuth Client. Let's go to AgentCore Identity and click on "Add Outbound Auth" -> "Add OAuth Client". Then select "Custom Provider" -> "Discovery URL" :

We can reuse the Cognito User Pool Client ID, Client Secret, and Discovery URL from part 2.

After we created the AgentCore Identity, let's grab its ARN:

The Client Secret will be automatically stored as a Secret in the AWS Secrets Manager. Let's also grab Secret ARN:

Now, let's configure both in the cdk.json :

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "agentcoreIdentityOutboundOAuthArn": "arn:aws:bedrock-agentcore:us-east-1:{AWS_ACCOUNT_ID}:token-vault/default/oauth2credentialprovider/resource-provider-oauth-gateway",
      "oAuthSecretArn": "arn:aws:secretsmanager:us-east-1:{AWS_ACCOUNT_ID}:secret:bedrock-agentcore-identity!default/oauth2/resource-provider-oauth-gateway-ba3b089d-toYfaV",
  ....
   }
}

Please replace both values with your individual ARNs. I explained in part 2 how we handle the AWS Account ID. Now, let's create and configure the credential provider:

// CloudFormation, see the issue https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/2391
  var oAuthProviderArn = ConventionalDefaults.getContextVariableValueWithReplacedAccountId(this, "agentcoreIdentityOutboundOAuthArn");
  var oAuthSecretArn = ConventionalDefaults.getContextVariableValueWithReplacedAccountId(this, "oAuthSecretArn");

  var oauthCredentialProviderConfigs = List.of(GatewayCredentialProvider
      .fromOauthIdentityArn(OAuthConfiguration.builder()
          .providerArn(oAuthProviderArn)
          .secretArn(oAuthSecretArn)
          .scopes(List.of())
          .build()));

  GatewayTarget.Builder.create(this, "MCP-Target-123")           
  .credentialProviderConfigurations(oauthCredentialProviderConfigs)
  ...
 .build();

We grab the AgentCore Identity and Secret ARNs and use them to create an OAuth Credential Provider. We then set it when creating the AgentCore Target credential provider configuration.

Now we are done with creating the AgentCore MCP Target. The next step is to create an Amazon API Gateway target. Please also read the article AgentCore Gateway Amazon API Gateway stages to gain an understanding of how AgentCore Gateway obtains the OpenAPI spec from the Amazon Gateway stage.

First of all, let's define the API stage name in the cdk.json:

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "restApiStageName": "prod"
   }
}

We'll pass the restApiId via the console parameter. We created it above when we deployed the conference talks and applications demo. Similar to AWS Account ID, which is public, we don't want to configure it in cdk.json:

  var restApiId=(String)this.getNode().tryGetContext("restApiId");

  var restApiStageName=ConventionalDefaults.getContextVariableValue(this, "restApiStageName");

  GatewayTarget.Builder.create(this, "APIGATEWAY-Target-123")         
    .targetConfiguration((ApiGatewayTargetConfiguration.Builder.create()
    .restApi(RestApi.fromRestApiId(this, "APIGATEWAY-ID", restApiId))
         .stage(restApiStageName).build()))
            ...
           .gatewayTargetName("apigateway-target")
           .description("Amazon ApiGateway Target ")
           .gateway(gateway)
           .build();

Here, we create the AgentCore Gateway Target as an Amazon API Gateway Target, set the target name and description. We also provide the REST API ID, stage, and AgentCore Gateway to which this target belongs.

We can define the tool filters. With that, we can shrink what Amazon API Gateway APIs will be exposed as MCP tools:

GatewayTarget.Builder.create(this, "APIGATEWAY-Target-123")           
  .targetConfiguration((ApiGatewayTargetConfiguration.Builder.create()
     .apiGatewayToolConfiguration(ApiGatewayToolConfiguration.builder()
       .toolFilters(List.of(
        ApiGatewayToolFilter.builder()
            .filterPath("/talks/{titleSubstring}")                                
                .methods(List.of(ApiGatewayHttpMethod.GET))                 
                .build(),
        ApiGatewayToolFilter.builder()
                .filterPath("/apply")
                .methods(List.of(ApiGatewayHttpMethod.POST))
                .build(),
        ApiGatewayToolFilter.builder()
                .filterPath("/talks")                    
                .methods(List.of(ApiGatewayHttpMethod.POST))
                .build()))

In our example, we expose all 3 APIs (/apply, /talks, //talks/{titleSubstring}) as MCP tools.

Next, let's use the tool override to give the MCP tools the proper names and descriptions:

GatewayTarget.Builder.create(this, "APIGATEWAY-Target-123")           
  .targetConfiguration((ApiGatewayTargetConfiguration.Builder.create()
     .apiGatewayToolConfiguration(ApiGatewayToolConfiguration.builder()
      .toolOverrides(List.of(
          ApiGatewayToolOverride.builder()
            .method(ApiGatewayHttpMethod.POST)
            .name("apply-to-conferences-w-conference-id-talk-id")
            .path("/apply")
            .description("apply to the conference with conference Id and talk Id")
            .build(), 
         ApiGatewayToolOverride.builder()
           .method(ApiGatewayHttpMethod.POST)
           .name("create-new-talk")
           .path("/talks")
           .description("create a new talk with talk Id, title and description")
           .build(),                    
         ApiGatewayToolOverride.builder()
           .method(ApiGatewayHttpMethod.GET)
           .name("get-talks-by-title-substring")
           .path("/talks/{titleSubstring}")
           .description("get talks by their title substring")
           .build()))

With that, LLM can easily find the right tool for the job.

The last part is to define how AgentCore Gateway handles the outbound authentication to the Amazon API Gateway. As described above and in the following issue, it's currently not possible to create the AgentCore Identity with CloudFormation. That's why CDK also can't provide this functionality. That's why we need to create it manually and then provide the configuration for this stack. Let's secure this Target with the API Key, as it is how we secured our Amazon Gateway API. Let's go to AgentCore Identity and click on "Add Outbound Auth" -> "Add API Key" :

Please put the same API Key that we used to secure our API. We defined it in the SAM template.

After we created the AgentCore Identity, let's grab its ARN:

The Client Secret will be automatically stored as a Secret in the AWS Secrets Manager. Let's also grab Secret ARN:

Now, let's configure both in the cdk.json:

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "agentcoreIdentityOutboundApiKeyArn": "arn:aws:bedrock-agentcore:us-east-1:{AWS_ACCOUNT_ID}:token-vault/default/apikeycredentialprovider/resource-provider-api-key-gateway",
      "apiKeySecretArn": "arn:aws:secretsmanager:us-east-1:{AWS_ACCOUNT_ID}:secret:bedrock-agentcore-identity!default/apikey/resource-provider-api-key-gateway-02d581b0-L9scmD",  ....
   }
}

Please replace both values with your individual ARNs. I explained in part 2 how we handle the AWS Account ID. Now, let's create and configure the credential provider:

var apiKeyProviderArn = ConventionalDefaults.getContextVariableValueWithReplacedAccountId(this, "agentcoreIdentityOutboundApiKeyArn");

var apiKeySecretArn = ConventionalDefaults.getContextVariableValueWithReplacedAccountId(this, "apiKeySecretArn");

var apiKeyProviderConfigs = List.of(GatewayCredentialProvider          
     .fromApiKeyIdentityArn(ApiKeyCredentialProviderProps.builder()
               .providerArn(apiKeyProviderArn)
               .secretArn(apiKeySecretArn)
               .credentialLocation(ApiKeyCredentialLocation                    
                   .header(ApiKeyAdditionalConfiguration.builder()
                     .credentialParameterName("x-api-key")
                     .credentialPrefix(" ")
                     .build()))
               .build()));

GatewayTarget.Builder.create(this, "APIGATEWAY-Target-123")           
  .targetConfiguration((ApiGatewayTargetConfiguration.Builder.create()
  ...
  .credentialProviderConfigurations(apiKeyProviderConfigs)
  ...
  build();

We grab the AgentCore Identity and Secret ARNs and use them to create an API Key Credential Provider. Then we define to set the credentials within the HTTP header with the name x-api-key. This is how we secured the Amazon API Gateway. Another option that AgentCore Gateway supports is to set them as query parameters. We then set them when creating the AgentCore Target credential provider configuration.

To deploy the AgentCore Gateway, please invoke cdk deploy spring-ai-conference-search-agentcore-gateway-with-mcp-server-target-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID} -c restApiId={YOUR_API_ID}:

After having successfully executed the AgentCore Gateway deployment, we'll see our Gateway in the console:

We need to grab the Gateway URL, which ends with /mcp. We also see both Gateway targets we created:

This AgentCore exposes 7 MCP tools in total:

4 tools for the conference search provided by the MCP server from part 2 and deployed on AgentCore Runtime.
3 tools to create a talk, search for existing talks, and apply for the conference with the talk. This 3 tools are provided through the Amazon API Gateway we deployed in this article.

Now, let's extend our Conference Application MCP client that we developed in part 3, so it can use this AgentCore Gateway MCP endpoint.

The important remaining topic is designing the IAM role and permissions so that AgentCore Gateway can handle inbound and outbound authentication and communicate with the Amazon API Gateway. I'll refer you to the articles, which cover those topics:

Extend our local Conference Application MCP client

In part 3, we developed a generic local MCP client capable of talking to each MCP server. I decided to extend it to be able to configure the AgentCore Gateway endpoint. This gives us the following options:

by configuring the amazon.bedrock.agentcore.runtime.id property in the application.properties to be not a blank string, we'll still connect to the MCP server running on AgentCore Runtime. It exposes only 4 MCP tools for the conference search.
by configuring the amazon.bedrock.agentcore.gateway.url property in the application.properties to be not a blank string, we'll connect to the AgentCore Gateway created previously, which exposes all 7 MCP tools. This is how we'll use it to show what is possible with that. Please make sure that amazon.bedrock.agentcore.runtime.id= is set to an empty string.
by configuring both properties, amazon.bedrock.agentcore.runtime.id take precedence. This is how I implemented the logic in the SpringAIAgentController class:

private String getMCPServerEndpoint() {
   if(!AGENTCORE_RUNTIME_ID.isBlank()) {
    return "https://bedrock-agentcore." + awsRegion + ".amazonaws.com/runtimes/"
       + AGENTCORE_RUNTIME_ID + "/invocations?qualifier=DEFAULT&accountId=" + this.getAccountId();
    } else if (!AGENTCORE_GATEWAY_URL.isBlank()) {
       return AGENTCORE_GATEWAY_URL;
    } else throw new RuntimeException(" no AgentCore Runtime Id or AgentCore Gateway URL defined");
}

You can change this logic if you wish.

Now we can use CURL or HTTPie to send some prompts. For example:

"Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today. Also, provide me with the list of my talks with this topic in the title. Finally, for each conference and talk retrieved, apply individually for the conference".

Here is an example of the request with HTTPie:

http GET http://localhost:8080/conference?prompt="Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today. Also, provide me with the list of my talks with this topic in the title. Finally, for each conference and talk retrieved, apply individually for the conference." Content-Type:text/plain.

Here is the correct LLM response:

Let's try another prompt:

http GET http://localhost:8080/conference?prompt="Please create a talk with a cool title (max 60 characters long) and description (max 300 characters long) about using Spring AI on the Amazon Bedrock AgentCore service. Then provide me with the list of conferences, including their IDs, with Java topics happening in 2026 and 2027, with the call for papers open today. Finally, for each conference, apply individually for it with the talk just created." Content-Type:text/plain.

Here is the correct LLM response again:

Cool, we created AgentCore Gateway, which gives us centralized access to the MCP tools that we need or the agent needs to accomplish the goal.

Conclusion

In this article, we looked at how to provide the MCP Tools for the Conference application via AgentCore Gateway in a centralized way.

As we saw in this and previous articles, the local MCP client for the Conference application, to talk to AgentCore Runtime or Gateway, became quite big. If we have many customers using such a client, changing and operating it can become quite challenging. That's why, in the next article, we look at how to deploy and run our MCP client on AgentCore 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.

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 3 Develop local MCP client for Conference application

Vadym Kazulkin — Mon, 11 May 2026 15:03:58 +0000

Introduction

Develop local MCP client for Conference application

You can find the source code of the MCP client in my spring-ai-1.1-conference-app-agent-local repository.

Let's go step-by-step through it.

First, in pom.xml, we include, among others, those dependencies:

spring-ai-bom - to include the general Spring AI functionality.
spring-boot-starter-web - as we develop the MCP client as a web application.
spring-ai-starter-model-bedrock-converse -as we use foundational models on Amazon Bedrock.
spring-ai-starter-mcp-client-webflux - to develop an asynchronous Spring AI MCP Client. We can use spring-ai-starter-mcp-client to develop a synchronous one.

SpringAIConferenceLocalMCPClient class is the main entry point to our application.

Second, in application.properties, we define some properties. Those are Spring AI-related:

spring.ai.bedrock.aws.region=us-east-1
spring.ai.bedrock.aws.timeout=10m
spring.ai.bedrock.converse.chat.options.max-tokens=100
spring.ai.bedrock.converse.chat.options.model=amazon.nova-lite-v1:0
spring.ai.mcp.client.type=ASYNC

We define the region where we host our application, and the timeout when talking to the Amazon Bedrock models. Then we also set the default Amazon Bedrock to use and a maximal number of tokens, and the MCP client type to ASYNC. We can also set SYNC instead, but we need to use another Spring AI MCP client dependency as described above.

We also include some application-related properties:

cognito.user.pool.name=UserPoolForAgentCoreMCP
cognito.user.pool.client.name=UserPoolClientWithUserAndPasswordForAgentCoreMCP
cognito.auth.token.resource.server.id=AgentCoreResourceServerId
amazon.bedrock.agentcore.runtime.id=spring_ai_conference_search_agentcore_runtime-6dnMIL9455

These are individual properties, whose values we need to set from the deployment of the Conference search MCP server. We described the configuration, creation process, and those properties of the MCP server in part 2.

Please ignore other properties like amazon.bedrock.agentcore.gateway.url as we will need them when we extend our application in the next articles.

The whole application logic is in the SpringAIAgentController class.

We inject the values of individual properties and build AWS service clients (STS and Cognito). This is how we create the ChatClient, which is the main interface of Spring AI to talk to the LLMs:

public SpringAIAgentController(ChatClient.Builder builder, ChatMemory chatMemory, @Value("${aws.region}") String awsRegion) {
   var options = ToolCallingChatOptions.builder()
    .model("us.anthropic.claude-sonnet-4-6")
    .maxTokens(2000)
    .build();

    this.chatClient = builder.defaultOptions(options).build();
}

We show here that we can optionally build ToolCallingChatOptions and override the default model name and the maximum number of tokens defined in application.properties. Then, we build the ChatClient, and can optionally set ToolCallingChatOptions.

Below is how the code for the method looks, which will receive the prompt from the user:

@GetMapping(value = "/conference", consumes = "text/plain")
public Flux<String> conferenceSearch(@RequestParam String prompt) {
  var token = getAuthTokenViaHttpClient();
  var client = McpClient.async(getMcpClientTransport(token)).build();
  client.initialize();
  var toolsResult = client.listTools(); 
  for (var tool : toolsResult.block().tools()) { 
    logger.info("tool found " + tool); 
  }

  var asyncMcpToolCallbackProvider = AsyncMcpToolCallbackProvider.builder()
     .mcpClients(client)
     .build();


  return this.chatClient.prompt().user(prompt)  
        .tools(new DateTimeTools())
        .toolCallbacks(asyncMcpToolCallbackProvider.getToolCallbacks())
        .stream()
        .content();
}

Let's break this code down and explain it. First, we need to obtain the JWT token:

var token = getAuthTokenViaHttpClient();

This, in turn, uses a bunch of Amazon Cognito services to achieve this goal:

private String getAuthTokenViaHttpClient() {
  var userPool = getUserPool();
  var userPoolClient = getUserPoolClient(userPool);
  var userPoolClientType = describeUserPoolClient(userPoolClient);
  var userPoolId = userPool.id();
  userPoolId = userPoolId.replace("_", "").toLowerCase();
  var url = "https://" + userPoolId + ".auth." + Region.US_EAST_1.id() + ".amazoncognito.com/oauth2/token";

  var SCOPE_STRING = RESOURCE_SERVER_ID + "/*";
  var entity = "grant_type=client_credentials&" + "client_id=" + userPoolClientType.clientId() + "&"
    + "client_secret=" + userPoolClientType.clientSecret() + "&" + "scope=" + SCOPE_STRING;

  try (var httpClient = HttpClients.createDefault()) {
     var httpPost = ClassicRequestBuilder.post(url)
       .setHeader("Content-Type", "application/x-www-form-urlencoded").setEntity(entity).build();
     return httpClient.execute(httpPost, new AuthTokenResponseHandler());       
}

Here, we use the configuration of the user (client ) names and the resource server ID from application.properties to obtain the user (client) pool. Then we construct the URL and the body (entity) of the HTTP request to obtain the authentication token. After it, we execute this request and obtain the token from the response:

private class AuthTokenResponseHandler implements HttpClientResponseHandler<String> {
@Override
  public String handleResponse(ClassicHttpResponse response) throws HttpException, IOException {
    var inputStream = response.getEntity().getContent();
    var responseString = new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);
    var responseMap = objectMapper.readValue(responseString, new TypeReference<Map<String, Object>>() {});
    return (String) responseMap.get("access_token");
   }
}

After we have obtained the token, we're ready to create the (asynchronous as configured) MCP client:

  var client = McpClient.async(getMcpClientTransport(token)).build();

Let's describe what happens when we invoke the getMcpClientTransport method:

private McpClientTransport getMcpClientTransport(String token) {        
  var MCP_SERVER_ENDPOINT= this.getMCPServerEndpoint();
  var headerValue = "Bearer " + token;
  var webClientBuilder = WebClient.builder()
     .defaultHeader("Authorization", headerValue)
     .defaultHeader("accept","application/json, text/event-stream")
     .defaultHeader("Content-Type","application/json");
     return WebClientStreamableHttpTransport
       .builder(webClientBuilder)
       .endpoint(MCP_SERVER_ENDPOINT).build();
}

We first construct the MCP_SERVER_ENDPOINT URL from the in application.properties configured AgentCore Runtime ID. In the next article, I'll add the use case to also add the AgentCore Gateway URL. Then, we create the WebClientBuilder by passing some HTTP headers, including the bearer token. After it, we create WebClientStreamableHttpTransport and set the web client builder and the MCP server endpoint. It's important to use the HTTP Streamable web client because AgentCore Runtime (and Gateway) only supports it.

Now we are ready to initialize our MCP client and obtain the list of tools from it:

client.initialize();
var toolsResult = client.listTools(); 
for (var tool : toolsResult.block().tools()) { 
    logger.info("tool found " + tool); 
}

We get all 4 tools that our Conference Search application from part 2 exposes, which we deployed on AgentCore Runtime.

Next, we need to create the list of tool callbacks from the MCP Client to pass to the ChatClient:

var asyncMcpToolCallbackProvider = AsyncMcpToolCallbackProvider.builder()
     .mcpClients(client)
     .build();

If you don't need all the tools, you can filter them and, for example, only leave those tools whose name contains Conference_Search_Tool_By_Topic as a substring, as shown below:

var asyncMcpToolCallbackProvider = 
AsyncMcpToolCallbackProvider.builder().mcpClients(client)
  .toolFilter(new McpToolFilter() {              
       @Override public boolean test(McpConnectionInfo info, Tool tool) { 
        return tool.name().toLowerCase()
                .contains("Conference_Search_Tool_By_Topic"); 
             } 
         }
      )
    .build();

Next, to enable search prompts such as "Please provide me with the list of conferences including their IDs, with Java topic happening in 2027, with call for papers open today", we need to obtain the current date. LLM doesn't know the current date, and for this, I wrote a small tool with the name DateTimeTools :

@Tool(description = "Get the current date ")
String getLocalDate() {
        return LocalDate.now().toString();       
}

It contains only one tool to get the current date. Then, we pass this local tool to the ChatClient by invoking the tools method. We also pass the tool callback list from the AsyncMcpToolCallbackProvider by invoking the toolCallbacks method. The last step is to use the ChatClient with the given prompt and tool (callbacks) to produce an answer to the prompt. This answer will be streamed back to the user:

  return this.chatClient.prompt().user(prompt)  
   .tools(new DateTimeTools())
   .toolCallbacks(asyncMcpToolCallbackProvider.getToolCallbacks())
   .stream()
   .content();

Let's build our application with mvn clean package and start it with: mvn spring-boot:run.

Now we can use CURL or HTTPie to send some prompts. For example:

"Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027".

Here is an example of the request with HTTPie:

http GET http://localhost:8080/conference?prompt="Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027" Content-Type:text/plain.

Here is the correct LLM response:

As you can see from the description and logs, LLM used the tool Conference_Search_Tool_By_Topic_And_Date from the MCP server to produce the answer. Let's try another prompt:

http GET http://localhost:8080/conference?prompt="Please provide me with the list of conferences, including their IDs, with Java topics happening in 2026 and 2027, with the call for papers open today" Content-Type:text/plain.

Here is the correct LLM response again:

As you can see from the description and logs, LLM used the tools to produce the answer. Conference_Search_Tool_By_Topic_Date_CFP_Open from the MCP server and the local tool Get_The_Current_Date to produce the answer.

Conclusion

In this article, we developed the (MCP-) client, capable of talking to our application running on AgentCore Runtime. In the next article, we'll look at another alternative to AgentCore Runtime to host MCP servers on AgentCore - AgentCore Gateway. We'll also compare both alternatives. In one of the next articles, I'll show you how to deploy and run this MCP client on the AgentCore Runtime as well, using the HTTP protocol. It's not always appropriate to work with the client locally.

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.

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 2 Deploy Conference Search application on AgentCore Runtime

Vadym Kazulkin — Mon, 04 May 2026 14:23:19 +0000

Introduction

In the article Introduction to Spring AI, we introduced the sample application to search for conferences. We also exposed its functionality as a set of MCP-compatible tools. In the article Explore Spring AI MCP Server with Streamable HTTP protocol, we ran this application as an MCP-Server locally and connected to it using the MCP Inspector or Amazon Q Developer.
Of course, running the application locally is not an enterprise-ready solution. That's why, in this article, we'll explain how to deploy and run our conference search application on the Amazon Bedrock AgentCore Runtime as the MCP server.

Adjustments of the conference search application

I decided to make some adjustments to the conference search application, which will act as the MCP server by exposing its functionality through tools. Please review the above-mentioned to gain a basic understanding of how to use the Spring AI framework with its rich set of features, including the MCP client and server functionality. You can find the updated version of our application in the spring-ai-1.1-conference-search-app-bedrock-agentcore-runtime-mcp-server repository.

I updated the examples to use Java 25 and recent Spring Boot 4 and Spring AI version 1.1.x versions. You can update it to the newest minor versions if you wish. And there is the Spring AI 2.x branch for Spring Boot 4 applications. The last one is currently in development and not GA. When it's released, I'll also provide my examples for the Spring AI 2.x version.

I also adjusted the static list of conferences to search for. Additionally, I updated the conference properties to set the conference (fake) dates in the future (the previous ones were mostly for 2025). And I also added 3 additional properties: conferenceId, callForPapersStartDate, and callForPapersEndDate. This enables us to search not only for all conferences, conferences by topic, and additionally by the date range, but also for the date when the call for papers is still open. In the course of the series, I'll use this functionality to apply for the conference when we extend our application.

With this, the Conference domain class looks like this:

public record Conference (Integer conferenceId, String name, Set<String> topics, String homepage, 
        LocalDate startDate, LocalDate endDate, LocalDate callForPapersStartDate, LocalDate callForPapersEndDate, 
        String city, String linkToCallforPapers) {
}

I also added one additional tool in the ConferenceSearchTool.

It's responsible for answering the following prompt: "Please provide me with the list of conferences, including their IDs, with a Java topic happening in 2027, with a call for papers open today." Here is how it's implemented:

@Tool(name = "Conference_Search_Tool_By_Topic_Date_CFP_Open", description = "Search for the conference list for exactly one topic provided, conference dates and the call for papers still open on the given date")
public Set<Conference> search(@ToolParam(description = "conference topic") String topic,
            @ToolParam(description = " the conference earliest start date") LocalDate earliestStartDate,
            @ToolParam(description = " the conference latest start date") LocalDate latestStartDate,
            @ToolParam(description = " the call for papers still open on this date") LocalDate callForPapersStillOpenOnThisDate) {

this.conferences.stream()
   .filter(c -> c.topics().contains(topic))
   .filter(c -> isConferenceStartDateInDateRange(c, earliestStartDate, latestStartDate))
   .filter(c -> isCallForPapersOpenOnThisDate(c, callForPapersStillOpenOnThisDate))
   .collect(Collectors.toSet());
}

We can run this updated version of the application locally as the MCP server, as described in the Explore Spring AI MCP Server with Streamable HTTP protocol.

Deploying the conference search application on the Amazon Bedrock AgentCore Runtime

I've written the whole article series about this service. So I refer to it for the overview of this service. AgentCore Runtime also lets us deploy and run Model Context Protocol (MCP) servers in the AgentCore Runtime, see Deploying MCP servers in AgentCore Runtime. In the next article, we'll develop the (MCP-) client, capable of talking to our application (MCP server).

One important thing is to understand How Amazon Bedrock AgentCore supports MCP. AgentCore supports both stateless and stateful streamable-HTTP MCP servers. By default, stateless mode (stateless_http=True) is recommended for basic MCP servers. The platform automatically adds an Mcp-Session-Id header for any request without one, so MCP clients can maintain connection continuity to the same Amazon Bedrock AgentCore Runtime session. Spring AI also supports Stateless Streamable-HTTP MCP Servers. To configure them, we need to add some properties to application.properties :

spring.ai.mcp.server.type=SYNC
spring.ai.mcp.server.protocol=STATELESS
server.port=8000
server.address=0.0.0.0

I tried to automate as much as possible for the IaC with AWS CDK for Java. Please read the article Getting started with the AWS CDK for the overview and installation. I usually use AWS SAM, but it currently doesn't have Bedrock AgentCore support. CDK AgentCore L2 construct is currently still alpha. Even with CDK, it turned out to be challenging because of the discovered issues and difficulties in fully automating roles, permissions, and Docker image creation with IaC. I'll give some guidance on how to proceed. You can find the whole IaC in the spring-ai-1.1-conference-app-bedrock-agentcore-cdk repository.

Let's first comment out the definition of the GatewayTargetStack stack in the CDKApp class:

public interface CDKApp {

String appName = "spring-ai-conference-search-agentcore";

static void main(String... args) {
   var app = new App();
   new UserClientPoolStack(app, appName, stackProperties());
   new RuntimeWithMCPStack(app, appName, stackProperties());
   //new GatewayTargetStack(app, appName, stackProperties());
   app.synth();  
 }

It contains the Stack using the AgentCore Gateway service, which we'll explore in the later articles. AgentCore Gateway also provides the functionality of the managed MCP server. I'll then give some recommendations on when to use the Runtime (directly) and when to use the Gateway.

Now, let's take a look at the RuntimeWithMCPStack, which we'll deploy later:

 var runtime = Runtime.Builder.create(this, "MCPRuntime-123")
    .runtimeName(appName.replace("-", "_")+ "_runtime")               
    .authorizerConfiguration(RuntimeAuthorizerConfiguration.usingJWT(UserClientPoolStack.COGNITO_DISCOVERY_URL, List.of(UserClientPoolStack.userPoolClient.getUserPoolClientId()), null))
                .description("AgenCore Runtime with MCP protocol for running conference search app")
                .protocolConfiguration(ProtocolType.MCP)
                .agentRuntimeArtifact(agentRuntimeArtifact)
                .executionRole(role)
                .build();

  CfnOutput.Builder.create(this, "RuntimeIdOutput").value(runtime.getAgentRuntimeId()).build();

We start with some easy parts: we give the AgentCore runtime a name, description, and define the protocol as MCP. Finally, the deployed runtime ID will be placed as the output variable RuntimeIdOutput. We'll see it in the console after the deployment of this stack is finished.

Let's cover the artifact part. You can automate the steps of building the Docker file, uploading it to the Amazon Elastic Container Registry, and referencing the image URL completely. The AgentRuntimeArtifact class offers different from* methods (fromCode, fromAsset, and so on). I prefer to do those steps separately and only reference the image URI. This is how publishing to ECR works :

# build the application
mvn clean package 

# build the Docker image
sudo docker build --no-cache -t spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server:v1 

# Login to ECR
aws ecr get-login-password --region {region} | sudo docker login --username AWS --password-stdin {account_id}.dkr.ecr.{region}.amazonaws.com  

# Create ECR repository (if it doesn't exist)
aws ecr create-repository --repository-name spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server --image-scanning-configuration scanOnPush=true --region {region}  

# Tag the Docker image
sudo docker tag spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server:v1 {account_id}.dkr.ecr.{region}.amazonaws.com/spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server:v1

# Push the Docker Image to the ECR repository
sudo docker push {account_id}.dkr.ecr.{region}.amazonaws.com/spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server:v1

Please replace AWS {account_id} and {region} with our own values. Also, your version may not be v1 but a different one.

We can also build the Docker image by using Buildpack support built into Spring instead of a Dockerfile. Just use the Maven task spring-boot:build-image.

Let's look at the relevant code parts to assign this code artifact to the AgentCore Runtime:

var ecrImageURI=ConventionalDefaults
.getContextVariableValueWithReplacedAccountId(this, "ecrImageURIForConferenceSearchAndApplicationAppAsMCPServer");          
var agentRuntimeArtifact = AgentRuntimeArtifact.fromImageUri(ecrImageURI);

Runtime.Builder.create(this, "MCPRuntime-123")
  .runtimeName(appName.replace("-", "_")+ "_runtime")
  ...                                
  .agentRuntimeArtifact(agentRuntimeArtifact)
  ...
  .build();

First, we get the value of the variable ecrImageURIForConferenceSearchAndApplicationAppAsMCPServer, which points to the imageURI in the ECR. This is typically done in the cdk.json:

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "ecrImageURIForConferenceSearchAndApplicationAppAsMCPServer": "{AWS_ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com/spring-ai-1.1-conference-search-bedrock-agentcore-runtime-mcp-server:v17",
...
 }
}

Let's ignore all the content variables we defined there for a moment. Please adjust the value so that it matches your imageURI. We use the placeholder {AWS_ACCOUNT_ID} there. The reason for it is that I don't want to expose the AWS account ID publicly. That's why I wrote the following utility method getContextVariableValueWithReplacedAccountId in the ConventionalDefaults class to replace the placeholder with the real value :

static String getContextVariableValueWithReplacedAccountId(Stack stack, String contextVariableName) {
   var awsAccountId=(String)stack.getNode().tryGetContext("awsAccountId");
   if(awsAccountId == null || awsAccountId.trim().isEmpty()) {
      System.out.println("please provide your aws account id as as content to the call, for example: cdk deploy -c awsAccountId=1234567890101");
    }
   var contextVariableValue= getContextVariableValue(stack, contextVariableName);
   return replaceAWSAccountID(contextVariableValue, awsAccountId);
 }

static String getContextVariableValue(Stack stack, String contextVariableName) {
   return (String)stack.getNode().tryGetContext(contextVariableName);
 }

private static String replaceAWSAccountID(String configParam, String awsAccountId) {
   return configParam.replace("{AWS_ACCOUNT_ID}", awsAccountId);
}

The command to deploy this stack later is:

cdk deploy spring-ai-conference-search-agentcore-runtime-with-mcp-server-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}

Don't do it now, as we first need to create inbound authentication.

spring-ai-conference-search-agentcore-runtime-with-mcp-server-stack is the name of our stack, and you need to pass your AWS account ID. Here, I assume you operate everything (AgentCore, IAM Role, ECR) in the same AWS account. Otherwise, you'll need to adjust the code to adapt to your needs.

Now, let's cover the part of defining the authorizer configuration and assigning it to the AgentCore Runtime. This configuration is responsible for creating the inbound authentication type. As we deploy our application on the Runtime publicly, we need to secure the access. For the Runtime MCP protocol, there are inbound authentication types :

IAM permissions - This will use the IAM username that you used to sign-in to the AWS console)
JSON Web Tokens (JWT) - Configure JWT (like an OAuth token) as the Inbound Auth to validate incoming token signatures and scopes.

We'll use JWT issues by Amazon Cognito as an identity provider. For this, we need to define the Discovery URL from Cognito and JWT Authorization Configuration ( "allowed clients IDS"), see the relevant code from the RuntimeWithMCPStack class:

 runtime = Runtime.Builder.create(this, "MCPRuntime-123")
   .runtimeName(appName.replace("-", "_")+ "_runtime")               
 .... 
 .authorizerConfiguration(RuntimeAuthorizerConfiguration
 .usingJWT(UserClientPoolStack.COGNITO_DISCOVERY_URL,  
 List.of(UserClientPoolStack.userPoolClient.getUserPoolClientId()), null))
 ...
 .build();

But how do we get those values? For this, we need to set up an Amazon Cognito user pool, user domain (to use the JWT token), and user client pool. I define all this in the UserClientPoolStack.

I'll leave it up to you to understand this stack in detail, because it requires Cognito knowledge and is not strictly related to the AgentCore. But basic steps are:

Create a user pool with the given ID.
Create a resource server with the scope (I created the full access scope).
Add the resource server to the already created user pool.
Construct the discovery URL, which always has a predefined schema: https://cognito-idp."+{region}+".amazonaws.com/"+{userPoolId}+"/.well-known/openid-configuration".
Create a user client pool with the given name with only the default user flow, client credentials, and the scopes with the resource server we defined for the user pool. Add the already created user pool to the user client pool and generate the secret for it.
Add the domain to the user pool we created to issue the token.

Initially, I thought I could automate this part completely. We don't even need to run the UserClientPoolStack stack individually, as we made the COGNITO_DISCOVERY_URL and the userPoolClient publicly there:

public static String COGNITO_DISCOVERY_URL;
public static UserPoolClient userPoolClient;

We also used them both from the RuntimeWithMCPStack as shown in the example above. With that, CDK understands that the RuntimeWithMCPStack stack depends on the UserClientPoolStack stack and executes the latter automatically first.

What should have worked out of the box is to create the domain prefix from the user pool ID. By definition, the prefix should be the user pool ID with lowercase letters, and the character _ stripped:

userPool.addDomain("UserPoolForAgentCoreMCPDomain", UserPoolDomainOptions.builder()
     .cognitoDomain(CognitoDomainOptions.builder()
     .domainPrefix(userPoolId.replace("_", "").toLowerCase()).build()).build());

Cognito doesn't accept setting other domain prefixes. But unfortunately, I encountered one issue with the creation of the user pool domain, which I described here. The only workaround I currently found was to comment out the user domain creation in the UserClientPoolStack :

/*
userPool.addDomain("UserPoolForAgentCoreMCPDomain", UserPoolDomainOptions.builder()
   .cognitoDomain(CognitoDomainOptions.builder()
   .domainPrefix(cognitoDomainPrefix.replace("_", "")
      .toLowerCase()).build()).build());
*/

Then, execute this stack individually: cdk deploy spring-ai-conference-search-agentcore-user-client-pool-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

Then, grab the value of the output variable CognitoUserPoolIdOutput and configure it in the cdk.json :

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "cognitoDomainPrefix":"us-east-1_JbjQPT5GJ",
      ...
  }
}

Finally, uncomment the user domain creation, which uses the value of this variable to construct the domain name :

 var cognitoDomainPrefix=ConventionalDefaults
  .getContextVariableValue(this, "cognitoDomainPrefix");
 userPool.addDomain("UserPoolForAgentCoreMCPDomain", UserPoolDomainOptions.builder()
   .cognitoDomain(CognitoDomainOptions.builder()
   .domainPrefix(cognitoDomainPrefix.replace("_", "")
   .toLowerCase()).build()).build());

And re-run the command: cdk deploy spring-ai-conference-search-agentcore-user-client-pool-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.
When AWS has fixed the issue with the domain prefixes, we can completely remove this workaround. We also won't need to deploy this stack separately.

Now let's cover the last missing part - defining the IAM execution role.
It's very difficult to automate this part as it takes plenty of time. If I find it, I'll provide the IaC part in the future :). I refer you to the article IAM Permissions for AgentCore Runtime for more information. You can also read my article Amazon Bedrock AgentCore Runtime - Part 2 Using Bedrock AgentCore Runtime Starter Toolkit with Strands Agents SDK, where I explained this part. In that article, we developed the agent in Python with the Strands Agents framework and deployed it on AgentCore Runtime.

Once we have defined the IAM role, we need to configure it in the cdk.json :

{
  "app": "mvn -e -q compile exec:java",
  "context": {
      "roleArnForTheAgentCoreRuntime": "arn:aws:iam::{AWS_ACCOUNT_ID}:role/service-role/AmazonBedrockAgentCoreRuntimeDefaultServiceRole-q8xp1",
    ....
   }
}

   var roleArnForTheAgentCoreRuntime=ConventionalDefaults
  .getContextVariableValueWithReplacedAccountId(this, "roleArnForTheAgentCoreRuntime");

   role=Role.fromRoleArn(this,"roleArnForTheAgentCoreRuntimeRole", roleArnForTheAgentCoreRuntime);

   Runtime.Builder.create(this, "MCPRuntime-123")
     .runtimeName(appName.replace("-", "_")+ "_runtime")
     ...
     .executionRole(role)
     .build();

Now we're completely ready and can deploy the conference-search-agentcore-runtime-with-mcp-server-stack stack with: cdk deploy spring-ai-conference-search-agentcore-runtime-with-mcp-server-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

We'll need some values for the configuration of the (Spring AI) MCP client, which we'll cover in the next article:

user pool name, user client pool name, and auth token resource server ID, which we defined as constants in the UserClientPoolStack. You can also see them in the output of the cdk deploy command.
agentcore runtime ID from the RuntimeWithMCPStack. This value will only be there after the deployment of this stack. You can also see it in the output of the cdk deploy command (variable name RuntimeIdOutput).

Here is how the AgentCore Runtime looks in the console after its creation:

Conclusion

In this article, we explained how to deploy and run our conference search application on the Amazon Bedrock AgentCore Runtime as the MCP server. In the next article, we'll develop the (MCP-) client, capable of talking to our application running on AgentCore 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.

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 1 Introduction to the series

Vadym Kazulkin — Mon, 27 Apr 2026 12:16:00 +0000

Introduction to the series

I've already started the article series Spring AI with Amazon Bedrock, where I've published articles to :

Introduce to Spring AI and the sample application to search for technical conferences.
Explore Spring AI MCP Server with STDIO protocol.
Explore Spring AI MCP Server with SSE protocol.
Explore Spring AI MCP Server with Streamable HTTP protocol.
Explore Amazon Bedrock AgentCore with Spring AI. Here, I used another sample application, which I implemented in Python with the Strands Agents framework and ported the parts of it to Spring AI. I deployed the application on the AgentCore Runtime. The application also used Spring AI MCP Client to talk to the AgentCore Gateway. It acts as the managed MCP server to expose the functionality provided by another application as MCP-compatible tools. This application stores and retrieves orders, which I implemented with API Gateway, Lambda, and Aurora DSQL.

Why did I decide to start a separate article series to cover building AI Agents with Spring AI and Amazon Bedrock AgentCore if the last-mentioned article also covers it? Because there is more to cover and to be released by AWS and Broadcom (the company behind the Spring development). I'll use the conference application example to cover the following topics in this series:

Deploy Spring AI MCP server on AgentCore Runtime with MCP protocol instead of locally, as mentioned in the examples above.
Discuss the use case where it's more beneficial to deploy the MCP server on AgentCore Gateway instead of AgentCore Runtime.
Use Spring AI MCP client to talk to the MCP server deployed on AgentCore Runtime and AgentCore Gateway. This MCP client itself can be deployed either locally or on the AgentCore Runtime.
Explore the functionality of the Spring AI AgentCore. It provides easier integration between Spring AI and the Amazon Bedrock AgentCore services, such as the Runtime, but also short-term, long-term, and episodic AgentCory Memory. In my example to explore Amazon Bedrock AgentCore with Spring AI, I didn't use AgentCore Memory at all, as such integration was an immense effort. With Spring AI AgentCore Memory, this integration becomes much easier.
I'll rewrite the agent using Embabel, which builds upon Spring AI. Embabel is a framework for authoring agentic flows on the JVM that seamlessly mix LLM-prompted interactions with code and domain models. Supports intelligent path finding towards goals.
How to set up so-called collector-less Observability for the Amazon Bedrock AgentCore resources using AWS Distro for OpenTelemetry (ADOT) SDK for Spring AI applications hosted in AgentCore Runtime.
Last but not least, I'll update the examples to use Java 25, Spring Boot 4, and the recent Spring AI version. There is a Spring AI 1.1* branch for Spring Boot versions before Spring Boot 4. And there is the Spring AI 2.x branch for Spring Boot 4 applications. The last one is currently in development and not GA. When it's released, I'll also provide my examples for the Spring AI 2.x version.

You can already preview some of my examples, where I'll cover the above-mentioned topics in my amazon-bedrock-agentcore-spring-ai GitHub repository.

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 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 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 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	1172	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.