DEV Community: Vadym Kazulkin

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 3 Waits and callbacks

Vadym Kazulkin — Mon, 24 Aug 2026 14:30:00 +0000

Introduction

In part 2 of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to create and execute durable steps synchronously and asynchronously. In this part, we'll extend our application by adding and implementing wait and callback operations to it.

Sample application with wait for callback

Let's explore waits and callbacks. We get access to them through DurableContext. Waits are planned pauses where your function stops running and stops charging until it's time to continue. Use them for time periods, external callbacks, or polling for a condition. Callbacks suspend execution until an external system sends a result. Use this for human approvals, webhooks, or any event-driven workflow. In our sample application, we'll combine both and use waitForCallback. It simplifies callback handling by combining callback creation and submission in one operation.

I first copied the application that we created in part 2 into the aws-s3-files-lambda-durable-functions-with-wait-for-callback-java-25 repository. We'll work on it to extend our application. Please go through the content of part 2 to understand the sample application and the basic concepts of Lambda durable functions. We'll completely reuse the Infrastructure as Code part as well.

Let's add another, a bit artificial use case to our sample application. After searching for the author's YouTube videos and upcoming talks, the author should confirm those talks. For this, let's extend our AsyncAuthorContentExtractor Lambda function and add the following invocation:

var upcomingTalkApprovalStatus = this.waitForUpcomingTalksApproval(ctx, author, upcomingTalks);

Next, let's look at the implementation of the waitForUpcomingTalksApproval method in the AbstractAuthorContentExtractor class:

public default UpcomingTalkApprovalStatus waitForUpcomingTalksApproval(DurableContext ctx, Author author, UpcomingTalks upcomingTalks) {
    var waitCallbackConfig= WaitForCallbackConfig.builder()
           .callbackConfig(CallbackConfig.builder()
           .timeout(Duration.ofHours(1))
           .build())
       .build();

   return ctx.waitForCallback(
            "wait-for-approval",
             UpcomingTalkApprovalStatus.class,
             (callbackId, stepCtx) 
              -> this.sendApprovalRequest(callbackId, author, upcomingTalks),
             waitCallbackConfig);
}

private void sendApprovalRequest(String callbackId, Author author, UpcomingTalks upcomingTalks) {
       LOGGER.info("get approval for the talk of  "+ author+ " for the talks "+upcomingTalks + 
       " with the callback id "+callbackId);
}

Let's explain step by step what is happening here. We use DurableContext to create the waitForCallback operation. We give it a name and the return type. This return type corresponds to the type of the object that will be passed in the callback. We also provide the submitter function sendApprovalRequest, receiving the callback ID and a StepContext. In this function, we can perform the desired operation, like sending the talk approval request to the author. We won't implement this functionality but only log the callback ID, which we'll require later to send the callback. We can optionally pass the WaitForCallbackConfig. In our case, we only set the CallbackConfig with a timeout of 1 hour. This means that if no callback arrives within this period of time, the Lambda durable function will fail. We can also set the StepConfig. Please review part 2 for more information.

When we invoke the waitForCallback method, the invocation will block until the callback arrives. After its arrival, the payload of the callback is deserialized into the object of type UpcomingTalkApprovalStatus, and this object will be returned.

Now we can build and package our application with mvn clean package and deploy it with sam deploy. The deployment process can take up to 10 minutes because of the creation and mounting of S3 Files.

To test our Lambda durable function, we can navigate to the Lambda service, search for the AsyncAuthorContentExtractor function, and go to the "Test" tab.

We need to pass the following sample JSON Event to it, which represents the author:

{
  "firstName": "Vadym",
  "lastName": "Kazulkin",
  "email": "bla@bla.de"
}

Then we can test it. After that, we go to the "Durable execution" tab and can see all the execution details:

What we see here is that the first 2 steps (searching for YouTube videos and upcoming talks) have already been executed asynchronously. Now, our Lambda function is in the "wait for the approval" state. The invocation of the Lambda durable function is now completed. Why? Because waits suspend our function without incurring charges.

Now let's send the reply (callback) to our Lambda durable function. We first need to grab the callback ID from the log. There are several ways to send the callback (success or failure). We can use the Lambda CLI send-durable-execution-callback-success or execution-callback-failure commands. Alternatively, we can use the AWS SDK to do the same. Let's use the AWS Java SDK for it. First, we need to add the following dependency to pom.xml:

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>lambda</artifactId>
</dependency>

We implemented the functionality to send the callback in the SendDurableExecutionCallback class:

public class SendDurableExecutionCallback {

  private final static String CALLBACK_ID=
"Ab9hZXiWYXJuOmF3czpsYW1iZGE6dXMtZWFzdC0xOjI2NTYzNDI1NzYxMDpmdW5jdGlvbjpBdXRob3JDb250ZW50RXh0cmFjdG9yOiRMQVRFU1QvZHVyYWJsZS1leGVjdXRpb24vc2VhcmNoRm9yVmFkeW0xMzUvMmM2NzRiOWEtNTQ0OC0zZDVjLWI3MzUtNTQ1NWM5ODA5MWUwYWl4JDA2N2JkNmRkLTViN2MtNGZmYi05NmY4LTRkM2Y1Yjk3MWE0Zf8";

  private final static LambdaClient LAMBDA_CLIENT = 
  LambdaClient.builder().region(Region.US_EAST_1).build();

  private final static ObjectMapper MAPPER= new ObjectMapper();

  public static void main(String[] args) {

    var approvedStatus= MAPPER.writeValueAsString(
         new UpcomingTalkApprovalStatus(UpcomingTalks.getDefaultUpcomingTalks(), "approved"));

    var response= LAMBDA_CLIENT.sendDurableExecutionCallbackSuccess(
                  builder -> builder.callbackId(CALLBACK_ID)
                  .result(SdkBytes.fromUtf8String(approvedStatus))
                  .build());
    }
}

First, we need to configure the callback ID (please replace it with your individual one). Then, we create the Lambda client. Next, we invoke its sendDurableExecutionCallbackSuccess method to send the successful callback. We pass the callback ID and payload as JSON. This payload should be deserializable into the object of type UpcomingTalkApprovalStatus (see above). Similarly, we can send the failure callback by using the sendDurableExecutionCallbackFailure operation. Please move this logic with all required dependencies to the service that sends the callbacks. Now let's send the callback (approximately 23 minutes later) and see what happens:

We observe that the callback was successfully received and processed. After it, the last writeAuthorContentToFile-step step was executed as well. But we also observe that execution of our Lambda durable function started from the beginning. What happened here exactly? After our function resumes from a pause or interruption, the system performs replay. During replay, our code runs from the beginning but skips over completed checkpoints, using stored results instead of re-executing completed operations. This replay mechanism ensures consistency while enabling long-running executions.

Here is the picture, which describes the concept that I took from this source:

There are also other individual operations that AWS Lambda Durable Execution SDK for Java supports:

