AWS lambda documentation change
Summary
Added Node.js 24 runtime details, removed Node.js initialization section, and moved experimental features documentation to new section
Security assessment
The changes primarily restructure documentation about runtime versions and experimental features. While the experimental features section warns about stability/SLA impacts, there's no evidence of addressing a specific security vulnerability. The removed initialization section contained general async operation guidance but no security-specific content.
Diff
diff --git a/lambda/latest/dg/lambda-nodejs.md b/lambda/latest/dg/lambda-nodejs.md index 973055fae..d1c1b463b 100644 --- a//lambda/latest/dg/lambda-nodejs.md +++ b//lambda/latest/dg/lambda-nodejs.md @@ -5 +5 @@ -Node.js initializationRuntime-included SDK versionsUsing keep-aliveCA certificate loading +Runtime-included SDK versionsUsing keep-aliveCA certificate loadingExperimental Node.js features @@ -14,0 +15 @@ Name | Identifier | Operating system | Deprecation date | Block function create +Node.js 24 | `nodejs24.x` | Amazon Linux 2023 | Apr 30, 2028 | Jun 1, 2028 | Jul 1, 2028 @@ -18,13 +18,0 @@ Node.js 20 | `nodejs20.x` | Amazon Linux 2023 | Apr 30, 2026 | Jun 1, 2026 -The upstream Node.js language releases enable some experimental features by default. Lambda disables these features to ensure runtime stability and consistent performance. The following table lists the experimental features that Lambda disables. - -Experimental feature | Supported Node.js versions | Node.js flag applied by Lambda | Lambda flag to re-enable ----|---|---|--- -Support for importing modules using require in ES modules | Node.js 20, Node.js 22 | `--no-experimental-require-module` | `--experimental-require-module` -Support for automatically detecting ES vs CommonJS modules | Node.js 22 | `--no-experimental-detect-module` | `--experimental-detect-module` - -To enable a disabled experimental feature, set the re-enable flag in the `NODE_OPTIONS` environment variable. For example, to enable ES module require support, set `NODE_OPTIONS` to `--experimental-require-module`. Lambda detects this override and removes the corresponding disable flag. - -###### Important - -Using experimental features can lead to instability and performance issues. These features might be changed or removed in future Node.js versions. Functions that use experimental features aren't eligible for the Lambda Service Level Agreement (SLA) or AWS Support. - @@ -60,2 +47,0 @@ Your Lambda function comes with a CloudWatch Logs log group. The function runtim - * Node.js initialization - @@ -67,0 +54,2 @@ Your Lambda function comes with a CloudWatch Logs log group. The function runtim + * Experimental Node.js features + @@ -85,57 +72,0 @@ Your Lambda function comes with a CloudWatch Logs log group. The function runtim -## Node.js initialization - -Node.js has a unique event loop model that causes its initialization behavior to be different from other runtimes. Specifically, Node.js uses a non-blocking I/O model that supports asynchronous operations. This model allows Node.js to perform efficiently for most workloads. For example, if a Node.js function makes a network call, that request may be designated as an asynchronous operation and placed into a callback queue. The function may continue to process other operations within the main call stack without getting blocked by waiting for the network call to return. Once the network call is completed, its callback is executed and then removed from the callback queue. - -Some initialization tasks may run asynchronously. These asynchronous tasks are not guaranteed to complete execution prior to an invocation. For example, code that makes a network call to fetch a parameter from AWS Parameter Store may not be complete by the time Lambda executes the handler function. As a result, the variable may be null during an invocation. There can also be a delay between `INIT` and `INVOKE` which can trigger errors in time-sensitive operations. In particular, AWS service calls can rely on time-sensitive request signatures, resulting in service call failures if the call is not completed during the `INIT` phase. - -To avoid this, we recommend deploying your code as an ECMAScript module (ES module), and using top-level `await` to ensure all initialization is completed during the function `INIT` phase. This ensures initialization tasks are completed before handler invocations, avoids delays between `INIT` and `INVOKE` disrupting time-sensitive operations, and also maximizes the effectiveness of [provisioned concurrency](./provisioned-concurrency.html) in reducing cold start latency. For more information and an example, see [Using Node.js ES modules and top-level await in AWS Lambda](https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda). - -### Designating a function handler as an ES module - -By default, Lambda treats files with the `.js` suffix as CommonJS modules. Optionally, you can designate your code as an ES module. You can do this in two ways: specifying the `type` as `module` in the function's `package.json` file, or by using the `.mjs` file name extension. In the first approach, your function code treats all `.js` files as ES modules, while in the second scenario, only the file you specify with `.mjs` is an ES module. You can mix ES modules and CommonJS modules by naming them `.mjs` and `.cjs` respectively, as `.mjs` files are always ES modules and `.cjs` files are always CommonJS modules. - -Lambda searches folders in the `NODE_PATH` environment variable when loading ES modules. You can load the AWS SDK that's included in the runtime using ES module `import` statements. You can also load ES modules from [layers](./chapter-layers.html). - -ES module example - - -###### Example – ES module handler - - - const url = "https://aws.amazon.com/"; - - export const handler = async(event) => { - try { - const res = await fetch(url); - console.info("status", res.status); - return res.status; - } - catch (e) { - console.error(e); - return 500; - } - }; - -CommonJS module example - - -###### Example – CommonJS module handler - - - const https = require("https"); - let url = "https://aws.amazon.com/"; - - exports.handler = async function (event) { - let statusCode; - await new Promise(function (resolve, reject) { - https.get(url, (res) => { - statusCode = res.statusCode; - resolve(statusCode); - }).on("error", (e) => { - reject(Error(e)); - }); - }); - console.log(statusCode); - return statusCode; - }; - @@ -175,0 +107,15 @@ For optimal performance, we recommend bundling only the certificates that you ne +## Experimental Node.js features + +The upstream Node.js language releases enable some experimental features by default. Lambda disables these features to ensure runtime stability and consistent performance. The following table lists the experimental features that Lambda disables. + +Experimental feature | Supported Node.js versions | Node.js flag applied by Lambda | Lambda flag to re-enable +---|---|---|--- +Support for importing modules using require in ES modules | Node.js 20, Node.js 22 | `--no-experimental-require-module` | `--experimental-require-module` +Support for automatically detecting ES vs CommonJS modules | Node.js 22 | `--no-experimental-detect-module` | `--experimental-detect-module` + +To enable a disabled experimental feature, set the re-enable flag in the `NODE_OPTIONS` environment variable. For example, to enable ES module require support, set `NODE_OPTIONS` to `--experimental-require-module`. Lambda detects this override and removes the corresponding disable flag. + +###### Important + +Using experimental features can lead to instability and performance issues. These features might be changed or removed in future Node.js versions. Functions that use experimental features aren't eligible for the Lambda Service Level Agreement (SLA) or AWS Support. +