Which strategy should I use for AWS Lambda Node.js 20 Deprecation on April 30,?
Choose whether to move Lambda functions to Node.js 22 before Node.js 20 deprecates on April 30, 2026 and new-function creation blocks start on August 31, 2026.
Blockers
- breaking_change_in: runtime/nodejs-20 → capability/lambda
- breaking_change_in: runtime/nodejs-20 → capability/lambda
- breaking_change_in: runtime/nodejs-22 → capability/lambda
- breaking_change_in: runtime/nodejs-22 → capability/lambda
Who this is for
- serverless
- low-ops
- cost-sensitive
Candidates
Move Lambda functions to Node.js 22 now
As of 2026-04-01, AWS Lambda lists `nodejs22.x` on Amazon Linux 2023 with deprecation on April 30, 2027, block function create on June 1, 2027, and block function update on July 1, 2027. AWS Lambda lists `nodejs20.x` on the same Amazon Linux 2023 base, so moving from Node.js 20 to Node.js 22 does not also force an Amazon Linux 2 to Amazon Linux 2023 migration. As of 2026-04-01, AWS Lambda pricing is based on requests, duration, memory, and architecture, and AWS documents up to 34% better price-performance for Arm-based Graviton2 versus x86; no runtime-specific Node.js surcharge is documented. Lambda includes an AWS SDK for JavaScript v3 minor version in the runtime, but AWS recommends bundling the SDK yourself for dependency control and backward compatibility.
When to choose
Use this for most teams running production Lambda on `nodejs20.x`, especially when you want to clear the April 30, 2026 deprecation before support risk starts. It is the default choice when you do not have known Node 22 compatibility blockers and want another full year before the next Lambda Node.js deprecation window.
Tradeoffs
Removes the immediate deprecation deadline and avoids a compressed migration in mid-2026. The tradeoff is that you still need regression testing for a Node major-version change, especially for module-loading behavior and native dependencies.
Cautions
Lambda disables some upstream experimental Node.js features by default. On Node.js 22, Lambda disables both `--experimental-require-module` and `--experimental-detect-module` unless you explicitly re-enable them with `NODE_OPTIONS`, and functions using experimental features are not eligible for the Lambda SLA or AWS Support.
Stay on Node.js 20 temporarily and schedule migration before the block dates
As of 2026-04-01, AWS Lambda still supports `nodejs20.x` on Amazon Linux 2023, but AWS lists deprecation for April 30, 2026, block function create for August 31, 2026, and block function update for September 30, 2026. AWS states that after a runtime is deprecated, it may no longer apply security patches or updates to that runtime, and deprecated runtimes are no longer eligible for technical support. As of 2026-04-01, AWS Lambda pricing remains the standard request-and-duration model, so there is no verified runtime-specific cost advantage to staying on Node.js 20. This option mainly preserves delivery schedule flexibility for a short period.
When to choose
Use this only when a near-term release freeze, compliance window, or native-module validation issue makes an immediate runtime upgrade materially risky. It is a temporary holding pattern, not a steady-state choice, because the support and platform-policy window is already narrow.
Tradeoffs
Minimizes immediate engineering churn and lets you batch the runtime bump with other platform work. The downside is running into deprecation first, then create and update blocks later in 2026, with shrinking support and less room for rollback.
Cautions
Do not treat the August 31, 2026 create block as the only deadline. AWS lists the runtime itself as deprecated on April 30, 2026, and AWS says deprecated runtimes may stop receiving runtime security patches and are no longer eligible for technical support.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for AWS Lambda Node.js 20 Deprecation on April 30,?"