wait - wait suspends the function and resumes after the specified duration. There is no charge during suspension.
waitAsync - starts the wait timer but returns a DurableFuture immediately, allowing other operations to run concurrently. The execution only suspends when you call .get() on the future (if the wait hasn't completed yet).
createCallback - callbacks suspend execution until an external system sends a result. Use this for human approvals, webhooks, or any event-driven workflow.

Conclusion

In this part of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to implement wait and callback.

In the next part, we'll explore the "wait for condition" operation to poll a condition until it's met. Still, our Lambda durable function itself contains too much business logic. Ideally, it should simply be the orchestrator and contain as little business logic as possible. That's why, in the subsequent parts, we'll move the logic for each step into a separate Lambda function. With that, we'll explore how to invoke another Lambda function within the durable step. We'll also show how to invoke multiple Lambda functions in parallel.

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.

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 2 Durable synchronous and asynchronous steps

Vadym Kazulkin — Mon, 17 Aug 2026 13:00:00 +0000

Introduction

In part 1, we introduced what we'll cover in this series and our sample application. We also gave a short introduction to the services that we'll use throughout this series: AWS Lambda durable functions and Amazon S3 Files. In this part of the series, we'll explore how to use the AWS Lambda Durable Execution SDK for Java to create and execute durable steps synchronously and asynchronously.

First implementation attempt of our sample application

Throughout this article series, we'll develop a simple application to show how to build multi-step applications and orchestrate workflows using AWS Lambda durable functions. This simple application provides the functionality to extract the content for the provided user. To this content belongs searching for YouTube videos of the authors and their upcoming talks. We'll store the result on Amazon S3 Files in JSON format. As this operation may potentially take time, we'll additionally provide access to the author content through the Amazon API Gateway:

We'll start with the search for YouTube videos and upcoming talks of the author synchronously. For the sake of simplicity, we won't implement any persistent layer and store the static content in memory. We'll store the result on Amazon S3 Files in JSON format.

You can find the code examples in my aws-s3-files-lambda-durable-functions-java-sdk repository. We'll go through all the examples in more detail in the subsequent articles.

First of all, let's declare some important dependencies in pom.xml. The most important one is the AWS Lambda Durable Execution SDK for Java:

<dependency>
    <groupId>software.amazon.lambda.durable</groupId>
    <artifactId>aws-durable-execution-sdk-java</artifactId>
    <version>2.0.0</version>
</dependency>

Why do we need such an SDK? Under the hood, durable functions are regular Lambda functions using a checkpoint/replay mechanism to track progress and support long-running operations through user-defined suspension points, commonly referred to as durable execution. After your function resumes from a pause or interruption, the system performs replay. During replay, your code runs from the beginning but skips over completed checkpoints, using stored results instead of re-executing completed operations. This replay mechanism ensures consistency while enabling long-running executions.

To harness this checkpoint-and-replay mechanism in your applications, Lambda provides a durable execution SDK. The SDK abstracts away the complexity of managing checkpoints and replay, exposing simple primitives called durable operations that you use in your code. The SDK integrates seamlessly with your existing Lambda development workflow.

To provide the implementation of our Lambda durable function, we need the class to extend DurableHandler and implement only the method handleRequest. Let's do it for our AuthorContentExtractor Lambda durable function:

public class AuthorContentExtractor extends DurableHandler<Author, AuthorContent> implements AbstractAuthorContentExtractor {

@Override
public AuthorContent handleRequest(Author author, DurableContext ctx) {
   var config = this.getStepConfig();       
   var upcomingTalks= ctx.step("searchForUpcomingTalks-step", UpcomingTalks.class, stepCtx -> this.searchForUpcomingTalks(), config);
   var youtubeVideos= ctx.step("searchForYouTubeVideos-step", YouTubeVideos.class, stepCtx -> this.searchForYouTubeVideos(), config);

   var authorContent = new AuthorContent(author, upcomingTalks, youtubeVideos);

   ctx.step("writeAuthorContentToFile-step", Void.class, stepCtx -> this.writeAuthorContentToFile(authorContent), config);      

    return authorContent;
   }
}

Let's go step by step through what's happening here. First of all, we also implement the AbstractAuthorContentExtractor interface. We place some common methods there that we'll use when improving our application.

Now let's introduce the concept of durable steps. Steps run business logic with built-in retries and automatic checkpointing. Each step saves its result, so your function resumes from the last completed step after an interruption. With the SDK, you wrap your Lambda event handler, which then provides a DurableContext alongside your event. This context gives you access to durable operations like steps. You write your function logic as normal sequential code, but instead of calling services directly, you wrap those calls in steps for automatic checkpointing and retries. When you need to pause execution, you add waits that suspend your function without incurring charges. We'll show it in the next part of the series. The SDK handles all the complexity of state management and replay behind the scenes, so your code remains clean and readable.

Here is the picture, which describes the concept that I took from this source:

We wrapped several operations into separate durable steps:

searchForUpcomingTalks-step
searchForYouTubeVideos-step
writeAuthorContentToFile-step

Let's look into the searchForUpcomingTalks-step first:

var upcomingTalks= ctx.step("searchForUpcomingTalks-step", UpcomingTalks.class, 
stepCtx -> this.searchForUpcomingTalks(), config);

To create a step, we need to give it a name and the result type. We also have to give it the function to execute, receiving a StepContext. The return type of the function should be the same as the result type. In our case, we execute the searchForUpcomingTalks function, which returns the static list of the upcoming talks. Optionally, we can also pass the StepConfig. In our case, we create it like this:

var stepConfig = StepConfig.builder()
    .semanticsPerRetry(StepSemantics.AT_LEAST_ONCE_PER_RETRY)                 
    .retryStrategy(RetryStrategies.exponentialBackoff(                                
      3, // max attempts
      Duration.ofSeconds(2),   // initial delay  
      Duration.ofSeconds(30),   // max delay
      2.0,                      // backoff multiplier
      JitterStrategy.FULL))
   .build();

We create the StepConfig by passing the following:

retry strategy: fixed delay, linear backoff, or exponential backoff. We pass the latter here.
semantics per retry: at-least-once delivery (default, which we also pass). The step may be re-executed if interrupted. START checkpoint is fire-and-forget. At-most-once delivery per retry attempt. START checkpoint is awaited before user code runs.
custom serializer for the step with serDes method. We don't provide it here, as we're happy with the default one.

searchForYouTubeVideos-step step works the same. After we have collected the result of the search for the upcoming talks and YouTube videos, we use the writeAuthorContentToFile-step step to serialize the result to JSON and write it to the file:

public default Void writeAuthorContentToFile(AuthorContent authorContent) {
  var authorContentAsJson = OBJECT_MAPPER.writeValueAsString(authorContent);
  var fileName= authorContent.author().firstName()+"-"+authorContent.author().lastName()+".json";
  Path path = Paths.get(WORKSPACE_MOUNT, fileName);
  byte[] strToBytes = authorContentAsJson.getBytes();
  Files.write(path, strToBytes);
  return null;
}

We use the standard Java Path API to do it. This is because we use Amazon S3 Files, and it supports POSIX. Strictly speaking, we could also use S3 here, but I wanted to show the functionality of S3 Files.

The directory where we store the file is passed as an environment variable WORKSPACE_MOUNT. In our case, it is /mnt/workspace. See the Infrastructure as Code explanation below, especially the LocalMountPath setting of the file system configuration for the Lambda function.

For infrastructure as code (IaC), I use AWS SAM, and you can find it here. To indicate that our Lambda function is durable, we need to provide some additional durable config properties:

  AuthorContentExtractorFunction:
    Type: AWS::Serverless::Function
    ...
    Properties:
      FunctionName: AuthorContentExtractor
      Handler: dev.vkazulkin.handler.AuthorContentExtractor::handleRequest
      DurableConfig:
        ExecutionTimeout: 3600
        RetentionPeriodInDays: 7
        ...

Execution timeout. The execution timeout controls how long a durable execution can run from start to completion. This is different from the Lambda function timeout, which controls how long a single function invocation can run. A durable execution can span multiple Lambda function invocations as it progresses through checkpoints, waits, and replays. The execution timeout applies to the total elapsed time of the durable execution, not to individual function invocations. Set the Execution timeout value in seconds (default: 86400 seconds / 24 hours, minimum: 60 seconds, maximum: 31536000 seconds / 1 year).
Retention period. The retention period controls how long Lambda retains execution history and checkpoint data after a durable execution completes. This data includes step results, execution state, and the complete checkpoint log. After the retention period expires, Lambda deletes the execution history and checkpoint data. You can no longer retrieve execution details or replay the execution. Set the Retention period value in days (default: 14 days, minimum: 1 day, maximum: 90 days).

For a very detailed explanation of how to create S3 Files and mount them to the Lambda function, please read the brilliant article Lambda Just Got a File System. I Put AI Agents on It by Eric Johnson. I mostly copied the IaC part from it and adjusted it to my needs. I only describe the main steps here:

First, we reference the networking stack, which we place in a separate file. Then we create:

VPC networking for Lambda functions using S3 Files.
VPC with private subnets (for Lambda + mount targets).
Security groups for NFS traffic.
Public subnet with a NAT gateway. We'll need them for internet access to Bedrock and Bedrock AgentCore Web Search Tool. In later parts, we'll use both services.

  NetworkingStack:
    Type: AWS::Serverless::Application
    Properties:
      Location: src/main/resources/stacks/network.yaml

Next, we need to create an S3 Bucket:

 WorkspaceBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName : vadym-s3-files-workspace
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true
      VersioningConfiguration:
        Status: Enabled

Please don't forget to rename the S3 Bucket. After that, we need to create S3 Files:

  S3FileSystem:
    Type: AWS::S3Files::FileSystem
    Properties:
      Bucket: !GetAtt WorkspaceBucket.Arn
      RoleArn: !GetAtt S3FilesRole.Arn
      AcceptBucketWarning: true

Here we reference an already created S3 Bucket. We also need to profile the appropriate IAM Role (see the SAM template for the IaC). Next, we need to create 2 different mount targets for the S3 File. They should use private subnets in different availability zones. Here is an example of one such mount target:

  MountTargetA:
    Type: AWS::S3Files::MountTarget
    Properties:
      FileSystemId: !GetAtt S3FileSystem.FileSystemId
      SubnetId: !GetAtt NetworkingStack.Outputs.PrivateSubnetAId
      SecurityGroups:
        - !GetAtt NetworkingStack.Outputs.MountTargetSGId

Next, we need to create an S3 Files access point:

  S3FilesAccessPoint:
    Type: AWS::S3Files::AccessPoint
    Properties:
      FileSystemId: !GetAtt S3FileSystem.FileSystemId
      PosixUser:
        Uid: '1000'
        Gid: '1000'
      RootDirectory:
        Path: /lambda
        CreationPermissions:
          OwnerUid: '1000'
          OwnerGid: '1000'
          Permissions: '755'

The CreationPermissions property is crucial. It auto-creates the /lambda directory within our S3 bucket with the right ownership when a client first connects. Without it, the root directory is owned by root (UID 0), and Lambda (running as UID 1000 through the access point) can’t create subdirectories.

Lastly, we need to provide configuration and give permissions to our Lambda function to use S3 Files:

  AuthorContentExtractorFunction:
    Type: AWS::Serverless::Function
    DependsOn:
      - MountTargetA
      - MountTargetB
    Properties:
      FunctionName: AuthorContentExtractor
      Handler: dev.vkazulkin.handler.AuthorContentExtractor::handleRequest
      DurableConfig:
        ExecutionTimeout: 3600
        RetentionPeriodInDays: 7
      VpcConfig:
        SecurityGroupIds:
          - !GetAtt NetworkingStack.Outputs.LambdaSGId
        SubnetIds:
          - !GetAtt NetworkingStack.Outputs.PrivateSubnetAId
          - !GetAtt NetworkingStack.Outputs.PrivateSubnetBId
      FileSystemConfigs:
        - Arn: !GetAtt S3FilesAccessPoint.AccessPointArn
          LocalMountPath: /mnt/workspace
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Sid: MountS3Files
              Effect: Allow
              Action:
                - s3files:ClientMount
                - s3files:ClientWrite
                - s3files:ClientRootAccess
              Resource: !GetAtt S3FileSystem.FileSystemArn

Here we provide the VPC and file system configuration (including local mount path) and the policy for our Lambda function to use the S3 Files.

To test our Lambda durable function, we can navigate to the Lambda service, search for the AuthorContentExtractor function, and go to the "Test" tab:

We need to pass the following sample JSON Event to it, which represents the author:

{
  "firstName": "Vadym",
  "lastName": "Kazulkin"
}

Then we can test it. After that, we go to the "Durable execution" tab and can see all the execution details:

Input and output as JSON
Logger output
Details like durable operations (with individual inputs and outputs of each step) and event history. If something goes wrong, the step status will be set to failed.

In our case, we invoked the durable function directly from the Lambda console. As an alternative, we can also use the Lambda SDK for it. We can also put an API Gateway in front of it if you wish and even invoke the Lambda function asynchronously.

We can also see the JSON file with author content in the S3 Bucket that we created. Alternatively, I implemented a GetAuthorContentResult Lambda function with the name GetAuthorContentResult. This Lambda function takes the author's first and last name and streams the content of the JSON file from the S3 bucket. This JSON file is stored in the subdirectory /lambda of our created S3 bucket. I also created and put an API Gateway in front of this Lambda function. Please use the /result/{firstname}/{lastname} HTTP GET endpoint for it, for example /result/Vadym/Kazulkin. Be aware that it takes several minutes for the file to appear in the S3 Bucket after being written to S3 Files. If you need the result immediately, you can rewrite this Lambda to retrieve the result from S3 Files instead.

This was a very simple application to explore the durable steps with the AWS Lambda Durable Execution SDK for Java. Let's improve our application a bit. Until now, we searched for the upcoming talks and YouTube videos sequentially. But we can do it in parallel. For that, we can use the stepAsync operation instead of step. I provided a separate implementation, AsyncAuthorContentExtractor, and the Lambda durable function with the name AsyncAuthorContentExtractor for it:

var upcomingTalksFuture= ctx.stepAsync("searchForUpcomingTalks-async-step", UpcomingTalks.class, 
stepCtx -> this.searchForUpcomingTalks(), config);
var youtubeVideosFuture= ctx.stepAsync("searchForYouTubeVideos-async-step", YouTubeVideos.class, 
stepCtx -> this.searchForYouTubeVideos(), config);

var upcomingTalks=upcomingTalksFuture.get();
var youtubeVideos= youtubeVideosFuture.get();

Now, stepAsync invocation returns a DurableFuture of the result type - a future representing the step result. This operation is non-blocking; we only block when invoking the get method on the result. Everything else remains the same in this asynchronous implementation as it was in the synchronous one.

Conclusion

In this part of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to create and execute durable steps synchronously and asynchronously. In the next part, we'll extend our application by adding and implementing wait and callback operations to it. Still, our Lambda durable function itself contains too much business logic. Ideally, it should simply be the orchestrator and contain as little business logic as possible. That's why in the later parts, we'll move the logic associated with each step into a separate Lambda function. We'll explore how to invoke another Lambda function within the durable step. We'll also show how to invoke multiple Lambda functions in parallel.

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.

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 1 Introduction to the series and services

Vadym Kazulkin — Mon, 10 Aug 2026 13:00:00 +0000

Introduction to the series

Throughout this article series, we'll develop a simple application to show how to build multi-step applications and orchestrate workflows using AWS Lambda durable functions. For it, we'll explore the AWS Lambda Durable Execution SDK for Java. This simple application provides the functionality to extract the content for the provided user. This content involves searching for YouTube videos of the authors and their upcoming talks. We'll store the result on Amazon S3 Files in JSON format. As this operation may potentially take time, we'll additionally provide access to the author content through the Amazon API Gateway:

We'll start with the simple application to search for YouTube videos and upcoming talks of the author synchronously. First, we'll use durable steps and then later add waits and callbacks. We won't implement any persistent layer and store the static content in memory.
We'll then improve our application by adding asynchronous communication where it makes sense. For example, searching for YouTube videos and upcoming talks can be done in parallel.
We'll then further improve our application by converting the AWS durable function to a pure orchestrator. This means we'll move the business logic for searching for YouTube videos and upcoming talks into separate Lambda functions. With that, our Lambda durable function will invoke those separate Lambda functions in parallel and combine the results
Finally, we'll further extend our application to use Amazon Bedrock AgentCore Web Search Tool to search for the author content on the web. With that, our Lambda durable function becomes an orchestrator of the agentic AI workflows. As we'll use Java in this series, we'll explore how to run this business logic responsible for the Amazon Bedrock AgentCore Web Search Tool. As this tool is exposed as an MCP tool by the Amazon Bedrock AgentCore Gateway, we need a framework capable of providing AI functionality and supporting MCP. That's why we'll use Spring AI. As 2 operational environments for our agentic AI workflows, we'll explore an AWS Lambda function and Amazon Bedrock AgentCore Runtime.

You can find the code examples in my aws-s3-files-lambda-durable-functions-java-sdk repository. We'll go through all the examples in more detail in the subsequent articles.

Introduction to the services used throughout the series

Throughout this series, we'll use the following AWS services:

AWS Lambda durable functions. With Lambda durable functions, you can build resilient multi-step applications and AI workflows. These can execute for up to one year while maintaining reliable progress despite interruptions. When a durable function runs, this complete lifecycle is called a durable execution, which uses checkpoints to track progress and automatically recover from failures through replay, re-executing from the beginning while skipping completed work. Within each function, you use durable operations as fundamental building blocks. Steps execute business logic with built-in retries and progress tracking. Waits suspend execution without incurring compute charges, making them ideal for long-running processes. These processes include human-in-the-loop workflows or polling external dependencies.
Amazon S3 Files. S3 Files is a shared file system that connects any AWS compute resource directly with your data in Amazon S3. It provides fast, direct access to all of your S3 data as files with full file system semantics and low-latency performance, without your data ever leaving S3. Every file-based application, agent, and team can access and work with your S3 data as a file system using the tools they already depend on. Built using Amazon EFS, S3 Files gives you the performance and simplicity of a file system with the scalability, durability, and cost-effectiveness of S3. You can read, write, and organize data using file and directory operations. At the same time, S3 Files manages the synchronization of changes between your bucket and file system.
We'll also introduce in the later parts of this series the following Amazon Bedrock AgentCore services or features: Gateway, Web Search Tool, and Runtime.

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

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

Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore - Part 3 Develop Agents as web application with Embabel

Vadym Kazulkin — Mon, 03 Aug 2026 13:00:00 +0000

Introduction

In part 2, we developed our first AI agents with the Embabel shell. We learned many concepts of this framework, such as agents, actions, and goals. In this article, we'll slightly adjust our application to convert it into a web application.

Implement AI agents as a web application with Embabel

You can look at my GitHub embabel-1.x-conference-app-agent-local repository for the example. We'll completely reuse the implementation of both agents, the CreateTalksAndApplyForConferencesAgent and the SearchForTalksAndApplyForConferencesAgent that we implemented in part 2.

Those agents are capable of responding to the following prompts:

"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." SearchForTalksAndApplyForConferencesAgent is responsible for responding to this 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." CreateTalksAndApplyForConferencesAgent is responsible for responding to this prompt.

First, let's check that we declared the following dependencies in pom.xml:

 <dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter-bedrock</artifactId>
    <version>${embabel-agent.version}</version>
 </dependency>
 <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

Also, make sure not to declare the embabel-agent-starter-shell dependency, as we don't use Embabel shell in this article.

All we need to do now is to additionally implement the EmbabelAgentController controller.

Let's first implement a generic endpoint that will accept both prompts. Let's first autowire and create some objects coming from Embabel that we'll use for this:

@RestController
public class EmbabelAgentController {

private final AgentPlatform agentPlatform;
private final AgentInvocation<Domain.ConferenceApplications> invocation;

private final ProcessOptions processOptions = new ProcessOptions()
     .withVerbosity(new Verbosity()
     .withShowPrompts(true)
     .withShowLlmResponses(true)
     .withShowPlanning(true)
     .withDebug(true));


public EmbabelAgentController(AgentPlatform agentPlatform) {
      this.agentPlatform = agentPlatform;

      this.invocation = AgentInvocation
            .builder(agentPlatform)
        .options(processOptions)
        .build(Domain.ConferenceApplications.class);
  }
...

}

First, we autowire the Embabel's AgentPlatform object and use it to create the AgentInvocation object. We additionally pass the ProcessOption object that is configured to show planning, LLM responses, and prompts. We also pass the type of the response - the domain object returned after the agents achieve their goals; in our case, the Domain.ConferenceApplications class:

Now, let's implement the endpoint itself:

@GetMapping(value = "/generic", consumes = "text/plain")
public Domain.ConferenceApplications genericPrompt(@RequestParam String prompt) {
    var inputs = Map.of("request", new UserInput(prompt)); 
    return this.invocation.run(inputs)
         .last(Domain.ConferenceApplications.class);    
}

Here we wrap the prompt into Embabel's UserInput object that we put into the map with all inputs required to run the agent. Then we use the AgentInvocation object to run the agent with the specified input synchronously. We can also invoke runAsync to run the agent asynchronously. Finally, we retrieve the result of the agent invocation with the specified type.

Let's build the application with mvn clean package and run it locally with mvn spring-boot:run. We'll send the prompt number 1 to this endpoint. What we'll see is that Embabel picked the wrong agent, CreateTalksAndApplyForConferencesAgent, to run. Why? As we don't use the Embabel shell, Embabel doesn't analyze the prompt and compute the score to determine what exact agent to run. It currently only looks into the return type of all agents and picks the first one that matches the type defined in the AgentInvocation object. But both our agents have the same return type Domain.ConferenceApplications. Their goals, in the end, are the same: to apply for the conferences. With that, for our 2 agents, there is a 50% probability that Embabel will pick the wrong agent to run.

How can we fix that? For example, we can define the endpoint per agent. Let's do this:

@GetMapping(value = "/applyToConferencesWithExistingTalks", consumes = "text/plain")
public Domain.ConferenceApplications applyToConferencesWithExistingTalks(@RequestParam String prompt) {
    return this.invokeAgent(prompt,
       SearchForTalksAndApplyForConferencesAgent.AGENT_NAME);   
}

@GetMapping(value = "/applyToConferencesWithNewTalks", consumes = "text/plain")
public Domain.ConferenceApplications applyToConferencesWithNewTalks(@RequestParam String prompt) {
    return this.invokeAgent(prompt,
        CreateTalksAndApplyForConferencesAgent.AGENT_NAME); 
}

I additionally wrote 2 helper methods, invokeAgent and getAgentByName, to simplify the agent search by name and its subsequent invocation:

private Domain.ConferenceApplications invokeAgent(String prompt, String agentName) {        
     var inputs = Map.of("request", new UserInput(prompt));
     var agent = this.getAgentByName(agentName);
     var agentProcess = this.agentPlatform.createAgentProcess(agent,
 processOptions, inputs);
     return agentProcess.run().last(Domain.ConferenceApplications.class);
}

private Agent getAgentByName(String agentName) {
     var optionalAgent = this.agentPlatform.agents()
        .stream()
        .filter(a -> a.getName().equals(agentName))
        .findFirst();

     if( optionalAgent.isEmpty()) {
       throw new RuntimeException("agent with the name "+agentName+ " not found");
     }

    return optionalAgent.get();
}

Let's explain what happens in the invokeAgent method. We first invoke the getAgentByName method. It searches in the collection of agents that the agent platform knows for one that has a specified name. All classes annotated with Embabel's Agent annotation will be registered in the agent platform. Then we use the AgentPlatform object to create the AgentProcess and pass the found agent, the already described process options, and inputs to it. Then we run the AgentProcess and return its last output of type Domain.ConferenceApplications.class.

Now we send prompt number 1 (see above) to the applyToConferencesWithExistingTalks endpoint and prompt number 2 to the applyToConferencesWithNewTalks endpoint. We'll see something similar as a result, as we saw in part 2.

For example, here I use httpie to send prompt number 1:
http GET http://localhost:8080/applyToConferencesWithExistingTalks?prompt="Please provide me with the list of conferences including their IDs with Java topic happening in 2026 and 2027 with 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 response of the agent:

Having one endpoint per Embabel agent has its pros and cons. The biggest disadvantage is that a service like AgentCore Runtime exposes only one HTTP POST /invocations endpoint to send the prompt to the web application. This means that we'll need to think about how to design, implement, and deploy each Embabel agent on a separate AgentCore Runtime. Each agent belonging to the same web application will have a lot of shared logic with other agents. This is not very convenient. The biggest advantage is that you can scale each Embabel agent individually. AgentCore Runtime will do it for you.

It's worth checking for the upcoming version of Embabel whether there are other options available to invoke the agent.

Conclusion

In this article, we covered how to develop a web application with Embabel.

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 Embabel, Spring AI and Amazon Bedrock AgentCore - Part 2 Develop Agents with Embabel shell

Vadym Kazulkin — Mon, 27 Jul 2026 15:35:30 +0000

Introduction

In part 1, we addressed some challenges when developing AI agents with Spring AI frameworks only. We start exploring how Embabel is capable of addressing and solving those challenges. Throughout this series, we'll start improving the agent developed in the Provide MCP tools for Conference application via AgentCore Gateway article using the Embabel framework. First, we'll use the Embabel shell, then the web application. You can look at my GitHub embabel-1.x-conference-app-agent-local repository for the example. I updated them to use the recently released Embabel version 1.0.0.

Implement AI agents with Embabel shell

In this article, we'll implement 2 AI agents capable of responding to the following prompts:

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

As our sample application also supports only searching for the conference as an attendee, not as a speaker, you can similarly implement those agents.

Before we start, we need to understand the following key concepts of the Embabel framework:

Actions: Steps an agent takes
Goals: What an agent is trying to achieve
Conditions: Conditions to assess before executing an action or determining that a goal has been achieved. Conditions are reassessed after each action is executed.
Domain model: Objects underpinning the flow and informing Actions, Goals and Conditions.
Plan: A sequence of actions to achieve a goal. Plans are dynamically formulated by the system, not the programmer. The system replans after the completion of each action, allowing it to adapt to new information as well as observe the effects of the previous action. This is effectively an OODA loop.

Now let's first define the actions for our agent - steps an agent takes.
We can split our first agent into the following actions:

Request: "Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today". LLM responds to it.
Request: "Provide me with the list of my talks with this topic in the title". LLM responds to it.
Request: "For each conference and talk retrieved, apply individually for the conference". This request means that the LLM uses its responses from the first 2 requests as the request and responds to it.

And we can split our second agent into the following actions:

Request: "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". LLM responds to it.
Request: "Provide me with the list of my talks with this topic in the title". LLM responds to it.
Request: "For each conference and talk, apply individually for the conference". This request means that the LLM uses its responses from the first 2 requests as the request and responds to it.

In this particular case, steps 2 and 3 are mainly the same for our 2 agents. The difference lies in step 1, where we either retrieve an existing talk(s) or create a new one. Your case might be different, so the design of the agents and their actions might also be different.

First, let's declare some important dependencies in pom.xml to use the Embabel framework (I use version 1.0.0) and its shell:

 <dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter-bedrock</artifactId>
    <version>${embabel-agent.version}</version>
 </dependency>
 <dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter-shell</artifactId>
    <version>${embabel-agent.version}</version>
 </dependency>

Also, make sure not to declare the spring-boot-starter-web dependency, as we'll implement a web application in the next article.

The EmbabelConferenceApplication is the main entry point of our application. Here we also load Amazon Bedrock models, which we declared in the additional-bedrock.yaml:

@Configuration
class AdditionalBedrockModels {
@Bean
   BedrockModelLoader bedrockModels() {
   return new BedrockModelLoader(new DefaultResourceLoader(), "classpath:models/additional-bedrock.yaml");
   }
}

In the Domain class, we declared a domain object (Java record) for each request and response, which corresponds to the agent actions described above. For example, for the action to search for the talks, those domain objects look like this:

// Request to LLM to create the talk
public record ConferenceSearchRequest(String topic, LocalDate startDate, 
  LocalDate endDate, LocalDate callForPapersOpenOnThistDate) 
}


