AWS Lambda support does not work with `nodejs24.x` Lambda runtime

[trentm]

In Nov 2025, AWS released the nodejs24.x Lambda runtime: https://aws.amazon.com/blogs/compute/node-js-24-runtime-now-available-in-aws-lambda/

The Elastic Node.js APM agent support for Lambda does not work with this runtime.
A symptom of the failure will be the "Dropping lambda data due to error: metadata is not yet available" message in your Lambda logs, e.g.:

{"log.level":"warn","@timestamp":"2026-02-18T01:01:40.646Z","log.origin":{"function":"github.com/elastic/apm-aws-lambda/apmproxy.(*Client).ForwardLambdaData","file.name":"apmproxy/apmserver.go","file.line":364},"message":"Dropping lambda data due to error: metadata is not yet available","ecs.version":"1.6.0"}

The workaround for now is to stay with the nodejs22.x Lambda runtime.

[trentm]

Assuming that I'm right that the nodejs24.x AWS Lambda runtime has switched from Runtime Interface Client (aws-lambda-ric) version 3 (currently on https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/tree/main/) to version 4 (currently on https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/tree/nodejs24.x/), then:

The initial (perhaps only real) issue is that loading of the user function module (the file with the user's handler function, typically the handler export from the index.{js,mjs,cjs} file) is now loaded with await import(path) rather than require(path).

Here is the AWS Lambda Node.js code in v3 (this will use require() for extension-less and if package.json#type suggests it is a commonjs module, then falls back to await import()):
https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/blob/962ed28eefbc052389c4de4366b1c0c49ee08a13/src/UserFunction.js#L149-L174

And in v4 (this tries await import() with all typical file extensions, then only tries require() as a fallback):
https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/blob/e42ed5fea55e8848b55c804a67c39324d88c4318/src/function/module-loader.ts#L19-L30

Why is this a problem?

Because currently:

1. Elastic's current setup documentation for Lambda instrumentation says to starting the APM agent via NODE_OPTIONS="-r elastic-apm-node/start". This only sets up for hooking require(), and not for hooking import. This is now insufficient. We'll now need --experimental-loader=elastic-apm-node/loader.mjs (or module.register('elastic-apm-node/loader.mjs') in newer Node.js versions) to enable import-hooking.
2. The Elastic Node.js APM agent doesn't currently support hooking of the Lambda handler module with import. This will require some internal changes to the APM agent.

First I'll look into (2.).

Then there are a couple options for (1.):

• Just require users to explicitly use --experimental-loader=elastic-apm-node/loader.mjs, as documented in docs/reference/esm.md.
• Or move forward a little bit and, for Node.js versions that support it (which includes 24.x), have -r elastic-apm-node/start handle registering the module loader for hooking ESM (i.e. have it call module.register(...)). We'll probably want an opt-out envvar here, for the rare (I don't have examples) case where having the module loader causes harm. (Note to self: we'll want the haveHookFromExperimentalLoader() guard from etel days of yore to protect against double installing the module loader.)

[hydevip]

Another breaking change for AWS Lambda introduced with Node 24 is the removal of Callback-based function handlers.

Callback-based function handlers are only supported up to Node.js 22. Starting from Node.js 24, asynchronous tasks should be implemented using async function handlers.

when using :
const apm = require('elastic-apm-node'); const handler = apm.lambda( ...... );