Thundra: Serverless Observability for AWS Lambda

The black box nature of AWS Lambda and other serverless environments means that identifying and fixing performance issues is difficult and time-consuming. Built for straightforward debugging, monitoring, and observability, Thundra provides deep insight into your entire serverless environment. Thundra collects and correlates all your metrics, logs, and traces, allowing you to quickly identify problematic invocations and also analyzes external services associated with that function. With Thundra’s zero overhead and automated instrumentation capabilities, your developers are free to write code without worrying about bulking up their Lambdas or wasting time on chasing black box problems.

Get Started    Discussions

Custom Runtime and Layer Support



“Lambda Layers” allows developers to centrally manage common code and data across multiple functions. By “Lambda Layers”, deployment packages (typically .zip files) can be released as layer to be used by AWS Lambda functions.

  • There is no defined format for the package content, it can contain anything (binaries, scripts, config files, etc …)
  • The content of layer packages is extracted onto /opt folder so they will be available there for the function’s execution environment to be used. Versioning of published layer is handled by AWS Lambda by giving monotonically increasing version number with every release.
  • The published layer can be deleted but then it cannot be added anymore. The functions which already have this layer can continue to have the layer.
  • Resource-based policies can be assigned to layers to give them account based or public access.

Custom Runtime

“Custom Runtime” feature in AWS Lambda which allows you to use any programming language to run your functions. By “Custom Runtime”, you provide your deployment package (typically .zip files) which contains bootstrap file as the entry point where it can be any executable file such as a script or binary file. In here, AWS Lambda platform is not interested in which programming language or runtime are you using, but just starts your bootstrap. It gives you more flexibility than managed runtimes but you need to implement the AWS Lambda “Runtime API” yourself which defines a simple HTTP based specification of the Lambda programming model which can be implemented in any programming language:

  • Initialize function once
  • Then for every invocation
  • Poll the request/event data from AWS Lambda runtime API through HTTP. When there is no invocation (typically you have already processed the previous invocation and looking for a new one), your container will be frozen here
  • Invoke the function (specifically classic handler implementation) itself with the polled request/event data and get the response from there
  • Send the response to AWS Lambda runtime API back through HTTP.

For managed runtimes, all of these above are already handled by AWS Lambda runtime itself for you but you don’t have control on the environment. Now, there are more things that you CAN do however there are more things that you MUST do :)

How to use Thundra Java Layer and Custom Runtime

With Thundra Java Layer and Custom Runtime implementation, you can integrate your existing Lambda Functions with Thundra so easy without changing any of your code. The document shows how to configure an existing Lambda function to be integrated with Thundra.

  • First, go to your AWS Lambda Function Page and Click Layers in Designers tab and then click "Add a layer"
  • Specify the Thundra layer by its ARN (Notice that latest part of the ARN is the version of the layer. So you can change it according to the version you want to use) and add it. Thundra layer ARN is arn:aws:lambda:${region}:269863060030:layer:thundra-lambda-java-layer:${latest-version} format. See the latest version here.

Note that region part of the ARN is dynamic, so you need to change it according the region where you deploy your function. So let say that you deploy your Lambda function to Oregon (us-west-2) region, the layer ARN will be arn:aws:lambda:us-west-2:269863060030:layer:thundra-lambda-java-layer:<latest-version>

  • Back to the main configuration page and change runtime to custom runtime.
  • Add Thundra API key as environment variable.
  • And then save the configuration.

That’s all. You are now integrated with Thundra without any code change, dependency addition and redeployment. Thundra is deployed to your Lambda environment by AWS and you don’t need to take care of anything. Thundra handles the rest for you. As you can see, you don’t need to

  • add Thundra dependency
  • wrap your function
  • redeploy your artifact bundle

Not anymore!

Additionally, with “Custom Runtime”, it is now possible tuning Java-based Lambda applications to start faster for reducing cold start overhead. Java is one of the languages that suffers from cold start overhead most on AWS Lambda. Until now, with managed Java runtime, it was not feasible to optimize a Java process to start faster. Even though, AWS Lambda already makes some optimizations to start process faster for Java runtime by enabling class data sharing with -Xshare:on so classes are loaded from a shared memory mapped file in some pre-parsed format, there are still some other options to tune Java application startup time. With Thundra “Custom Runtime” support, you already get these optimizations out of the box, by setting thundra_agent_lambda_jvm_optimizeForFastStartup environment variable to true, as we use AWS Lambda’s JVM which is pre-installed on the custom runtime environment already and you will get have lover cold start overhead. If you are in trouble with the cold start overhead for your Java-based Lambda function, give it a try and see the effect.

Latest Layer Version

The latest version of the layer is 26.

You can add it to your project by copying the following line and setting the region (for ex. us-west-2).


Custom Runtime and Layer Support

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.