// Response from LLM for the talk creation request
public record Conference (Integer conferenceId, String name, Set<String> topics, String homepage, LocalDate startDate, LocalDate endDate, LocalDate callForPapersStartDate, LocalDate callForPapersEndDate,  String city, String linkToCallforPapers) {
}

Now let's design those 2 agents. We defined the common actions for both of them in the AbstractConferenceAgent class. We defined individual agent-specific actions in the CreateTalksAndApplyForConferencesAgent and SearchForTalksAndApplyForConferencesAgent classes, respectively.

Let's explain the talk search agent action from the SearchForTalksAndApplyForConferencesAgent class in more detail. First of all, we annotate each agent with Embabel's Agent annotation, for example:

@Agent(name=SearchForTalksAndApplyForConferencesAgent.AGENT_NAME , description = "search for the talk(s), search for the conference(s) by the given criteria (all, by the topic, by the date range, and by call for papers being open on some date), and apply for them with the found talks")
public final class SearchForTalksAndApplyForConferencesAgent extends AbstractConferenceAgent {
 ....
}

Here we give the agent a name and description.

The first question is how we can break down a big unstructured prompt into the 3 actions that we described above? Let's start with the action to search for the talk first. The answer is: we can ask LLMs to do this job. Even cheap models are already capable of doing this. Here is how this looks for the action: "Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today"

