DEV Community: Vadym Kazulkin

Serverless applications on AWS with Lambda using Java 25, API Gateway and Aurora DSQL - Part 8 Using Container Image

Vadym Kazulkin — Mon, 19 Oct 2026 15:00:00 +0000

Introduction

Several years ago, I wrote an article series Lambda function using Docker Container Image, where I explained how to convert an application deployed on AWS Lambda as a managed Java runtime to one deployed on AWS Lambda as a (Docker) container image. As we saw, the cold start time of a Lambda function using a container image was quite high. Back then, no Lambda cold-start performance optimization approaches were available, such as Lambda SnapStart. This has changed recently, as AWS Lambda now supports SnapStart for container image functions. Now it's time to revisit this topic and evaluate this option. In this part of the series, we'll refresh our knowledge about how to convert the sample application to one using a container image as a deployment artifact on AWS Lambda and measure the performance of the Lambda functions.

In the next part, we'll enable SnapStart on the Lambda functions as we did in part 3. We'll also apply the same priming techniques that we applied in parts 4-5 of this series. Of course, we'll measure the performance of the Lambda functions for all scenarios.

Sample application with JDBC and Hikari connection pool using a Container Image

You can find the final version of our sample application in the aws-lambda-java-25-aurora-dsql-as-container-image GitHub repository, which we can deploy on AWS Lambda as a container image. Let's go through the changes that we had to make to our application from part 1. First of all, we need to define a Dockerfile:

FROM public.ecr.aws/lambda/java:25

COPY target/aws-lambda-java-25-with-aurora-dsql-as-container-image-*.jar ${LAMBDA_TASK_ROOT}/lib/

Here we use the AWS Lambda base Docker image public.ecr.aws/lambda/java:25 for Java 25 from the public Amazon ECR repository. Here you can find all Lambda base Docker images for Java provided by AWS. In the Docker image, we also copy the application's code packaged as a JAR file to the path of our Lambda function code. This path is defined as the runtime environment variable LAMBDA_TASK_ROOT.

Next, let's answer the question of how to create and push a Docker container image to the ECR repository. You can do it automatically when you execute sam build, and sam deploy command chain, or if you build and package the application outside of SAM and only deploy with SAM, you need to do it manually, like this:

# Build and package your application

mvn clean package

# Build Docker image with name aws-lambda-java-25-aurora-dsql:

sudo docker build --no-cache -t aws-lambda-java-25-aurora-dsql:v1 .

# Log in to Amazon ECR in case the credentials have expired:

aws ecr get-login-password --region {aws_region} | sudo docker login --username AWS --password-stdin {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com  

# Create Amazon ECR repository if it does not exist with the name aws-lambda-java-25-aurora-dsql:

aws ecr create-repository --repository-name aws-lambda-java-25-aurora-dsql --image-scanning-configuration scanOnPush=true --region {aws_region}

# Tag our local Docker image and link it with the Amazon ECR repository. 
# Exactly this image is referenced as ImageUri in the Lambda function:

sudo docker tag aws-lambda-java-25-aurora-dsql:v1 {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-aurora-dsql:v1

# Push the Docker image to the Amazon ECR repository:

sudo docker push {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-aurora-dsql:v1

Please replace the values of the variables {aws_account_id} and {aws_region} with your own values. If you build a version (image tag) other than v1, please replace the version reference as well.

You can find all other changes in the AWS SAM template. Instead of defining Runtime (as Java 25), CodeUri, and Handler parameters, we have to define the following for all Lambda functions:

GetProductByIdFunction:
  Type: AWS::Serverless::Function
  Properties:
    FunctionName: GetProductByIdJava25WithDSQLAsCI
    PackageType: Image
    ImageUri: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/aws-lambda-java-25-aurora-dsql:v1
    ImageConfig:
      Command: [ "software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest" ]

First, we set the PackageType to Image and point the ImageURI to the ECR function's code in the ECR repository. We created the repository with the name aws-lambda-java-25-aurora-dsql above. Please pay attention to the version (image tag). We use v1 here, but you can use latest instead. Then, in the ImageConfig, we define the Command property, which is specific to each Lambda function and should point to the function's handler. For a function defined as a container image, Lambda resolves the image tag to an image digest. In Amazon ECR, if you update the image tag to a new image, Lambda does not automatically update the function. You need to use update-function-code instead.

Finally, to deploy our application, we need to invoke sam deploy --image-repository {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-aurora-dsql command.

Please note that SnapStart charges apply to the container images, while SnapStart for supported Java managed versions remains free on AWS Lambda.

Measurements of cold and warm start times of our application using a Container Image

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

We designed the experiment exactly as described in part 2.

The deployed artifact size of the container image of this application was 141.63 MB.

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

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Container Image	1886	2047	2218	2568	2628	2629	4.90	5.24	5.63	8.00	131.40	380

Sample application with Hibernate and Hikari connection pool using a Container Image

Overall, we need to apply the same steps as described above. You can find the final version of our sample application in the aws-lambda-java-25-hibernate-aurora-dsql-as-container-image GitHub repository, which we can deploy on AWS Lambda as a container image. Lastly, the biggest difference is the ECR repository name, which is aws-lambda-java-25-hibernate-and-aurora-dsql.

Measurements of cold and warm start times of our application using a Container Image

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

We designed the experiment exactly as described in part 2.

The deployed artifact size of the container image of this application was 164.32 MB.

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

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Container Image	3971	4150	4229	4660	4914	4914	5.46	5.86	6.30	8.20	203	398

Conclusion

In the next part, we'll enable SnapStart on the Lambda functions using a container image. We'll also apply priming techniques and measure the performance of the Lambda functions for all scenarios.

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 8 Using Container Image

Vadym Kazulkin — Mon, 12 Oct 2026 15:00:00 +0000

Introduction

Sample application using a Container Image

You can find the final version of our sample application in the aws-lambda-java-25-dynamodb-as-container-image GitHub repository, which we can deploy on AWS Lambda as a container image. Let's go through the changes that we had to make to our application from part 1. First of all, we need to define a Dockerfile:

FROM public.ecr.aws/lambda/java:25

COPY target/aws-lambda-java-25-with-dynamodb-as-container-image-*.jar ${LAMBDA_TASK_ROOT}/lib/

# Build and package your application

mvn clean package

# Build Docker image with name aws-lambda-java-25-with-dynamodb:

sudo docker build --no-cache -t aws-lambda-java-25-with-dynamodb:v1 .

# Log in to Amazon ECR in case the credentials have expired:

aws ecr get-login-password --region {aws_region} | sudo docker login --username AWS --password-stdin {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com  

# Create Amazon ECR repository if it does not exist with the name aws-lambda-java-25-with-dynamodb:

aws ecr create-repository --repository-name aws-lambda-java-25-with-dynamodb --image-scanning-configuration scanOnPush=true --region {aws_region}

# Tag our local Docker image and link it with the Amazon ECR repository. 
# Exactly this image is referenced as ImageUri in the Lambda function:

sudo docker tag aws-lambda-java-25-with-dynamodb:v1 {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-with-dynamodb:v1

# Push the Docker image to the Amazon ECR repository:

sudo docker push {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-with-dynamodb:v1

Please replace the values of the variables {aws_account_id} and {aws_region} with your own values. If you build a version (image tag) other than v1, please replace the version reference as well.

You can find all other changes in the AWS SAM template. Instead of defining Runtime (as Java 25), CodeUri, and Handler parameters, we have to define the following for all Lambda functions:

GetProductByIdFunction:
  Type: AWS::Serverless::Function
  Properties:
    FunctionName: GetProductByIdJava25WithDynamoDBAsCI
    PackageType: Image
    ImageUri: !Sub ${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/aws-lambda-java-25-with-dynamodb:v1
    ImageConfig:
      Command: [ "software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest" ]

First, we set the PackageType to Image and point the ImageURI to the ECR function's code in the ECR repository. We created the repository with the name aws-lambda-java-25-with-dynamodb above. Please pay attention to the version (image tag). We use v1 here, but you can use latest instead. Then, in the ImageConfig, we define the Command property, which is specific to each Lambda function and should point to the function's handler. For a function defined as a container image, Lambda resolves the image tag to an image digest. In Amazon ECR, if you update the image tag to a new image, Lambda does not automatically update the function. You need to use update-function-code instead.

To deploy our application, we need to invoke sam deploy --image-repository {aws_account_id}.dkr.ecr.{aws_region}.amazonaws.com/aws-lambda-java-25-with-dynamodb command.

Please note that SnapStart charges apply to the container images, while SnapStart for supported Java managed versions remains free on AWS Lambda.

Measurements of cold and warm start times of our application using a Container Image

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

We designed the experiment exactly as described in part 2.

The deployed artifact size of the container image of this application was 138.53 MB.

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

Approach	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
Lambda Container Image	2788	2884	3063	3374	3456	3460	5.25	5.73	6.30	9.46	56.82	1481

Conclusion

In this part of the series, we learned how to convert the sample application to one using a container image as a deployment artifact on AWS Lambda and measured the performance of the Lambda functions. We observed that the Lambda cold start times are quite high. But there is a noticeable improvement compared to my last measurements, which I did with Java 21. I refer to the article that describes AWS efforts to reduce container cold start times in general.

In the next part, we'll enable SnapStart on the Lambda functions using a container image. We'll also apply priming techniques and measure the performance of the Lambda functions for all scenarios.

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.

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 8 AI Agents with Spring AI on AgentCore Runtime

Vadym Kazulkin — Mon, 05 Oct 2026 14:30:00 +0000

Introduction

In part 7, we transformed our application into an agentic one. We replaced the search for YouTube and upcoming talks with the AgentCore Gateway Web Search Tool. Also, we used the Spring AI framework to implement the AI agent and AWS Lambda to host it. This might be sufficient for very simple agents, as AWS Lambda has its limitations of a 15-minute execution duration and isn't very efficient for agents spending a lot of time waiting on I/O.

In this part of the series, we'll show how to host those AI agents on the Amazon Bedrock AgentCore Runtime instead. AgentCore Runtime provides a secure, serverless, and purpose-built hosting environment for deploying and running AI agents or tools. I wrote an article series about AgentCore Runtime, which I refer to.

There are multiple good articles that highlight the difference between hosting the agents on AWS Lambda vs Amazon Bedrock AgentCore Runtime:

Sample application using AgentCore Gateway Web Search Tool and Spring AI hosted on Amazon Bedrock AgentCore Runtime

The target architecture of our sample application looks like this:

Instead of hosting the AI Agents for searching for upcoming talks and YouTube videos in the Lambda function, we bundle them and deploy them together on AgentCore Runtime. We expose this agent via the HTTP protocol. In this case, bundling agents works fine. It's because we can parameterize our prompt to instruct the agent to search either for upcoming talks or for YouTube videos. There are cases where it's beneficial to have different agents and host them separately (on AgentCore Runtime). We still use a Lambda function per agent to invoke our agent hosted on AgentCore Runtime, using the AWS Java SDK.

You can find the final version of the application in my aws-s3-files-lambda-durable-functions-as-ai-agents-orchestrator-java-25 repository.

Here we find the following subdirectories:

The agent implementation. It contains the same business logic that we described in part 7, but now it's a pure Spring Boot application. It should be dockerized to be deployed on AgentCore Runtime. I gave a detailed explanation of how to do it in my article Building AI Agents with Spring AI and Amazon Bedrock AgentCore – Part 5 Deploy MCP client for Conference application on AgentCore Runtime.
The Infrastructure as Code based on AWS CDK for Java. We covered it partially in part 7. In addition to AgentCore Gateway and Cognito stack, we now have to create AgentCore Runtime stack. I also refer to my article Deploy MCP client for Conference application on AgentCore Runtime for the detailed explanation of this step. After AgentCore Runtime is created, we have to grab its Runtime ARN. We'll see it in the console output, or we can find it on the AWS AgentCore Runtime service page.
The Agent orchestrator implementation with AWS Lambda durable function. The biggest difference to the business logic from part 7 is the implementation of the UpcomingTalksExtractor and YouTubeVideosExtractor Lambda functions. They both inherit from the BaseContentExtractor, which provides the search method both Lambda functions use:

   default public <T> T search(Author author, String searchTopic, 
     int maxNumberOfResults, Class<T> clazz)  throws Exception {
       var payload = """
           {
    "prompt":"Do a web search for the %s authored by %s %s. Provide maximum %d results. Your response should be in JSON format. Do not include any explanations, only provide a RFC8259 compliant JSON response following this format without deviation.",
    "resultType": "%s"
           }
       """.formatted(searchTopic, author.firstName(), author.lastName()
       , maxNumberOfResults, clazz.getName());

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

     var bedrockAgentCoreClient = BedrockAgentCoreClient.builder()               
         .region(Region.of(System.getenv("REGION")))
         .httpClient(httpClient)
         .build();

     var AGENT_RUNTIME_ARN= System.getenv("AGENTCORE_RUNTIME_ARN");

     var invokeAgentRuntimeRequest = InvokeAgentRuntimeRequest.builder()
          .agentRuntimeArn(AGENT_RUNTIME_ARN)                                          
          .qualifier("DEFAULT")
          .contentType("application/json")
          .payload(SdkBytes.fromUtf8String(payload))
          .build();

     try (var responseStream = bedrockAgentCoreClient.invokeAgentRuntime(invokeAgentRuntimeRequest)) {

      var response = new String(responseStream.readAllBytes(), StandardCharsets.UTF_8);
      return OBJECT_MAPPER.readValue(response, clazz);
     }
}

First, we parameterize the prompt by providing:

the search topic (YouTube videos or upcoming talks)
content author first and last name
maximum number of results
the result type (YouTubeVideos.class or UpcomingTalks.class depending on the search topic).

Next, we use the AWS Java SDK to create an InvokeAgentRuntimeRequest with the constructed prompt and AgentCore Runtime ARN, which we retrieve from an environment variable AGENTCORE_RUNTIME_ARN. We set the value of this variable in the AWS SAM template. This value should correspond to the Runtime ARN we created in the IaC part described earlier. Here is an example of how to do it for the YouTubeVideosExtractorFunction Lambda function:

 YouTubeVideosExtractorFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: YouTubeVideosAIAgentExtractor
      Handler: dev.vkazulkin.handler.YouTubeVideosExtractor::handleRequest
      Environment:
        Variables:
          AGENTCORE_RUNTIME_ARN: !Sub arn:aws:bedrock-agentcore:${AWS::Region}:${AWS::AccountId}:runtime/RuntimeForAuthorContentAgenticSearch-LBaMJZGabnk
      Policies:
          - Version: '2012-10-17'
            Statement:
              - Sid: InvokeRuntime
                Effect: Allow
                Action:
                  - bedrock-agentcore:*Runtime*
                  - bedrock-agentcore:*WorkloadIdentity
                  - bedrock-agentcore:*CredentialProvider
                  - bedrock-agentcore:*Token*
                  - bedrock-agentcore:*Access*
                Resource: 'arn:aws:bedrock-agentcore:*:*:*runtime*'

We also need to give this Lambda function permissions to invoke the AgentCore Runtime. We have to do the same for the UpcomingTalksExtractorFunction Lambda function as well. After that, create a BedrockAgentCoreClient client to execute this request. Lastly, we convert an LLM response in JSON format to the specified result type and return it.

Once again, I gave a detailed explanation of this step in my article Deploy MCP client for Conference application on AgentCore Runtime.

Building, packaging, deploying, and testing our sample application

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. Please follow the steps from part 7 to test the application, as they are exactly the same. Our Lambda durable function executes exactly the same steps, so the output will be the same. The only difference is that I renamed the Lambda Durable function in this project to AuthorContentExtractorAIAgentsOrchestrator.

Conclusion

In this part of the series, we showed how to host AI agents, which our Lambda durable function orchestrates, on the AgentCore Runtime.

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

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

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 7 AI Agents with Spring AI and AgentCore on AWS Lambda

Vadym Kazulkin — Mon, 28 Sep 2026 14:30:00 +0000

Introduction

In part 6 of the series, we moved the logic associated with each step into a separate Lambda function. We explored how to invoke another Lambda function within the durable step. Also, we showed how to invoke multiple Lambda functions in parallel.

In this article, we'll transform our application into an agentic one. Currently, the search for YouTube and upcoming talks returns static content. We'll replace it with the Amazon Bedrock AgentCore Gateway Web Search Tool. As it's exposed via MCP, we need an MCP client to connect to it. For that, we'll use the Spring AI framework. First, we still use AWS Lambda to host the AI agents. In later parts, we'll show how to host those AI agents on Amazon Bedrock AgentCore Runtime instead.

The question is whether it'd be appropriate to host our AI agents on AWS Lambda. Our agents are really simple and return a constant amount of data. They also have a nearly constant context size. We don't need the flexibility of Firecracker, including the ability to grow and shrink the CPU and memory usage of VMs in place. Also, our agents are stateless, so we don't need the AgentCore support of stateful streamable-HTTP MCP servers. For such agents, it's feasible to host them on AWS Lambda.

Introduction to Spring AI framework

I've written an entire article series on the Spring AI framework and have also heavily used this framework in my article series Building AI Agents with Spring AI and Amazon Bedrock AgentCore. I refer to them to understand the basics. Spring AI is based on Spring Boot, but we have pure Lambda functions in our application instead. So, we need to have a Spring context to use Spring AI. How can we achieve it?

How to convert AWS Lambda to a Spring (Boot) Application

I've written another article series about Spring Boot 3.4 applications on AWS Lambda where I introduced 3 approaches to convert AWS Lambda to a Spring (Boot) Application :

In this article, I'll go for AWS Serverless Java Container for Spring Boot.

Sample application using AgentCore Gateway Web Search Tool and Spring AI hosted on AWS Lambda

The target architecture of our sample application looks like this:

I first copied the application that we created in part 6 into the aws-s3-files-lambda-durable-functions-spring-ai-agentcore-gateway-web-search-tool repository. We explain step by step how to adjust our application. Please go through the content of part 6 to understand the sample application and the basic concepts of Lambda durable functions. There will be some changes in the Infrastructure as Code (IaC) part as well.

First, let's import some important dependencies in the pom.xml. Those include:

aws-serverless-java-container-springboot4 (to use AWS Serverless Java Spring Boot 4 Container)
spring-ai-starter-mcp-client (to use Spring AI MCP Client)
spring-ai-starter-model-bedrock-converse (to use Spring AI Bedrock Converse API)
others

Next, let's create the Spring Boot AuthorContentWebSearchExtractorController controller:

@RestController
public class AuthorContentWebSearchExtractorController { 
...

    @RequestMapping(path = "/author/content/youtubeVideos", method = RequestMethod.GET, 
   consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
    public YouTubeVideos searchForYouTubeVideos(@RequestBody Author author) {
        return this.webSearch(author,"YouTube videos", 3 ,YouTubeVideos.class);
    }


   @RequestMapping(path = "/author/content/upcomingTalks", method = RequestMethod.GET, 
   consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
    public UpcomingTalks searchForUpcomingTalks(@RequestBody Author author) {
        return this.webSearch(author, "upcoming talks", 3, UpcomingTalks.class);
    }
....

Here we define 2 (web search) GET methods, searchForYouTubeVideos and searchForUpcomingTalks, with the specified path and incoming and outgoing media types. They both receive the JSON representation of the Author class in their HTTP body. We can also modify our application to receive first and last name as request parameters. For this, we also need to adjust both paths, for example, to /author/content/upcomingTalks/{firstname}/{lastname}. We'll take care of the implementation of the websearch method later.

The controller is a standard Spring Boot controller where we have access to the whole Spring Boot (web) functionality.

Our Lambda durable function AuthorContentExtractor looks very similar to the function we defined in part 6. Here we invoke in parallel 2 Lambda functions: UpcomingTalksWebSearchExtractor and YouTubeVideosWebSearchExtractor. We'll transform exactly those 2 functions, so they perform the agentic search for the content instead of returning the static one. When we invoke them, we pass an object of type Author as a payload. Our Lambda durable function AuthorContentExtractor receives this payload as its input.

The question is how to transform this payload into the HTTP requests which 2 methods of the AuthorContentWebSearchExtractorController receive. This is exactly the functionality that AWS Serverless Java Spring Boot 4 Container provides to us. This framework does this transformation automatically in case the input payload comes from Amazon API Gateway. The payload should be of either type APIGatewayProxyRequestEvent (REST API) or type APIGatewayV2HTTPEvent (HTTP API). For more information, please read the Invoking a Lambda function using an Amazon API Gateway endpoint article. In such a case, we can use the generic Lambda handler com.amazonaws.serverless.proxy.spring.SpringDelegatingLambdaContainerHandler to do the job. Nevertheless, AWS Serverless Java Spring Boot 4 Container offers the functionality to convert and proxy any request to one described above. In our sample application, we'll use the APIGatewayProxyRequestEvent request event. Let's explain how to do it.

Both Lambda functions, UpcomingTalksWebSearchExtractor and YouTubeVideosWebSearchExtractor.java, recieve the input request of type Author. The only difference is that they should convert this request into an APIGatewayProxyRequestEvent request event and proxy it to different paths. We define those paths in the Lambda function itself.

For the UpcomingTalksWebSearchExtractor Lambda function, it looks like this:

public class UpcomingTalksWebSearchExtractor extends AuthorContentWebSearchExtractor {

@Override
protected String getPath() {
    return "/author/content/upcomingTalks";
   }
}

The path /author/content/upcomingTalks exactly matches the path of the request mapping in the controller:

   @RequestMapping(path = "/author/content/upcomingTalks", method = RequestMethod.GET, 
   consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
    public UpcomingTalks searchForUpcomingTalks(@RequestBody Author author) {
        return this.webSearch(author, "upcoming talks", 3, UpcomingTalks.class);
    }

So this Lambda function will proxy the incoming request to the controller's searchForUpcomingTalks method.

For the YouTubeVideosWebSearchExtractor Lambda function, it looks like this:

public class YouTubeVideosWebSearchExtractor extends AuthorContentWebSearchExtractor {

@Override
protected String getPath() {
    return "/author/content/youtubeVideos";
   }
}

The path /author/content/youtubeVideos exactly matches the path of the request mapping in the controller:

    @RequestMapping(path = "/author/content/youtubeVideos", method = RequestMethod.GET, 
   consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
    public YouTubeVideos searchForYouTubeVideos(@RequestBody Author author) {

    return this.webSearch(author,"YouTube videos", 3 ,YouTubeVideos.class);
    }

So this Lambda function will proxy the incoming request to the controller's searchForYouTubeVideos method.

The generic business logic that performs the conversion is in the AuthorContentWebSearchExtractor class:

abstract class AuthorContentWebSearchExtractor implements RequestStreamHandler {

private static SpringBootLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler = 
SpringBootLambdaContainerHandler.getAwsProxyHandler(Application.class)

@Override
public void handleRequest(InputStream inputStream, 
  OutputStream outputStream, Context context) throws IOException {
    var author = new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);
    var proxyRequestEvent = this.getAwsProxyRequest(author);
    var response = handler.proxy(proxyRequestEvent, context);
    var body = response.getBody();
    try (var printStream = new PrintStream(outputStream, 
        true, StandardCharsets.UTF_8)) {
            printStream.print(body);
        }
    }

private AwsProxyRequest getAwsProxyRequest (String author) {
    var awsProxyRequest = new AwsProxyRequest ();
    awsProxyRequest.setHttpMethod("GET");
    awsProxyRequest.setPath(this.getPath());
    awsProxyRequest.setBody(author);

    var header= new SingleValueHeaders();
    header.put("Content-Type", "application/json");
    awsProxyRequest.setHeaders(header);

    var headers= new Headers();
    headers.add("Content-Type", "application/json");
    awsProxyRequest.setMultiValueHeaders(headers);

    var awsProxyRequestContext = new AwsProxyRequestContext();
    var apiGatewayRequestIdentity= new ApiGatewayRequestIdentity();
    apiGatewayRequestIdentity.setApiKey("blabla");
    awsProxyRequestContext.setIdentity(apiGatewayRequestIdentity);
    awsProxyRequest.setRequestContext(awsProxyRequestContext);

    return awsProxyRequest;        
}

 protected abstract String getPath();
}

Let's go step by step through the code. As we see, our class implements the RequestStreamHandler class. First, we instantiate the SpringBootLambdaContainerHandler handler with the proxy request and response type and the main entry point of the Spring Boot Application class. In the handleRequest method, we convert the input stream into a JSON representation of the Author object. We use it in the getAwsProxyRequest method to create the AwsProxyRequest object, which represents the APIGatewayProxyRequestEvent request event. To do so, we set several properties:

HTTP Method as GET (should be the same as the HTTP method of both controllers' methods).
path (each of the 2 Lambda functions sets its own path as described above).
HTTP body (we set the Author object) as required by the 2 Lambda functions.
header and multi-value headers with the content type of application/json.
some dummy settings for request content and API Gateway request identity. It leads to an error if we don't set them.

After having created the AwsProxyRequest object, we use the handler to proxy it. By doing so, the appropriate method of the AuthorContentWebSearchExtractorController will be invoked. As a result, we get an object of the type AwsProxyResponse, which contains the response of the controller's method. This response is either of type UpcomingTalks or of type YouTubeVideos depending on the method invoked. We get this response by invoking the body method, and then we inject it into the output stream. With that, our Lambda durable function receives the response of the Lambda invocation.

Now let's implement the webSearch method of the controller. This method implements the web search for the given author content (either upcoming talks or YouTube videos) using the Amazon Bedrock AgentCore Gateway Web Search Tool.

Introduction to the Amazon Bedrock AgentCore Gateway Web Search Tool

AI agents are transforming how organizations interact with information, but they face a fundamental limitation: their knowledge is frozen at training time. When a user asks about today’s stock prices or a software release that shipped an hour ago, an agent relying solely on its training data cannot provide accurate answers.

Building custom web search integrations to solve this is costly — procuring third-party search APIs, managing keys and quotas and rate limits, parsing inconsistent result formats across providers, building snippet extraction logic so models get relevant passages instead of raw HTML, reasoning about where customer queries travel and how data might be retained, and maintaining freshness and coverage over time. Each of these is a project in itself.

Web Search Tool on Amazon Bedrock AgentCore eliminates that complexity. It is a fully managed, MCP-compliant web search capability that lets your agents retrieve information from the web without any infrastructure overhead. It is available as a managed connector that you connect to your AgentCore Gateway. Agents discover it with a standard tools/list call and invoke it like any other Model Context Protocol tool. There are no search APIs to provision, no outbound credentials to manage, and no result-parsing glue to maintain.

How to set up the Amazon Bedrock AgentCore Gateway Web Search Tool

I refer to the article Introducing Web Search on Amazon Bedrock AgentCore, which describes everything you need to set it up. Currently, there is no IaC CDK support for the Web Search Tool, but setting it up manually takes minutes.

As a small help, I provided the spring-ai-2.0-ai-agents-on-agentcore-runtime/cdk repository that uses AWS CDK in Java. Please execute the Cognio and Gateway stacks. Then, manually add a Gateway MCP Target with the Web Search tool connector as shown in the pictures above.

The created Bedrock AgentCore Gateway should look similar to this one:

We'll need the Gateway Resource ARN and Gateway Resource URL later. Then we need to create the AgentCore Target by selecting the MCP Target and Web Search tool in the Connectors section:

We'll need to define an IAM role with the following policy, as described in the article above:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "InvokeWebSearchTool",
            "Effect": "Allow",
            "Action": "bedrock-agentcore:InvokeWebSearch",
            "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1"
        },
        {
            "Sid": "InvokeGateway",
            "Effect": "Allow",
            "Action": "bedrock-agentcore:InvokeGateway",
            "Resource": "{YOUR_AGENTCORE_GATEWAY_ARN}"
        }
    ]
}

Please replace the {YOUR_AGENTCORE_GATEWAY_ARN} with the ARN of your created AgentCore Gateway.

Another question is how to set up the inbound authorization of our AgentCore Gateway. We can put it completely public, which is not recommended. Another alternative is to use IAM-based inbound authorization. In this article, we'll use JSON Web Token (JWT)-based inbound authorization with Amazon Cognito as an identity provider as we see in the picture above. I won't go into the details of how to create and configure the Cognito User (Client) Pool, but refer to my following articles:

Deploy Conference Search application on AgentCore Runtime. Here I provided IaC and an explanation of how to create the Cognito User (Client) Pool.
Provide MCP tools for Conference application via AgentCore Gateway. Here I provided IaC and an explanation of how to configure the inbound authorization for the AgentCore Gateway with Amazon Cognito as an identity provider.

Alternatively, please look into the Cognito and Gateway stack of the spring-ai-2.0-ai-agents-on-agentcore-runtime/cdk repository for an example of how to set it up.

How to implement the Amazon Bedrock AgentCore Gateway Web Search Tool using Spring AI

I've already covered how to talk to an LLM and use the MCP Client to connect to tools with Spring AI in my following articles:

Please go through those articles first to understand the basics, as we'll reuse much of the business logic. Let's first configure the AgentCore Gateway resource URL and Cognito settings in the application.properties file:

amazon.bedrock.agentcore.gateway.base.url=https://web-search-gateway-XXX.gateway.bedrock-agentcore.us-east-1.amazonaws.com
amazon.bedrock.agentcore.gateway.endpoint=/mcp

cognito.user.pool.name=UserPoolForAuthorContentAgenticSearch
cognito.user.pool.client.name=UserClientPoolForAuthorContentAgenticSearch
cognito.auth.token.resource.server.id=ResourceServerIdAuthorContentAgenticSearch

Please split this URL into 2 parts: the base URL and the endpoint, which is always /mcp.

The implementation of the webSearch method in the AuthorContentWebSearchExtractorController controller looks like this:

private <T> T webSearch(Author author, String searchTopic, 
   int maxNumberOfResults, Class<T> clazz) {

    var token = getAuthTokenViaHttpClient();
    try (var client = McpClient.sync(getMcpClientTransport(token)).build()) {
         client.initialize();
         client.listTools().tools().forEach
             (tool -> LOGGER.info("tool found: " + tool));

          var mcpToolCallbackProvider = SyncMcpToolCallbackProvider.builder()
              .mcpClients(client)
              .build();

       var prompt = """
            Search for the %s given by %s %s. Provide maximum %d results.
            Your response should be in JSON format.
            Do not include any explanations, only provide a RFC8259 compliant JSON response 
            following this format without deviation.
            """.formatted(searchTopic, author.firstName(), author.lastName(), maxNumberOfResults);

       return this.chatClient.prompt().user(prompt)
                    .tools(mcpToolCallbackProvider.getToolCallbacks())
                    .call()
                    .entity(clazz);
    }
}

This is a generic method, which takes the following parameters:

object of type Author.
search topic ("search for upcoming talks" or "search for YouTube videos" in our case)
maximum number of results returned by the Web Search tool. Valid range: 1-25. Defaults to 10.
result type (UpcomingTalks or YouTubeVideos in our case)

First, get the authentication token from Amazon Cognito. We can remove this part, including setting this token in the header of the HTTP Streamable Client, in case our AgentCore isn't secured by the JWT (either public or we use IAM authorization). Next, we create the MCP client and initialize it. After that, we list the MCP tools available; in our case, only the WebSearch tool. Then, we create MCPToolCallbackProvider with the MCP client. Next, we construct the parametrized prompt by passing the author, the search topic, and the number of results. We also advise an LLM to return the response in JSON format, which our Lambda functions require.

Finally, we use the ChatClient from Spring AI to pass the prompt, the tools, and the result type. We implement the last one by using the entity method, which tries to provide the structured LLM output. Once again, for more details about this code, I refer to my articles mentioned above. We invoke the websearch method from the controller's methods searchForUpcomingTalks and searchForYouTubeVideos with different parameters.

IaC for the sample application using AgentCore Gateway Web Search Tool and Spring AI hosted on AWS Lambda

The IaC part in the AWS SAM Template matches what we described in part 6. There are, of course, some differences, as we need to give our 2 Lambda functions, which implement the AI agents, more permissions. We need these permissions to grant those Lambda functions access to the Cognito, AgentCore, and Bedrock services. Here is an example of the UpcomingTalksWebSearchExtractorFunction Lambda function declaration:

UpcomingTalksWebSearchExtractorFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: UpcomingTalksWebSearchExtractor
      Handler: dev.vkazulkin.handler.UpcomingTalksWebSearchExtractor::handleRequest
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Sid: AllowedCognitoActions
              Effect: Allow
              Action:
                - cognito-idp:ListUserPools
                - cognito-idp:ListUserPoolClients
                - cognito-idp:DescribeUserPoolClient
              Resource: '*'
            - Sid: InvokeGateway
              Effect: Allow
              Action:
                - bedrock-agentcore:InvokeGateway
                - bedrock-agentcore:*WorkloadIdentity
                - bedrock-agentcore:*CredentialProvider
                - bedrock-agentcore:*Token*
                - bedrock-agentcore:*Access*
              Resource: 'arn:aws:bedrock-agentcore:*:*:*gateway*'
            - Sid: InvokeRuntime
              Effect: Allow
              Action:
                - bedrock-agentcore:*Runtime*
                - bedrock-agentcore:*WorkloadIdentity
                - bedrock-agentcore:*CredentialProvider
                - bedrock-agentcore:*Token*
                - bedrock-agentcore:*Access*
              Resource: 'arn:aws:bedrock-agentcore:*:*:*runtime*'
            - Sid: InvokeBedrock
              Effect: Allow
              Action:
                - bedrock:InvokeModel
                - bedrock:InvokeModelWithResponseStream
                - bedrock:Converse
                - bedrock:ConverseStream
              Resource: '*'
      Events:
        GetRequest:
          Type: Api
          Properties:
            RestApiId: !Ref MyApi
            Path: /author/content/upcomingTalks
            Method: get

The declaration of the YouTubeVideosWebSearchExtractorFunction Lambda function looks very similar.

Building, packaging, deploying, and testing our sample application

To test our Lambda durable function, we can navigate to the Lambda service, search for the AuthorContentWebSearchExtractor 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:

Let's also look at event history:

We see that this matches what we implemented. Our Lambda durable function invokes 2 Lambda functions in parallel to search for YouTube videos and upcoming talks (each in an individual branch). Then, it awaits the results of both invocations because we defined in the parallel configuration that we wait until all invocations are completed. Then the last Lambda function to write the author content into the file gets invoked. This process is the same as we described in part 6, as the workflows remained the same. We only changed the implementation of 2 Lambda functions responsible for the content search. Now we use the AgentCore Gateway Web Search Tool for it.

Conclusion

In this article, we transformed our application into an agentic one. We replaced the search for YouTube and upcoming talks with the AgentCore Gateway Web Search Tool. Also, we used the Spring AI framework. We used AWS Lambda to host the AI agents.

As we saw, Lambda durable functions provide a lot of building blocks like synchronous and asynchronous steps, invocation of another Lambda function, invoke async, waits, and callbacks (and combinations of both, like wait for the callback), and parallel execution to orchestrate the AI agents and multi-step workflows. We only showed one simple example of how to orchestrate the AI agent by using another Lambda function invocation and parallel execution.

In the next part, we'll show how to host those AI agents on the AgentCore Runtime instead.

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 6 Invoke a Lambda function and parallel execution

Vadym Kazulkin — Mon, 21 Sep 2026 14:00: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. After that, in parts 3, 4, and 5 of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to implement wait for callback, wait for condition, and map operations.

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 this part, we'll move the logic associated with each step into a separate Lambda function. An additional advantage of this approach is that it allows us to apply individual settings to those functions, like setting the right memory and granting the exact permissions they need. We'll explore how to invoke another Lambda function within the durable step. Also, we'll show how to invoke multiple Lambda functions in parallel.

Sample application with invoking another Lambda function and performing parallel execution

Let's explore invoking another Lambda function and parallel execution. We get access to them through DurableContext.

invoke - the invoke operation calls another Lambda function and waits for its result. It supports both durable functions and standard on-demand Lambda functions. When you call ctx.invoke() or ctx.invokeAsync(), the SDK checkpoints the start of the operation, and the durable functions backend invokes the target Lambda function. On replay, the SDK returns the checkpointed result without invoking the target again.
parallel - parallel runs multiple independent branches concurrently, each in its own child context. Branches are registered via branch() and execute immediately (respecting maxConcurrency). The operation completes when all branches finish or completion criteria are met.

I first copied the application that we created in part 2 into the aws-s3-files-lambda-durable-functions-as-orchestrator-java-25 repository. We explain step by step how to adjust our application. Please go through the content of part 2 to understand the sample application and the basic concepts of Lambda durable functions. There will be some changes in the Infrastructure as Code (IaC) part as well. I'll leave out the wait for callbacks that we implemented in part 2. You can copy this logic into the Lambda durable function orchestrator, if you will.

We'll move the business logic for 3 individual steps out of our Lambda durable function AuthorContentExtractor to 3 different Lambda functions:

The implementation of all 3 Lambda functions is trivial. We'll focus on the change in the Lambda durable function AuthorContentExtractor and in the IaC located in the AWS SAM template.

We already showed in part 2 how to execute the first 2 Lambda functions asynchronously. This time, we'll show how to execute them in parallel. Here is how the complete code of the AuthorContentExtractor Lambda durable function looks:

public class AuthorContentExtractor extends DurableHandler<Author, AuthorContent> {

private static final String UPCOMING_TALKS_EXTRACTOR_FUNCTION_ARN  = 
System.getenv("UpcomingTalksExtractorFunctionArn");
private static final String YOUTUBE_VIDEOS_EXTRACTOR_FUNCTION_ARN  =
System.getenv("YouTubeVideosExtractorFunctionArn");
private static final String WRITE_AUTHOR_CONTENT_TO_FILE_FUNCTION_ARN  =
System.getenv("WriteAuthorContentToFileFunctionArn");


@Override
public AuthorContent handleRequest(Author author, DurableContext ctx) {
  var config = ParallelConfig.builder()
      .maxConcurrency(5)
      .nestingType(NestingType.NESTED)
      .completionConfig(CompletionConfig.allCompleted())
      .build();

  var invokeConfig=InvokeConfig.builder().build();

  var parallel = ctx.parallel("parallel-search", config);

  var upcomingTalksFuture = parallel.branch("searchForUpcomingTalks-parallel-step",
      UpcomingTalks.class, branchCtx -> {
           return branchCtx.invoke("searchForUpcomingTalks-step",           
             UPCOMING_TALKS_EXTRACTOR_FUNCTION_ARN, author,
             UpcomingTalks.class, invokeConfig);
     });

  var youtubeVideosFuture = parallel.branch("searchForYouTubeVideos-parallel-step",
      YouTubeVideos.class, branchCtx -> {
      return branchCtx.invoke("searchForYouTubeVideos-step",                
             YOUTUBE_VIDEOS_EXTRACTOR_FUNCTION_ARN, author, 
             YouTubeVideos.class, invokeConfig);
    });

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

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

  ctx.invoke("writeAuthorContentToFile-step", WRITE_AUTHOR_CONTENT_TO_FILE_FUNCTION_ARN, 
    authorContent, Void.class, invokeConfig);

  return authorContent;
  }
}

Let's go step by step through the code. First, we pass the ARNs of all 3 Lambda functions via environment variables. We set those for the Lambda durable function AuthorContentExtractorFunction in the AWS SAM template. Also, we give our Lambda durable function the required permissions to invoke the other 3 Lambda functions:

  AuthorContentExtractorFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: AuthorContentExtractorOrchestrator
      Handler: dev.vkazulkin.handler.AuthorContentExtractor::handleRequest
      Environment:
        Variables:
          UpcomingTalksExtractorFunctionArn: !GetAtt UpcomingTalksExtractorFunction.Arn
          YouTubeVideosExtractorFunctionArn: !GetAtt YouTubeVideosExtractorFunction.Arn
          WriteAuthorContentToFileFunctionArn: !GetAtt WriteAuthorContentToFileFunction.Arn
      DurableConfig:
        ExecutionTimeout: 3600
        RetentionPeriodInDays: 7
      Policies:
        - Version: '2012-10-17'
          Statement:
            - Sid: InvokeLambda
              Effect: Allow
              Action: lambda:InvokeFunction
              Resource:
                  - !GetAtt YouTubeVideosExtractorFunction.Arn
                  - !Sub '${YouTubeVideosExtractorFunction.Arn}:*'
                  - !GetAtt UpcomingTalksExtractorFunction.Arn
                  - !Sub '${UpcomingTalksExtractorFunction.Arn}:*'
                  - !GetAtt WriteAuthorContentToFileFunction.Arn
                  - !Sub '${WriteAuthorContentToFileFunction.Arn}:*'
....

As we invoke UpcomingTalksExtractor and YouTubeVideosExtractor Lambda functions in parallel, we create ParallelConfig. Here we set the maximum concurrency value and nesting type. There are 2 nesting types:

Nested (the default one). Create CONTEXT operations for each branch/iteration with full checkpointing. Operations within each branch/iteration are wrapped in their own context. Observability: High - each branch/iteration appears as a separate operation in execution history. Cost: Higher - consumes more operations due to CONTEXT creation overhead. Scale: Lower maximum iterations due to operation limits
Flat. Skip CONTEXT operations for branches/iterations using virtual contexts. Operations execute directly without individual context wrapping. Observability: Lower - branches/iterations don't appear as separate operations. Cost: ~30% lower - reduces operation consumption by skipping CONTEXT overhead. Scale: Higher maximum iterations possible within operation limits

We also set the CompletionConfig. Here, there are many possibilities from which we can choose:

allCompleted (we use it). All items run regardless of failures. Failures are captured per-item.
allSuccessful. All items must succeed. Zero failures tolerated.
firstSuccessful. Complete as soon as the first item succeeds.
minSuccessful. Complete when the specified number of items have succeeded.
toleratedFailureCount. Complete when more than the specified number of failures have occurred.
toleratedFailurePercentage. Complete when the failure percentage exceeds the specified threshold (0.0 to 1.0).

Next, we create an InvocationConfig for each individual Lambda function invocation that we can optionally set. Here we go with the default configuration. But we additionally set the tenant ID, which is used to isolate execution state for different tenants. It's required when invoking multi-tenant Lambda functions. So far, we covered the following parts:

 var config = ParallelConfig.builder()
      .maxConcurrency(5)
      .nestingType(NestingType.NESTED)
      .completionConfig(CompletionConfig.allCompleted())
      .build();

  var invokeConfig=InvokeConfig.builder().build();

Next, let's implement the Lambda function invocation in parallel:

  var parallel = ctx.parallel("parallel-search", config);

  var upcomingTalksFuture = parallel.branch("searchForUpcomingTalks-parallel-step",
      UpcomingTalks.class, branchCtx -> {
           return branchCtx.invoke("searchForUpcomingTalks-step",           
             UPCOMING_TALKS_EXTRACTOR_FUNCTION_ARN, author,
             UpcomingTalks.class, invokeConfig);
     });

  var youtubeVideosFuture = parallel.branch("searchForYouTubeVideos-parallel-step",
      YouTubeVideos.class, branchCtx -> {
      return branchCtx.invoke("searchForYouTubeVideos-step",                
             YOUTUBE_VIDEOS_EXTRACTOR_FUNCTION_ARN, author, 
             YouTubeVideos.class, invokeConfig);
    });

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

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

First, we invoke the parallel method on the DurableContext and pass the ParallelConfig. We get back the ParallelDurableFuture, with which we can start a branch. To do this, we invoke the branch method for each individual Lambda invocation and specify the result type. In each branch, we call the invoke method on the BranchContext. Here we pass the following parameters:

name - the unique operation name within this context.
functionName - the ARN or name of the Lambda function to invoke.
payload - the input payload to send to the target function.
resultType - the result class for deserialization.

We get back the DurableFuture of the resultType (in our case UpcomingTalks or YouTubeVideos).

When we invoke the blocking get method on the ParallelDurableFuture to get the results with respect to the ParallelConfig. Then, we invoke the get method on DurableFuture to get the individual results of both Lambda invocations. Finally, we create the _ AuthorContent _ with these results.

The last step is to invoke the Lambda function, which is responsible for writing the author content into the file:

 ctx.invoke("writeAuthorContentToFile-step", WRITE_AUTHOR_CONTENT_TO_FILE_FUNCTION_ARN, 
    authorContent, Void.class, invokeConfig);

As we explained in part 2, we use S3 Files here. The whole part on how to configure S3 Files and give the Lambda function access to it has now moved from the AuthorContentExtractorOrchestrator durable Lambda function to the WriteAuthorContentToFileFunction Lambda function. See the SAM template for more detail.

To test our Lambda durable function, we can navigate to the Lambda service, search for the AuthorContentExtractorOrchestrator 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:

Let's also look at event history:

We see that this matches what we implemented. Our Lambda durable function invokes in parallel 2 Lambda functions to search for YouTube videos and upcoming talks (each in an individual branch). Then, it awaits the results of both invocations because we defined in the parallel configuration that we wait until all invocations are completed. Then the last Lambda function to write the author content into the file gets invoked.

One general question at the end: is the Lambda function invocation from another Lambda function considered an anti-pattern? Or should we put an API Gateway in between instead? My answer is that with built-in fault-tolerance for AWS Lambda durable functions, it's now safe to invoke a Lambda function directly.

Conclusion

In this part of the series, we moved the logic associated with each step into a separate Lambda function. We explored how to invoke another Lambda function within the durable step. Also, we showed how to invoke multiple Lambda functions in parallel.

In the next part of the series, we'll transform our application into an agentic one. Currently, the search for YouTube and upcoming talks returns static content. We'll replace it with the Amazon Bedrock AgentCore Gateway Web Search Tool. As it's exposed via MCP, we need an MCP client to connect to it. For that, we'll use the Spring AI framework. First, we still use AWS Lambda to host the AI agents. In later parts, we'll show how to host those AI agents on the Amazon Bedrock AgentCore Runtime instead.

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 5 Map and child context

Vadym Kazulkin — Mon, 14 Sep 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. Later, in parts 3 and 4 of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to implement wait for callback and wait for condition.

In this part, we'll explore map and child context operations.

Sample application with map and child context

Let's explore the child context operation first. Child contexts run an isolated stream of work with their own operation counter and checkpoint log. They support the full range of durable operations — step, wait, invoke, createCallback, and nested child contexts. In our sample application, we'll add a map operation, which uses a child context underneath. We get access to it through DurableContext. A Map operation applies a function to each item in a collection concurrently, with each item running in its own child context.

Now let's add an artificial use case: for each YouTube video found, we add it to the author's YouTube playlist. I first copied the application that we created in part 2 into the aws-s3-files-lambda-durable-functions-with-map-and-child-context-java-25 repository.

The main business logic we have to add is in the saveYouTubeVideosToPlayList method of the AbstractAuthorContentExtractor:

public default void saveYouTubeVideosToPlayList (DurableContext ctx, Author author, YouTubeVideos youtubeVideos)  {
   var youtubePlayList = findOrCreateYouTubePlayListForTheAuthor(author);

   var mapConfig = MapConfig.builder()
       .nestingType(NestingType.NESTED)
       .maxConcurrency(5)                                   
       .completionConfig(CompletionConfig.allCompleted())    
       .build();

   var mapResult = ctx.map("saveYouTubeVideoToPlayList-step", youtubeVideos.youtubeVideos(), 
      Boolean.class, (youtubeVideo, index, childCtx) -> {       
        return childCtx.step("saveYouTubeVideoToPlayList-step-"+index, Boolean.class, 
       stepCtx -> saveYouTubeVideoToPlayList(youtubeVideo, youtubePlayList)
      , this.getStepConfig());
    }, mapConfig);

}


private static int findOrCreateYouTubePlayListForTheAuthor(Author author) {
     // Use YouTube API to log in to the YouTube Account and search for the author's playlist
     // and return it if it already exists or create a new one
     // move this logic into a separate Lambda function and invoke it as a durable step
     return 1;
}

private static Boolean saveYouTubeVideoToPlayList(YouTubeVideo youtubeVideo, int playListId) {
    //Use YouTube API to save the video URL to the playlist. 
    return true;
}

We invoke this saveYouTubeVideosToPlayList method in the AuthorContentExtractor or AsyncAuthorContentExtractor classes.

First of all, I won't use the YouTube API to create or retrieve the YouTube playlist for the given author and store each found video there. I use some static output, as the goal of this article is to demonstrate the functionality of the map operation.

Let's go step by step through this code. Map applies a function to each item in a collection concurrently, with each item running in its own child context. Results are collected into a MapResult that maintains input order. Each item's function receives its own DurableContext, so you can use any durable operation (step(), wait(), invoke(), etc.) inside the map function. The function passed to map() is a MapFunction:

@FunctionalInterface
public interface MapFunction<I, O> {
    O apply(I item, int index, DurableContext context);
}

The index parameter is the zero-based position of the item in the input collection, useful for naming operations or correlating results. For each found YouTube video, we invoke the saveYouTubeVideoToPlayList method, which returns the result of type Boolean. In our case, it is always true, indicating that the video was stored in the playlist.

The input collection must have deterministic iteration order. List, LinkedList, and TreeSet are accepted. HashSet and unordered map views are not, leading to the IllegalArgumentException. That's why I changed the implementation of the YouTubeVideos class to use List instead of Set there.

Next, let's explore MapConfig in more detail. There are several main settings there:

maxConcurrency controls how many items execute concurrently. When set, items beyond the limit are queued and started as earlier items complete. The default is null (unlimited).

nestingType, with Nested as the default.

Nested. Create CONTEXT operations for each branch/iteration with full checkpointing. Operations within each branch/iteration are wrapped in their own context. Observability: High - each branch/iteration appears as a separate operation in execution history. Cost: Higher - consumes more operations due to CONTEXT creation overhead. Scale: Lower maximum iterations due to operation limits
Flat. Skip CONTEXT operations for branches/iterations using virtual contexts. Operations execute directly without individual context wrapping. Observability: Lower - branches/iterations don't appear as separate operations. Cost: ~30% lower - reduces operation consumption by skipping CONTEXT overhead. Scale: Higher maximum iterations possible within operation limits

CompletionConfig controls when the map operation stops starting new items. Here, there are many possibilities from which we can choose:

allCompleted (we use it). All items run regardless of failures. Failures are captured per-item.
allSuccessful. All items must succeed. Zero failures tolerated.
firstSuccessful. Complete as soon as the first item succeeds.
minSuccessful. Complete when the specified number of items have succeeded.
toleratedFailureCount. Complete when more than the specified number of failures have occurred.
toleratedFailurePercentage. Complete when the failure percentage exceeds the specified threshold (0.0 to 1.0).

When early termination is triggered, items that were never started have SKIPPED status with null for both result and error in the MapResult.

Each MapResultItem contains the following methods:

status: SUCCEEDED, FAILED, or SKIPPED.
result: the result value, or null if failed/skipped.
error: the error details as MapError, or null if succeeded/skipped.

Failed items store error details as MapError, a serializable record that survives checkpoint-and-replay cycles with the following methods that can be invoked:

errorType: Fully qualified exception class name (e.g., java.lang.RuntimeException).
errorMessage: The exception message.
stackTrace: Stack trace frames as a list of strings, or null.

One item's failure does not prevent other items from completing. MapResult captures the failed items at their corresponding index.

Map operations are fully durable. On replay after interruption:

Completed items return cached results without re-execution.
Incomplete items resume from their last checkpoint.
Items that never started execute fresh.

Small results (< 256KB) are checkpointed directly, whereas large results are reconstructed from individual child context checkpoints on replay.

That's it. There are no changes in the Infrastructure as Code part that we need to make. 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 AuthorContentExtractor or 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"
}

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

Here we see that the operation with the name saveYouTubeVideoToPlayList-step and the subtype Map. We also see 2 iterations (for each of the 2 YouTube videos found) with the subtype MapIteration. Each iteration is executed as an individual durable step.

Let's also look at event history:

Here we see all events (durable operations) in the right order required for the execution of our Lambda durable function.

There is also the mapAsync operation. It starts the map operation without blocking, returning a DurableFuture.

Conclusion

In this part of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to implement map and child context operations.

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 next part, 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.

Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore - Part 4 Upgrade sample application to Embabel 1.5

Vadym Kazulkin — Mon, 07 Sep 2026 14:00:00 +0000

Upgrade sample application to Embabel 1.5 to support Spring Boot 4.x and Spring AI 2.x

In parts 2 and 3, we developed our sample application and interacted with it via the shell and HTTP. We used Embabel version 1.0 there, which targets Spring Boot 3.x / Spring AI 1.x.

Recently, the Embabel team released version 1.5, which supports Spring Boot 4.x / Spring AI 2.x. In this article, we'll explain how to migrate our sample application to the Embabel 1.5.x version. You can find the final version of the application in my GitHub repository.

The migration for my use case is really simple. First, in pom.xml we need to declare this Embabel version:

<properties>
   <java.version>25</java.version>
   <embabel-agent.version>1.5.1</embabel-agent.version>
</properties>

Please note that we use version 1.5.1 here. With version 1.5.0, I ran into a specific problem while using the Amazon Bedrock Converse API. This was due to the fact that BedrockOptionsConverter created generic ToolCallingChatOptions. Spring AI 2.0’s BedrockProxyChatModel expects BedrockChatOptions and casts the request options accordingly, causing:

ClassCastException: DefaultToolCallingChatOptions cannot be cast to BedrockChatOptions.

With version 1.5.1, the Embabel team fixed the problem. Next, as Spring Boot 4.x / Spring AI 2.x uses Jackson version 3 by default, we need to declare a Jackson 3 mapper Spring bean. We do it in the Spring Boot main EmbabelConferenceApplication application class of our sample application:

@Bean
public JsonMapper objectMapper() {
    return new tools.jackson.databind.json.JsonMapper();
}

That's it. Now you can compile, start, and interact with our sample application the same way we described in parts 2 and 3.

Orchestrating workflows with Amazon S3 Files and AWS Lambda durable functions using Java SDK - Part 4 Wait for condition

Vadym Kazulkin — Mon, 31 Aug 2026 14:00: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.
Later, in part 3 of the series, we explored how to use the AWS Lambda Durable Execution SDK for Java to implement wait and callback.

In this part, we'll explore the wait for condition operation.

Sample application with wait for condition

Let's explore the "wait for condition" operation. We get access to it through DurableContext. It repeatedly calls a check function until it signals done. Between polls, the Lambda suspends without consuming compute. State is checkpointed after each check, so progress survives interruptions.

I first copied the application that we created in part 3 into the aws-s3-files-lambda-durable-functions-with-wait-for-condition-java-25 repository. The only change we had to make was to reimplement the waitForUpcomingTalksApproval method of the AbstractAuthorContentExtractor class. Here we'll now use the "wait for condition" instead of the "wait for callback" operation.

This is how the code now looks:

public default UpcomingTalkApprovalStatus waitForUpcomingTalksApproval(DurableContext ctx, Author author, UpcomingTalks upcomingTalks) {

  var config = WaitForConditionConfig.<UpcomingTalkApprovalStatus>builder()                
     .waitStrategy(WaitStrategies.defaultStrategy())
     .initialState(new UpcomingTalkApprovalStatus(upcomingTalks, 
         UpcomingTalkApprovalStatus.Status.PENDING))
     .build();

  return ctx.waitForCondition(
     "wait-for-approval",
     UpcomingTalkApprovalStatus.class, 
         (currentStatus, stepCtx) -> {
         var latest = this.getUpcomingTalkApprovalStatus(author,upcomingTalks);
         return  
         UpcomingTalkApprovalStatus.Status.APPROVED.equals(latest.status())                     
         ? WaitForConditionResult.stopPolling(latest)
         : WaitForConditionResult.continuePolling(latest);
    },
    config);
}

private UpcomingTalkApprovalStatus getUpcomingTalkApprovalStatus(Author author, UpcomingTalks upcomingTalks) {
     // Generate random integers in range 0 to 3
     int r = RANDOM.nextInt(4);
     return r < 3 ? 
       new UpcomingTalkApprovalStatus(upcomingTalks, 
          UpcomingTalkApprovalStatus.Status.NOT_APPROVED) :
       new UpcomingTalkApprovalStatus(upcomingTalks, 
          UpcomingTalkApprovalStatus.Status.APPROVED);
}

Let's go step by step through this code. The ctx.waitForCondition invocation receives the current state and a StepContext, and returns a WaitForConditionResult. WaitForConditionResult contains the result type, in our case UpcomingTalkApprovalStatus :

WaitForConditionResult.stopPolling(value) - condition met (in our case, status "APPROVED"), return value as the final result.
WaitForConditionResult.continuePolling(value) - keep polling (bacause the status is "NOT_APPROVED"), pass value to the next check.

For the sake of simplicity, we haven't implemented the proper endpoint to poll the status. We provided a simple implementation in the getUpcomingTalkApprovalStatus method, which generates a random integer between 0 and 3. If 3 is generated, the "APPROVED" status will be returned, indicating that the condition is met and the polling should stop. If 0, 1, or 2 are generated, the operation will keep polling.

Next, let's look at how to configure WaitForConditionConfig. First, we pass the initialState with the status "PENDING," and this status is passed to the first check invocation. After that, we also configure the waitStrategy. The wait strategy controls the delay between polls. By default, waitForCondition uses an exponential backoff wait strategy (60 max attempts, 5s initial delay, 300s max delay, 1.5x backoff rate, FULL jitter). We can invoke the WaitStrategies.exponentialBackoff method to configure exponential backoff with different settings than the default ones. Alternatively, we can use the WaitStrategies.fixedDelay method. With this wait strategy, we need to configure:

fixedDelay - a constant delay between polls and
maxAttempts - a maximum number of attempts before throwing WaitForConditionFailedException. This exception is thrown when the maximum attempts are exceeded (thrown by the wait strategy).

We can also implement Custom Wait Strategies, which we won't cover in this article.

To test our Lambda durable function, we can navigate to the Lambda service, search for the AuthorContentExtractor or 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"
}

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

Here we see that the operation with the name wait-for-approval and the subtype WaitForCondition succeeded after 3 attempts. The number of retries is 2. This means that it took 3 attempts to generate the integer 3. We defined the generation of this value as the condition to stop polling and return the result.

Let's also look at event history:

Here we see all events (durable operations) in the right order required for the execution of our Lambda durable function.

There is also the waitForConditionAsync operation for non-blocking polling that you can explore on your own. It starts polling but returns a DurableFuture immediately, allowing other operations to run concurrently.

Conclusion

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

In the next part, we'll explore map and child context operations. 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 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.

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.

Update from September 2026 Please read my article Building AI Agents with Embabel, Spring AI and Amazon Bedrock AgentCore - Part 4 Upgrade sample application to Embabel 1.5 to find out how to upgrade this sample application to Embabel version 1.5, which supports Spring Boot 4.x and Spring AI 2.x.

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 in the upcoming versions 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.