DEV Community

Cover image for AWS Lambda Managed Instances with Java 25 and AWS SAM – Part 5 Lambda function initial performance measurements
AWS Heroes profile image Vadym Kazulkin
Vadym Kazulkin for AWS Heroes

Posted on • Originally published at vkazulkin.com

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

#aws #serverless #java #lambda

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

Lambda function initial performance measurements

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Top comments (0)