@Action
Domain.TalkSearchRequest extractTalkSearchRequest(UserInput userInput, OperationContext context) {
return  context.ai()
   .withLlm(LlmOptions.withModel("us.amazon.nova-pro-v1:0"))
     .createObject("""
Create a talk search request from this user input, extracting the optional parameters like talk title substring, conference start and end date, and whether the call for papers is still open on a certain date. 
Don't include any other information in the request.
Here is the user input:
     %s""".formatted(userInput.getContent()), Domain.TalkSearchRequest.class);
}

Let's explain step by step what's happening here. The extractTalkSearchRequest method is an action, which the Agent executes. That's why we annotated it with the Embabel Action annotation. This method also takes 2 parameters, both coming from the Embabel framework:

UserInput object, which represents the unstructured user prompt
OperationContext, which gives us access to the AI functionality

We first invoke the ai() method of the context object and then provide the LLM to do the job. We can either pass the concrete model AI or use other options that are available, like using the default LLM, LLM by role, and others. As a result, we get back the Embabel implementation of the PromptRunnerOperations. Or, we can declare such LLMs in the application.properties, for example :

embabel.models.default-llm=us.anthropic.claude-sonnet-4-6
embabel.models.llms.best=us.anthropic.claude-sonnet-4-6
embabel.models.llms.balanced=us.amazon.nova-pro-v1:0

By invoking the createObject() method on the PromptRunnerOperations implementation, we pass the user prompt and instruction to the LLM on how to split this prompt into one subtask or action. It should only contain the information about the talk search criteria. Additionally, we pass the domain object, in this case, the object of type Domain.TalkSearchRequest. Embabel will make the best effort to map the LLM response to this domain object, which additionally provides us with type safety.

The next step is to implement the talk search itself. For this, we define another action in the SearchForTalksAndApplyForConferencesAgent class:

@Action
Domain.Talks talkSearch(Domain.TalkSearchRequest talkSearchRequest, Ai ai) {        
return config.speaker()     
    .promptRunner(ai)            
    .withPromptContributors(List.of(talkSearchRequest))
    .withToolGroup(this.getMcpToolGroupByName("get-talks-by-"))
    .createObject("Search for the talks with the given criteria", Domain.Talks.class);
}

Please note that the object of the Domain.TalkSearchRequest type, which is the output of the previous action, is now the input of this action. Also, we inject the Ai object coming from the Embabel framework this time directly. Let's first ignore the config.speaker invocation, which we'll explain later. Here we pass the prompt, which contains the properties required to search for the talk. When with createObject() method invocation, we once again pass the prompt and the domain object, which should match the outcome, in this case, the object of type Domain.Talks.

To respond to this prompt, the agent needs tools. Please review the articles Develop local MCP client for Conference application and Provide MCP tools for Conference application via AgentCore Gateway to understand the whole setup. I implemented very similar code to initialize the MCP client connected to the Bedrock AgentCore Gateway in the McpToolService class. MCP client is then exposed as a Spring bean in the EmbabelConferenceApplication class:

@Bean 
@Primary
public McpSyncClient geMcpClient() {
    return this.mcpToolService.getMcpClient();
}

By invoking the withToolGroup(this.getMcpToolGroupByName("get-talks-by-")) method on the PromptRunner (see above), we achieved another goal that we described in part 1. We not only split the prompt into individual actions, but are now also able to provide exact MCP tool(s) required to execute it. Embabel provides the ToolGroup abstraction for this. In this case, we give the LLM only the tools whose names consist of the get-talks-by- substring. I implemented the MCP tool filtering in the AbstractConferenceAgent class:

protected ToolGroup getMcpToolGroupByName(String name) {
    var  toolGroupDescription=  ToolGroupDescription.Companion.invoke(
         "A collection of tools to interact with 
         the MCP conference search service",
         "location",""
   );

  var noOp= ToolCallContextMcpMetaConverter.Companion.noOp();   

  return new McpToolGroup(
          toolGroupDescription,
          "Vadym",
          name,
          Set.of(ToolGroupPermission.INTERNET_ACCESS),
          List.of(mcpClient),
          callback -> filterMcpTool(callback, name),
          noOp
      );
}

private boolean filterMcpTool (ToolCallback toolCallback, String name) {
    // not passing name means return true -> pass all tools
      if(name==null) return true;
      return toolCallback.getToolDefinition().name().contains(name);
 }

The downside is that if we were to rename the MCP tools, we'd need to adjust their names here also. The alternative is to use semantic search for the tools. The alternative is to use semantic search for the tools.

Now let's come back to the config.speaker() method invocation, which we saw in the talkSearch action. Embabel gives the possibility to create different roles and attach different LLMs to them. In our case, we have 2 roles: conference attendee and conference speaker. We can define these roles either programmatically or in the application.properties:

conference.attendee.llm.role=best
conference.attendee.persona.role=Conference attendee
conference.attendee.persona.goal=Conduct a thorough conference search with the information (topics, conference dates) provided so I decide which to attend.
conference.attendee.persona.backstory=As a Conference Attendee Specialist, your mission is to find a suitable conference that matches the given request


conference.speaker.llm.role=best
conference.speaker.persona.role=Conference speaker
conference.speaker.persona.goal=Conduct the search for the talks or create the talk with the given criteria with the conference application for those talks
conference.speaker.persona.backstory=As a Conference Speaker Specialist, your mission is to search for the talk or create the talk with the given criteria with the conference application for those talks

We also link each role to the LLM model by referencing the previously defined LLM strategy (in our case, by the name best). See the LLM definition once again:

embabel.models.default-llm=us.anthropic.claude-sonnet-4-6
embabel.models.llms.best=us.anthropic.claude-sonnet-4-6
embabel.models.llms.balanced=us.amazon.nova-pro-v1:0

In our case, the best LLM strategy will use the us.anthropic.claude-sonnet-4-6 model.
Next, we defined ConferenceConfig to have access to the roles and actors:

@Validated
@ConfigurationProperties(prefix = "conference")
public record ConferenceConfig(Actor<RoleGoalBackstory> attendee,   
    Actor<RoleGoalBackstory> speaker) {
}

The conference prefix, together with Actor definitions, determines the mapping to the roles. For example, Actor speaker matched the conference.speaker role definition in the application.properties.

Finally, we injected the ConferenceConfig object (as config) into the constructor of each agent.

Similarly, we split the initial prompt into other individual steps or actions for searching for conferences. See the extractConferenceSearchRequest and conferenceSearch agents in the AbstractConferenceAgent class. Also, the last step (applying for conferences with talks) looks similar. See the applyForConference action in the same class. There are 2 things to notice here:

We don't ask the LLM to split the prompt. This is because the input to this action is the output of 2 actions before: talkSearch and conferenceSearch, and 2 domain objects, Domain.Conferences and Domain.Talks respectively. Both become the input to the PromptContributors.
This agent is additionally annotated with the AchievesGoal annotation to outline that this action execution is the final step that the agent should take in the workflow. See the complete code:

@Action
@AchievesGoal(description = "apply for the conferences with their IDs and talk IDs and provide status of the application")
    Domain.ConferenceApplications applyForConference(Domain.Conferences conferences, Domain.Talks talks, Ai ai) {
     return config.speaker()
         .promptRunner(ai)
         .withPromptContributors(List.of(conferences, talks))
         .withToolGroup(this.getMcpToolGroupByName("apply-to-conference"))
         .createObject("Apply for the conference with the given criteria", Domain.ConferenceApplications.class);
 }

We're completely done with the SearchForTalksAndApplyForConferencesAgent agent.

The implementation of the agent CreateTalksAndApplyForConferencesAgent looks very similar. The biggest difference is the first step: instead of searching for the existing talks, the talk is created. See the extractTalkCreationRequest and createTalks actions.

Now come the biggest questions:

How is Embabel capable of identifying which agent to execute?
How is Embabel capable of identifying the order of actions to execute for the individual agent? We only defined the last action to finally achieve the goal properly by annotation.

Let's build the application with mvn clean package and run it locally with mvn spring-boot:run. We see that Embabel starts the shell, and we can execute the prompt by running:

x '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.'

Let's see what happens next:

Embabel identifies 2 agents, takes their description to compute the score, and chooses a concrete agent to execute based on the user input (prompt). I assume Embabel also uses an LLM for it. As a result, it computed: As a result, it computed :

SearchForExistingTalksAndApplyForConferencesAgent: 0,97
CreateNewTalksAndApplyForConferencesAgent: 0,05

So, the SearchForExistingTalksAndApplyForConferencesAgent agent is clearly a winner.

Next, we see that Embabel formulates a plan to achieve the goal:

The sequence of agent actions to execute is a correct one :

Embabel could also come up with the plan to first search for the conferences, then for the talks, and then to apply. Both plans are valid. How does Embabel create such a plan? The system, not the programmer, dynamically formulates plans. The system replans after the completion of each action, allowing it to adapt to new information as well as observe the effects of the previous action. This is effectively an OODA loop. Emabebl analyzes the input and output types of each agent that we defined. This also helps to formulate the plan.

We see how Embabel executes those individual actions in the identified order. It logs all structured outputs of each action. The final output looks like this:

It found 2 talks and 1 conference to apply those talks that matched the criteria that we defined in the prompt. Finally, Embabel provides the statistics of the LLM used, the number of input (prompt) and output (completion) tokens spent. We also see the total cost of the agent execution. Embabel maintains the LLM pricing database. I don't expect this information to be very accurate, but it provides some indication. We also see the MCP tool names that the LLM used during the agent execution, their response times, and the number of failures.

If we execute the prompt x '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.', we'll see that Embabel chooses to execute the CreateNewTalksAndApplyForConferencesAgent agent :

It then formulates the plan and executes the actions to achieve the goal:

Finally, it provides the same statistics, which we previously explained:

There are many more features that Embabel provides, like retries, which we'll explore in later articles.

Conclusion

In this article, we developed our first AI agents with the Embabel shell. We learned many concepts of this framework, such as agents, actions, and goals. In the next article, we'll slightly adjust our application to convert it into a web application.

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 Embabel, Spring AI and Amazon Bedrock AgentCore - Part 1 Introduction to the series and to the Embabel framework

Vadym Kazulkin — Mon, 20 Jul 2026 14:28:13 +0000

Introduction to the series and to the Embabel framework

In my article series Building AI Agents with Spring AI and Amazon Bedrock AgentCore, we've already covered how to build AI Agents with Spring AI and Amazon Bedrock AgentCore. You'll need to go through at least its first 4 parts to be able to follow this article series. I'll reuse that sample application for this series. Why might the abstractions provided by Spring AI frameworks alone not be enough? Let's look at the prompt that we sent to our application in Provide MCP tools for Conference application via AgentCore Gateway:

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

The prompt is highly unstructured. We set here at least 3 pairs of requests to the LLM and their responses:

Request: "Please provide me with the list of conferences, including their IDs, with Java topics happening in 2027, with the call for papers open today". LLM responds to it.
Request: "Provide me with the list of my talks with this topic in the title". LLM responds to it.
Request: "For each conference and talk retrieved, apply individually for the conference". This request means that the LLM uses its responses from the first 2 requests as the request and responds to it.

The thing is that we, as humans, can think logically, but not every LLM can break this prompt down into such individual pieces. So, it might require a strong and more expensive model to be able to do it. If we can automatically break down the problem into subtasks so the prompt will become structured, the LLM will have better chances at doing its job right. Spring AI has a function CallResponseSpec.entity method for the synchronous LLM call to at least convert the response to structured output. But again, this is not enough, as we need to break down the initial prompt into a set of structured subtasks first.

The next challenge is that in the same article, we exposed 7 MCP tools through the Bedrock AgentCore Gateway. And we gave all of them to the LLM all at once. This is because the LLM can't respond to any request without using the correct tool. And there is always only 1 correct tool out of 7 per request. It not only blows up the content window, but there is also a high chance that the LLM will hallucinate. It may not only break down the prompt correctly, but may also select the wrong tool to respond to the request.

Wouldn't it be better if we could break down the prompt as described above and give the LLM exactly the correct tool per request? See the parts 2 and 4 to see how we defined and exposed those MCP tools. For the first request, it will be the "conference search tool by topic, date, and call for papers open" tool. Then, for the second tool - "get talks by title substring" tool. For the third - "apply to conferences with conference ID and talk ID" tool.

With Spring AI, we can filter the tools, as we explained in part 3. But it's not enough as long as we can't break down the big prompt into individual subtasks, which may require suitable tool(s). If we implement prompt handling in a not structured way, it's not trivial to implement the tool filtering. This is because different prompts may require different tools depending on their content.

The same challenges have another prompt from the same article: "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."

The only difference from the previous prompt is that we ask the LLM to create a new talk instead of extracting the existing talk(s). For this, the LLM will need to use the "create new talk" tool.

Also, our application has 2 different actors. First, these are conference attendees who are interested in searching for and attending the conference. Second, these are the conference speakers who apply to the conference with their talk(s). Maybe those actors should use a different LLM model that suits each role the best.

Welcome to the Embabel. It's a framework for authoring agentic flows on the JVM that seamlessly mixes LLM-prompted interactions with code and domain models. It supports intelligent finding the path towards goals. Embabel builds on the Spring AI framework.

I give some links to the resources, which will help you to grasp the concepts of this framework quickly.

Embabel user guide
Embabel Agentic AI Framework Release 1.0.0: New Features by Igor Dayen
The AI Generation Is Coming of Age: Enterprise JVM Agents with Embabel by Rod Johnson
Developing AI Agents in Java with Embabel (Getting Started) by Dan Vega
Embabel Tools & MCP Servers: Optimize Your Java AI Agents by Dan Vega

We'll explore in the next articles that Embabel is capable of addressing and solving those challenges that we described above. Throughout this series, We'll improve the agent developed in the Provide MCP tools for Conference application via AgentCore Gateway article using the Embabel framework. First, we'll use the Embabel shell, then the web application. You can already look at my GitHub embabel-1.x-conference-app-agent-local repository for the example.

The reasons I decided to create a separate series for using the Embabel framework are:

Embabel recently became generally available (GA), and the current version is 1.0.0. I expect a lot of new functionality to be added soon. I don't want to mix the Embabel and Spring AI content, even though Embabel builds on Spring AI.
Embabel currently doesn't support Spring Boot 4.x and Spring AI 2.x version. So, also here I'll need to update my examples when that version support is there.
It's unclear whether it's possible to integrate spring-ai-agentcore into Embabel. For example, spring-ai-agentcore-runtime-starter, which we demonstrated for Spring AI in the article Deploy MCP client on AgentCore Runtime using Spring AI AgentCore Starter. And especially spring-ai-agentcore-memory, which we demonstrated in the articles Use Spring AI AgentCore short-term Memory for MCP client on AgentCore Runtime and Use Spring AI AgentCore long-term Memory for MCP client on AgentCore Runtime.

Stay tuned!

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

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

Building AI Agents with Spring AI and Amazon Bedrock AgentCore - Part 9 Configure AgentCore Observability

Vadym Kazulkin — Mon, 13 Jul 2026 12:03:51 +0000

Introduction

In part 6, we introduced our sample application spring-ai-2.0-ac-conference-app-agent-bedrock-agentcore-runtime using Spring AI AgentCore. Later, in parts 7 and 8, we added AgentCore short- and long-term Memory, respectively, using Spring AI AgentCore Memory.

In this part of the series, we'll explore how to configure AgentCore Observability. I've already covered this topic in my other article series when we used the Strands Agents SDK. I refer to my following articles:

Even though the CloudWatch Generative AI Observability service UI now looks different and has more capabilities, CloudWatch Logging and Monitoring configuration looks the same for our application and is provided out of the box. For the CloudWatch metrics, please review the article Amazon Bedrock AgentCore generated observability data for the current state of the exposed metrics. Also, make sure to enable Log delivery for Application and Usage Logs and Tracing for all AgentCore Services involved. In our case, these are:

Runtime (2 of them, as we host the MCP server and the Agent there)
Gateway
Memory (both short- and long-term).
Identity (please make sure to do so for the Runtime and Gateway Identity)

Enabling AgentCore Tracing

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

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

AWS offers AWS Distro for OpenTelemetry Java with the AWS Distro for OpenTelemetry (ADOT). To get started, see the AWS Distro for OpenTelemetry Java documentation. Let's add it to our sample application. To do so, we need to modify the Dockerfile of our sample application. We first have to download the aws-opentelemetry-agent and then run it as the Java agent to instrument the code on the fly:

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

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

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

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

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

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

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

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

Then, after rebuilding and redeploying the application, we can see similar metrics and traces as provided in the articles using Strands Agents SDK above. There are, of course, some differences in the collected metadata. This is because we use the AWS OpenTelemetry Agent distribution for Java and not for Python, as in the articles above. Here are some selected screenshots taken from the CloudWatch GenAI Observability: Bedrock AgentCore Observability for the prompt "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.", which I sent :

All sessions view:

All traces view:

All spans view:

Session ID view:

Tree view of the Trace ID:

Trajectory view of the Trace ID:

Timeline view of the Trace ID:

This is how to enable observability for Amazon Bedrock AgentCore Runtime hosted agents. If you don't host your application on AgentCore, you can still use CloudWatch to enable observability for non-Amazon Bedrock AgentCore-hosted agents.

Conclusion

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

In the next article, we'll explore how to configure the same AgentCore observability with the help of spring-ai-agentcore-otel-extension.

Please also check out my other series on Building AI Agents with Embabel, Spring AI, and Amazon Bedrock AgentCore.

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 8 Use Spring AI AgentCore long-term Memory for MCP client on AgentCore Runtime

Vadym Kazulkin — Mon, 06 Jul 2026 14:07:04 +0000

Introduction

In part 7, we explained how to add and use AgentCore short-term Memory to our application with the help of Spring AI AgentCore Memory. In this article, we'll use AgentCore long-term Memory instead.

We'll once again build on the spring-ai-2.0-ac-conference-app-agent-bedrock-agentcore-runtime sample application, which we introduced in part 6. Please review part 7 to better understand the base concept of Spring AI AgentCore Memory and how to add it to our application.

Create Bedrock AgentCore long-term Memory

I've written the article Amazon Bedrock AgentCore Runtime - Part 7 Using AgentCore long-term Memory with Strands Agents SDK about what AgentCore long-term Memory is and how to create one with the Python SDK. Also provided an example of how to use it with Strands Agent SDK. I refer to this article to understand the basics.

To run examples, we've already deployed our sample application on AgentCore Runtime by executing the RuntimeWithMCPStack stack in part 6. Next, let's create AgentCore long-term Memory with CDK for Java by executing the LongTermMemoryStack stack. First, let's look at what is happening there:

public class LongTermMemoryStack extends Stack {

 public LongTermMemoryStack(Construct scope, String appName,  StackProps stackProps) {
    super(scope, id, stackProps);   
    var memory = Memory.Builder.create(this, "long-term-memory")
    .memoryName("long_term_memory_for_conference_application")
    .description("Long-Term Memory for Conference Application")
    .expirationDuration(Duration.days(7))
    .memoryStrategies(List.of(MemoryStrategy.usingBuiltInSummarization(),
                      MemoryStrategy.usingBuiltInSemantic()))
    .build();                 

    CfnOutput.Builder.create(this, "LongTermMemoryIdOutput").value(memory.getMemoryId()).build();           
    }  
}

We use Bedrock AgentCore Memory.Builder to set the memory name, description, expiration duration, and then create the memory. By defining the memory strategies, we outline that we'll create the AgentCore long-term memory. We used the semantic and summarization built-in memory strategies. You can also set the currently supported user preference and episodic memory strategies instead. The MemoryStrategy class offers usingBuiltInUserPreference and usingBuiltInEpisodic methods for this purpose. You can also configure the Custom Memory Strategy.

You can deploy the stack with the command: cdk deploy spring-ai-ac-conference-application-lt-memory-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

This is how the created long-term memory looks in the AgentCore Memory UI:

And this is how the default namespaces look:

If you're not satisfied with the built-in configuration, for example, default namespaces, you can set your own. Here is an example of how to create a semantic memory strategy:

 MemoryStrategy.usingSemantic(ManagedStrategyProps.builder()
     .name("name")
     .namespaces(List.of("namespace1", "namespace2"))
     .build());

Other memory strategies work the same; just use the corresponding using* method. But I always start with the built-in memory strategies.

Also, the Memory ID will be printed out, which we will need to configure in our Spring AI application. We can find the same Memory ID in the service UI above.

Finally, we need to configure the following IAM permissions to allow our application running on AgentCoreRuntime to access this AgentCore Memory:

{
 "Sid": "BedrockAgentCoreLongTermMemory",
   "Effect": "Allow",
   "Action": [
       "bedrock-agentcore:ListEvents",
       "bedrock-agentcore:CreateEvent",
       "bedrock-agentcore:RetrieveMemoryRecords",
       "bedrock-agentcore:GetMemory"
      ],
   "Resource": [
         "arn:aws:bedrock-agentcore:{YOUR_AWS_REGION}:{YOUR_AWS_ACCOUNT_ID}:memory/{YOUR_LONG_TERM_MEMORY_ID}"
      ]
}

Configure Bedrock AgentCore long-term Memory in our sample application

To configure Bedrock AgentCore long-term Memory in our sample application, we need to make some changes to it. First, we need to configure some long-term memory-related properties in the application.properties:

agentcore.memory.memory-id={YOUR_LONG_TERM_MEMORY_ID}
agentcore.memory.long-term.auto-discovery=true

The first required property is the AgentCore Memory ID we just created. By setting agentcore.memory.long-term.auto-discovery to true, we use the recommended AgentCore long-term Memory autodiscovery option.

Autodiscovery behavior is:

Queries AWS to discover all strategies configured in your memory
Creates advisors only for supported types: SEMANTIC, SUMMARIZATION, USER_PREFERENCE, EPISODIC
Skips CUSTOM strategy types (not supported by autodiscovery)
Uses the first namespace if a strategy has multiple namespaces
Uses default topK values for each strategy type

We can also override the specific settings for discovered strategies by providing explicit configuration. See the link above to find out how to do this. Another option is to use the AgentCore long-term Memory explicit configuration option, in which we need to specify each strategy manually.

Next, we need to ensure that we set ChatMemory to the ChatClient in the SpringAIAgentController. I'll provide the generic constructor, capable of dealing with no AgentCore Memory configured or short-term or long-term memory configured:

public SpringAIAgentController(ChatClient.Builder builder, 
ChatMemory chatMemory, List<AgentCoreLongTermMemoryAdvisor> ltmAdvisors) {
   var options = ToolCallingChatOptions.builder()
      .model("us.anthropic.claude-sonnet-4-6")
      .maxTokens(2000);

   this.chatClient = builder.defaultOptions(options)      
           .defaultAdvisors(this.getAllMemoryAdvisors(chatMemory, ltmAdvisors))
         .build())
         .build();          
....
}

private List<Advisor> getAllMemoryAdvisors(ChatMemory chatMemory, List<AgentCoreLongTermMemoryAdvisor> ltmAdvisors) { 
   Advisor chatMemoryAdvisor= MessageChatMemoryAdvisor.builder(chatMemory).build();
   var cltmAdvisors=(List<Advisor>)(List<?>) ltmAdvisors;  
   var allAdvisors=new ArrayList<Advisor>();
   allAdvisors.addAll(cltmAdvisors);
   if(chatMemoryAdvisor!=null) {
      allAdvisors.add(chatMemoryAdvisor);
   }
   return allAdvisors;
}

Short-term Spring AI AgentCore Memory implements the Spring AI ChatMemoryRepository interface. This doesn't work for long-term Spring AI AgentCore Memory. For this, we inject the list of AgentCoreLongTermMemoryAdvisor. Then we use the Advisors API to build the complete list of Advisors in the getAllMemoryAdvisors method. We use MessageChatMemoryAdvisor with the ChatMemory to build the short-term memory advisor, and then we add the long-term advisors to the list. We then provide this complete list of memory advisors as an input to the defaultAdvisors method of the ChatClient.Builder. Even if we don't configure the AgentCore short-term or long-term Memory (or both), the same code still works without throwing any exceptions. MessageChatMemoryAdvisor, and List of AgentCoreLongTermMemoryAdvisors or both will be null in such a case, which Spring AI treats the same way as not setting any advisors. That's all the changes we need to make to our application to use the AgentCore long-term memory.

The last step is exactly the same as for the short-term memory: to include a custom ChatMemory Conversation ID in the ChatClient. According to the documentation, ChatMemory.CONVERSATION_ID parameter is required for all memory advisors. Calls that omit this parameter will throw an IllegalArgumentException at runtime, as there is no default conversation ID.
The Spring AI AgentCore long-term Memory supports flexible conversation ID formats:

Simple: user123 → actor: user123, session: default-session
With Session: user123:session456 → actor: user123, session: session456

This is how the code looks for it in the SpringAIAgentController:

private final String CONVERSATION_ID="default-actor-id-12345678:default-session-id-12345678";

@AgentCoreInvocation
public Flux<String> invoceAsync(PromptRequest promptRequest, AgentCoreContext agentCoreContext) {
    var token = getAuthTokenViaHttpClient();
    ...
    var client = McpClient.async(getMcpClientTransport(token)).build();
    client.initialize();

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


    var content = this.chatClient.prompt()
       .user(promptRequest.prompt())
       .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, CONVERSATION_ID))
       .tools(new DateTimeTools(),asyncMcpToolCallbackProvider.getToolCallbacks()).stream()
       .content();

As shown above, we defined a static CONVERSATION_ID. However, if you'd like to use individual IDs depending on the actor or user providing the prompt, you can add the login functionality and set the individual user ID. Finally, we set the value of the conversation ID as the parameter of the memory advisor.

Then we need to rebuild the Docker image of our application and deploy it to the Amazon ECR. After it, we need to configure the correct ecrImageURI in the cdk.json. We covered those concepts in parts 2 and 4.

Finally, we need to redeploy the AgentCore Runtime stack with the command: cdk deploy spring-ai-ac-conference-application-agentcore-runtime-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

Now, we can use the InvokeRuntimeAgent class to send prompts to our agent running on AgentCore Runtime. We described this in part 5 and can reuse these prompts to apply the talks to the conferences.

But now, similarly to the example of the short-term memory in part 7, we can ask such questions as: "You recently applied for some conferences for me. Can you provide me with the details?" The agent will give us a reply, which shows that it provided the answer using the AgentCore long-term Memory:

The reply is very similar to one provided in part 7 for the long-term memory.

Conclusion

In this article, we explained how to add and use AgentCore long-term Memory to our application with the help of Spring AI AgentCore Memory. In the next article, we'll add AgentCore Observability to our application.

Please also check out my other series on Building AI Agents with Embabel, Spring AI, and Amazon Bedrock AgentCore.

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 7 Use Spring AI AgentCore short-term Memory for MCP client on AgentCore Runtime

Vadym Kazulkin — Mon, 29 Jun 2026 14:00:35 +0000

Introduction

In part 6, we used Spring AI AgentCore Starter in our sample application to deploy and run our MCP client on AgentCore Runtime. We used several useful features of the Spring AI AgentCore Starter, like annotation-based auto-configuration, smart health checks, and rate limiting.

Until now, our agent deployed on AgentCore Runtime was stateless. If we apply for conferences with some talks and then ask the agent in the next conversation about which talks we applied for which conferences, the agent won't be able to answer. In this article, we'll add the AgentCore Memory to our application. We'll start with the short-term memory and later add the long-term memory. Then, we'll show how to use Spring AI AgentCore Memory, which provides the Spring AI ChatMemory integration with the Amazon Bedrock AgentCore Memory service.

We'll build on the spring-ai-2.0-ac-conference-app-agent-bedrock-agentcore-runtime sample application, which we introduced in part 6.

Spring AI AgentCore Memory

Spring AI AgentCore Memory provides Spring AI ChatMemory integration with the Amazon Bedrock AgentCore Memory service.
Its features currently include:

Spring AI Integration: Implements ChatMemoryRepository interface
Auto-configuration: Zero-configuration setup with Spring Boot
Short-Term Memory: Conversation history with MessageWindowChatMemory
Long-Term Memory: 4 consolidation strategies (Semantic, User Preference, Summary, Episodic)

To use Spring AI AgentCore Memory in our application, we need to add one more dependency to the pom.xml:

<dependency>
    <groupId>org.springaicommunity</groupId>
    <artifactId>spring-ai-agentcore-memory</artifactId>
</dependency>

As stated above, in this article, we'll cover short-term memory, leaving the long-term memory to the next article.

Create Bedrock AgentCore short-term Memory

I've written the article Amazon Bedrock AgentCore Runtime - Part 6 Using AgentCore short-term Memory with Strands Agents SDK about what AgentCore short-term Memory is and how to create one with the Python SDK. Also provided an example of how to use it with the Strands Agent SDK. I refer to this article to understand the basics.

To run examples, we've already deployed our sample application on AgentCore Runtime by executing the RuntimeWithMCPStack stack in part 6. Next, let's create AgentCore short-term Memory with CDK for Java by executing the ShortTermMemoryStack stack. First, let's look at what is happening there:

public class ShortTermMemoryStack extends Stack {

 public ShortTermMemoryStack(Construct scope, String appName,  StackProps stackProps) {
    super(scope, id, stackProps);   
    var memory = Memory.Builder.create(this, "short-term-memory-1")
              .memoryName("short_term_memory_for_conference_application")
              .description("Short-Term Memory for Conference Application")
              .expirationDuration(Duration.days(7))
              .build();   

    CfnOutput.Builder.create(this, "ShortTermMemoryIdOutput").value(memory.getMemoryId()).build();           
    }  
}

We use Bedrock AgentCore Memory.Builder to set the memory name, description and expiration duration, and then create the memory.

You can deploy the stack with the command: cdk deploy spring-ai-ac-conference-application-st-memory-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

As we don't set any memory strategy, the short-term memory will be created like this:

Also, the Memory ID will be printed out, which we will need to configure in our Spring AI application. We can find the same Memory ID in the service UI above.

Finally, we need to configure the following IAM permissions to allow our application running on AgentCoreRuntime to access this AgentCore Memory:

{
 "Sid": "BedrockAgentCoreShortTermMemory",
   "Effect": "Allow",
   "Action": [
       "bedrock-agentcore:ListEvents",
       "bedrock-agentcore:CreateEvent",
       "bedrock-agentcore:RetrieveMemoryRecords"
      ],
   "Resource": [
         "arn:aws:bedrock-agentcore:{YOUR_AWS_REGION}:{YOUR_AWS_ACCOUNT_ID}:memory/{YOUR_SHORT_TERM_MEMORY_ID}"
      ]
}

Configure Bedrock AgentCore short-term Memory in our sample application

To configure Bedrock AgentCore short-term Memory in our sample application, we need to make some changes to it. First, we need to configure some short-term memory-related properties in the application.properties:

agentcore.memory.memory-id={YOUR_SHORT_TERM_MEMORY_ID}
agentcore.memory.total-events-limit=10 #Max events to retrieve (context window), default 100
agentcore.memory.default-session=default-session-id-12345678 #Default session name, default name is default-session
agentcore.memory.page-size=50  #API pagination size, default value is 50
agentcore.memory.ignore-unknown-roles=false #Handle unknown message roles, default value is false

The only required property is the AgentCore Memory ID we just created. All others are optional, with default values described in the Spring AI AgentCore Memory Configuration Reference.

Next, we need to ensure that we set ChatMemory to the ChatClient in the SpringAIAgentController. We've already set it up like this:

public SpringAIAgentController(ChatClient.Builder builder, ChatMemory chatMemory) {
var options = ToolCallingChatOptions.builder()
   .model("us.anthropic.claude-sonnet-4-6")
   .maxTokens(2000);

this.chatClient = builder.defaultOptions(options)
          //short term memory         
         .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory)
         .build())
         .build();          
....
}

Short-term Spring AI AgentCore Memory implements the Spring AI ChatMemoryRepository interface. That's why, when we provide the memory configuration as above, Spring AI injects the correct implementation of the ChatMemory into the constructor. Then we use the Advisors API to build MessageChatMemoryAdvisor with the ChatMemory and to provide it as an input to the defaultAdvisors method of the ChatClient.Builder. Even if we don't configure the AgentCore short-term Memory, the same code still works without throwing any exceptions. MessageChatMemoryAdvisor will be null, which Spring AI treats the same way as not setting any advisors. That's all the changes we need to make to our application to use the AgentCore short-term memory.

In addition, we need to include a custom ChatMemory Conversation ID in the ChatClient. According to the documentation, the ChatMemory.CONVERSATION_ID parameter is required for all memory advisors. Calls that omit this parameter will throw an IllegalArgumentException at runtime, as there is no default conversation ID.
The Spring AI AgentCore long-term Memory supports flexible conversation ID formats:

Simple: user123 → actor: user123, session: default-session
With Session: user123:session456 → actor: user123, session: session456

This is how the code looks for it in the SpringAIAgentController:

private final String CONVERSATION_ID="default-actor-id-12345678:default-session-id-12345678";

@AgentCoreInvocation
public Flux<String> invoceAsync(PromptRequest promptRequest, AgentCoreContext agentCoreContext) {
    var token = getAuthTokenViaHttpClient();
    ...
    var client = McpClient.async(getMcpClientTransport(token)).build();
    client.initialize();

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

    var content = this.chatClient.prompt()
       .user(promptRequest.prompt())
       .advisors(a -> a.param(ChatMemory.CONVERSATION_ID, CONVERSATION_ID))
       .tools(new DateTimeTools(),asyncMcpToolCallbackProvider.getToolCallbacks())
       .stream()
       .content();

Finally, we need to redeploy the AgentCore Runtime stack with the command: cdk deploy spring-ai-ac-conference-application-agentcore-runtime-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

Now, we can use the InvokeRuntimeAgent class to send prompts to our agent running on AgentCore Runtime. We described this in part 5 and can reuse these prompts to apply the talks to the conferences.

But now, additionally, we can ask such questions as: "You recently applied for some conferences for me. Can you provide me with the details?" The agent will give us a reply similar to the reply shown below, which shows that it provided the answer using the AgentCore short-term Memory:

Conclusion

In this article, we explained how to add and use AgentCore short-term Memory to our application with the help of Spring AI AgentCore Memory. In the next article, we'll use AgentCore long-term Memory instead.

Please also check out my other series on Building AI Agents with Embabel, Spring AI, and Amazon Bedrock AgentCore.

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 6 Deploy MCP client on AgentCore Runtime using Spring AI AgentCore Starter

Vadym Kazulkin — Mon, 22 Jun 2026 14:25:38 +0000

Introduction

In part 5, we looked at how to deploy and run our MCP client on AgentCore Runtime. Starting from this article, we'll look at the Spring AI AgentCore functionality. In this article, we'll use Spring AI AgentCore Starter in our sample application to deploy and run our MCP client on AgentCore Runtime. As Spring AI 2.0 and Spring Boot 4.1 have both already gone GA, I updated our application to use them; see pom.xml. For this, I created a new spring-ai-2.0-ac-conference-app-agent-bedrock-agentcore-runtime. It consists of the agent and Infrastructure as Code (IaC) subfolders.

Differences in the implementation of the MCP client for the Conference application between Spring AI 1.1 and 2.0

I have noticed several major differences in the implementation of the MCP client for the Conference application. We developed it mainly in part 3, and then adjusted it in part 4 and part 5. See SpringAIAgentController for the full version of the controller.

The first one is that ChatClient now requires passing the ChatOptions.Builder object to the defaultOptions method instead of the ChatOptions object itself:

var options = ToolCallingChatOptions.builder()
        .model("us.anthropic.claude-sonnet-4-6")
        .maxTokens(2000);

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

Next, the biggest difference is that instead of using WebClient from the Spring Webflux dependency, Spring AI 2.0 now uses HttpRequest.Builder from the java.net.http module to create an MCP HTTP Streamable transport. Also, the implementation of this protocol is now in the HttpClientStreamableHttpTransport class, which was adjusted to use the java.net.http module. In Spring AI 1.*, the class name was WebClientStreamableHttpTransport:

private McpClientTransport getMcpClientTransport(String token) {

 var mcpServerConfig= this.getMCPServerConfig();
 var headerValue = "Bearer " + token;

 var httpRequestBuilder = HttpRequest.newBuilder()
     .header("Authorization", headerValue);

 return HttpClientStreamableHttpTransport.builder(mcpServerConfig.baseUrl)
     .connectTimeout(Duration.ofMinutes(3))
     .endpoint(mcpServerConfig.endpoint)        
     .requestBuilder(httpRequestBuilder)
     .build();
}

It also requires splitting the MCP endpoint URL into 2 parts: base URL (domain) and endpoint itself (/mcp), which we did in the application.properties:

amazon.bedrock.agentcore.gateway.base.url=https://spring-ai-conference-search-agentcore-gateway-xizwpytsgm.gateway.bedrock-agentcore.us-east-1.amazonaws.com
amazon.bedrock.agentcore.gateway.endpoint=/mcp

Lastly, Spring AI 2.0 introduced some changes to how to use the MCP tools. This is how the code looked in the previous Spring AI 1.x versions:

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

The code in Spring AI 2.0 uses the tools method, capable of accepting the local tools as well as tool callbacks as its parameters:

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

Also, we need to additionally define the ToolCallingManager Spring bean in the main SpringAIConferenceAppOnAgentCoreRuntimeApplication class:

@Bean ToolCallingManager toolCallingManager() {
   return ToolCallingManager.builder().build();
}

Everything else remains the same as described in parts 3-5.

Spring AI AgentCore SDK

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. We'll start by using Spring AI AgentCore Starter in this article and then cover Spring AI AgentCore Memory in subsequent articles.

Spring AI AgentCore Starter

Spring AI AgentCore Starter is a Spring Boot starter that enables existing Spring Boot applications to conform to the Amazon Bedrock AgentCore Runtime contract with minimal configuration. Its features currently include:

Auto-configuration: Automatically sets up AgentCore endpoints when added as a dependency
Annotation-based: Simple @AgentCoreInvocation annotation to mark agent methods
SSE Streaming: Server-Sent Events support with Flux return types
Smart health checks: Built-in /ping endpoint with Spring Boot Actuator integration
Async task tracking: Convenient methods for background task tracking
Rate limiting: Built-in Bucket4j throttling for invocations and ping endpoints

Let's add the relevant dependencies to pom.xml:

<dependencyManagement>
   <dependencies>
       <dependency>
            <groupId>org.springaicommunity</groupId>
            <artifactId>spring-ai-agentcore-bom</artifactId>
            <version>${spring-ai-agentcore-version}</version> 
            <type>pom</type>
            <scope>import</scope>
       </dependency>
   </dependencies>
</dependencyManagement>
...
<dependencies>
  <dependency>
     <groupId>org.springaicommunity</groupId>
     <artifactId>spring-ai-agentcore-runtime-starter</artifactId>
  </dependency>
  <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
  </dependency>
</dependencies>

By adding the spring-ai-agentcore-runtime-starter dependency, we can now use org.springaicommunity.agentcore.annotation.AgentCoreInvocation annotation to annotate the method. Exactly this method we'll expose as a /invocation POST endpoint on the Bedrock AgentCore Runtime. Please note that only one method per application can be annotated with this annotation. Next, we need to do a small adjustment to the SpringAIAgentController to use this annotation:

@AgentCoreInvocation
public Flux<String> invoceAsync(PromptRequest promptRequest, AgentCoreContext agentCoreContext) {
...
return this.chatClient.prompt()
         .user(promptRequest.prompt())
         .tools(new DateTimeTools(),asyncMcpToolCallbackProvider.getToolCallbacks())
         .stream().content();
}

PromptRequest is a Java record representing a prompt:

public record PromptRequest(String prompt){};

Spring AI Starter also supports rate limiting. The starter includes built-in rate limiting using Bucket4j to protect against excessive requests. However, rate limiting is deactivated by default and will be active only if limits are defined in application.properties:

agentcore.throttle.invocations-limit=20
agentcore.throttle.ping-limit=250

The provided rate limit response is an HTTP response code 429:
({"error":"Rate limit exceeded"}).
Rate limits are also applied per client IP address and reset every minute.

Next, please comment out all application properties starting with agentcore.memory, as we'll need them in the upcoming article where we'll cover Bedrock AgentCore Memory.

By adding the dependency to the spring-boot-starter-actuator, we enabled health monitoring. We no longer need to implement the intelligent /ping endpoint ourselves.

Without Spring Boot Actuator:

Returns static "Healthy" status
Always responds with HTTP 200

With Spring Boot Actuator:

Integrates with Actuator health checks
Maps Actuator status to AgentCore format: UP → "Healthy" (HTTP 200), DOWN → "Unhealthy" (HTTP 503), Other → "Unknown" (HTTP 503)
Tracks status change timestamps
Thread-safe concurrent access

Then, let's briefly cover the IaC part with CDK for Java, which I implemented in the RuntimeWithMCPStack stack. It's completely identical to the IaC that we described in part 5. I wanted to have a separate IaC stack (also including an IAM role and ECR repository) for this Spring AI 2.0 and Spring AI AgentCore application. Also, please comment out the ShortTermMemoryStack and LongTermMemoryStack execution in the CDKApp class. We'll cover those later.

You can deploy the stack with the command: cdk deploy spring-ai-ac-conference-application-agentcore-runtime-stack -c awsAccountId={YOUR_AWS_ACCOUNT_ID}.

Finally, please visit the above-mentioned part 5 for more details on how to deploy this application on AgentCore Runtime and send prompts to it. All the prompts remain valid, as this is the same application, but using Spring AI AgentCore now.

Conclusion

In this article, we used Spring AI AgentCore Starter in our sample application to deploy and run our MCP client on AgentCore Runtime. We used several useful features of the Spring AI AgentCore Starter, like annotation-based auto-configuration, smart health checks, and rate limiting.

Until now, our agent deployed on AgentCore Runtime was stateless. If we apply for the conferences with some talks and then ask the agent in the next conversation about which talks we applied for which conferences, the agent won't be able to answer. In the next article, we'll add the AgentCore Memory to our application. We'll start with the short-term memory and later add the long-term memory. Then, we'll show how to use Spring AI AgentCore Memory, which provides the Spring AI ChatMemory integration with the Amazon Bedrock AgentCore Memory service.

Please also check out my other series on Building AI Agents with Embabel, Spring AI, and Amazon Bedrock AgentCore.

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 7 Lambda performance optimization approaches

Vadym Kazulkin — Mon, 15 Jun 2026 14:51:59 +0000

Introduction

In the previous articles of the series about how to develop, run, and optimize Serverless applications on AWS with Lambda using Java 25, API Gateway, and Aurora DSQL database, we used:

Managed Java 25 runtime
GraalVM Native Image deployed as Lambda Custom Runtime

We also did Lambda performance (cold and warm starts) measurements with the following settings:

Lambda functions used 1024 MB of memory
Java compilation option "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
Lambda x86_64 architecture used

In this article, we'll introduce some additional Lambda performance (cold and warm starts) optimization approaches to apply to our sample application. You'll need to measure the performance by yourself to figure out whether they will provide the desired Lambda performance improvements.

Please keep in mind that you can also deploy our sample application on AWS Lambda as a (Docker) Container Image. I didn't cover this approach, but you can look into my article series Lambda function using Docker Container Image for a step-by-step introduction on how to do it. I used DynamoDB as a database in this example. The cold start will be quite big. Lambda SnapStart isn't available for the Lambda deployment as a Container Image. Instead, you can use Ahead-of-Time (AOT) and CDS caches for the Container Image and then measure the Lambda performance.

Lambda performance optimization approaches

We can apply the following approaches to the managed Java runtime and GraalVM Native Image. For the managed Java runtime, it includes enabling SnapStart and applying the priming techniques on top:

Try out different Lambda memory settings. We performed all measurements with 1024 MB of memory for the Lambda function. With different memory settings, you might become better at the price-performance trade-off.
Try out setting Lambda arm64 architecture using AWS Graviton2 processor, which supports SnapStart since July 2024. This can provide a better cost-performance trade-off compared to x86 architecture.

We can apply the following approaches primarily only to the managed Java runtime on Lambda. This includes SnapStart being enabled and applying the priming techniques on top:

Try out different Java compilation options for the Lambda function. We performed all measurements until now with the compilation option "-XX:+TieredCompilation -XX:TieredStopAtLevel=1". We can provide other compilation options to the Lambda function using an environment variable called JAVA_TOOL_OPTIONS. This can have different cold and warm starts trade-offs. For GraalVM Native Image, the choice of Java compilation method doesn't have much impact on the Lambda performance. This is because our application is already compiled natively.
Further exclude unused dependencies. With that, we can especially reduce the cold start times (also for SnapStart enabled). In the case of GraalVM Native Image, only reachable Java classes, functions, and methods will become a part of the Native Image, so including unused dependencies may not help that much.

We can apply the following approach primarily to the managed Java runtime on Lambda with SnapStart enabled:

Search for further Lambda SnapStart priming potential in addition to those we introduced in this series. For this, you can use AWS Lambda Profiler Extension for Java. I described it in my article Improving Lambda performance with Lambda SnapStart and priming.

We can apply the following approach primarily to the GraalVM Native Image :

Try out Profile-Guided Optimizations to see whether you can further improve Lambda performance. The difficulty of trying out this technique is that you'll need to do some additional semi-automated steps to run your application either with the Lambda emulator locally or in an extra environment to obtain the profile of your application, which you'll then need to use to generate the optimized Native Image. You can use Lambda extension for it, but it still requires a lot of additional work. This is the work AWS did for us in case Lambda SnapStart is enabled. I really appreciate that I don't need to care about generating, encrypting, storing, and restoring the snapshots/profiles.

Conclusion

In this article, we introduced additional Lambda performance optimization approaches that we can use in our sample application. Try them out on your own to figure out whether they will provide the desired Lambda performance improvements.

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 7 Lambda performance optimization approaches

Vadym Kazulkin — Tue, 09 Jun 2026 15:04:06 +0000

Introduction

In the previous articles of the series about how to develop, run, and optimize Serverless applications on AWS with Lambda using Java 25, API Gateway, and DynamoDB, we used:

Managed Java 25 runtime
GraalVM Native Image deployed as Lambda Custom Runtime

We also did Lambda performance (cold and warm starts) measurements with the following settings:

Lambda functions used 1024 MB of memory
Java compilation option "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
Lambda x86_64 architecture used
Default Apache HTTP Client (version 4.5) used to connect to the DynamoDB

Please keep in mind that you can also deploy our sample application on AWS Lambda as a (Docker) Container Image. I didn't cover this approach, but you can look into my article series Lambda function using Docker Container Image for a step-by-step introduction on how to do it. The cold start will be quite big. Lambda SnapStart isn't available for the Lambda deployment as a Container Image. Instead, you can use Ahead-of-Time (AOT) and CDS caches for the Container Image and then measure the Lambda performance.

Lambda performance optimization approaches

To find a good balance between the cold and warm start times of the Lambda function, you can try out the optimization techniques introduced below. I have not taken any additional measurements with our sample application with Java and GraalVM 25, but have done so using older Java, GraalVM, and dependency versions. I'll provide references to my relevant articles. Measurements that I did back then might already be outdated, so I strongly recommend you to re-measure.

We can apply the following approaches to the managed Java runtime and GraalVM Native Image. For the managed Java runtime, it includes enabling SnapStart and applying the priming techniques on top:

Try out different Lambda memory settings. We performed all measurements with 1024 MB of memory for the Lambda function. With different memory settings, you might become better at the price-performance trade-off. See my article Measuring cold and warm starts and deployment time with Java 21 using different Lambda memory settings for further examples, performance measurements, and conclusions.
Try out setting Lambda arm64 architecture using the AWS Graviton2 processor, which supports SnapStart since July 2024. This can provide a better cost-performance trade-off compared to x86 architecture. See my article AWS Lambda performance with Java 21: x86 vs arm64 - Initial measurements for some insights.
Try out different synchronous HTTP clients to establish an HTTP connection to DynamoDB. We performed all measurements until now with the default synchronous Apache HTTP Client version 4.5. There are other options like UrlConnection and AWS CRT HTTP clients, which provide different performance trade-offs for the cold and warm start. See my article Measuring cold and warm starts with Java 21 using different synchronous HTTP clients for further examples, performance measurements, and conclusions. GraalVM Native Image also supports the AWS CRT HTTP Client, and I did some measurements using a pure Java Lambda function in my article Measuring cold and warm starts with GraalVM 23 and AWS CRT HTTP Client. Recently, also Apache 5.x based HTTP client has been released, so you can try it out.
Explore whether an asynchronous HTTP client for DynamoDB is an option for your use case. The default asynchronous HTTP Client is NettyNio. There is another option, the AWS CRT async HTTP client, which provides different performance trade-offs for the cold and warm starts. See my article Measuring cold and warm starts with Java 21 using different asynchronous HTTP clients for further examples, performance measurements, and conclusions.

We can apply the following approaches primarily only to the managed Java runtime on Lambda. This includes SnapStart being enabled and applying the priming techniques on top:

Try out different Java compilation options for the Lambda function. We performed all measurements until now with the compilation option "-XX:+TieredCompilation -XX:TieredStopAtLevel=1". We can provide other compilation options to the Lambda function using an environment variable called JAVA_TOOL_OPTIONS. This can have different cold and warm starts trade-offs. See my article Measuring cold and warm starts with Java 21 using different compilation options for further examples, performance measurements, and conclusions. For GraalVM Native Image, the choice of Java compilation method doesn't have much impact on the Lambda performance. This is because our application is already compiled natively.
Further exclude unused dependencies. With that, we can especially reduce the cold start times (also for SnapStart enabled); see my article Measuring cold starts with Java 21 using different deployment artifact sizes. In the case of GraalVM Native Image, only reachable Java classes, functions, and methods will become a part of the Native Image, so including unused dependencies may not help that much.

We can apply the following approach primarily to the managed Java runtime on Lambda with SnapStart enabled:

Search for further Lambda SnapStart priming potential in addition to those we introduced in this series. For this, you can use AWS Lambda Profiler Extension for Java. I described it in my article Improving Lambda performance with Lambda SnapStart and priming.

We can apply the following approach primarily to the GraalVM Native Image :

Try out Profile-Guided Optimizations to see whether you can further improve Lambda performance. The difficulty of trying out this technique is that you'll need to do some additional semi-automated steps to run your application either with the Lambda emulator locally or in an extra environment to obtain the profile of your application, which you'll then need to use to generate the optimized Native Image. You can use Lambda extension for it, but it still requires a lot of additional work. This is the work AWS did for us in case Lambda SnapStart is enabled. I really appreciate that I don't need to care about generating, encrypting, storing, and restoring the snapshots/profiles.

Conclusion

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.