I tried out the Node.js 24 runtime for AWS Lambda
This page has been translated by machine translation. View original
On November 25, 2025, AWS Lambda began supporting Node.js 24.
AWS Lambda adds support for Node.js 24 | AWS What's New
The Node.js 24 runtime includes significant changes to development methods, such as the deprecation of traditional callback-based function handlers and support for only the async/await pattern. This article presents the results of deployment verification using AWS CLI and CloudFormation, and error behavior when using the callback format.
Test Environment
- OS: Linux (Amazon Linux 2023)
- AWS CLI: aws-cli/2.32.6
- Region: us-east-1
- Deployment Methods: AWS CLI, CloudFormation
1. Deploying ES Modules Functions with AWS CLI
First, I created a function using ES Modules format (import/export) with the nodejs24.x runtime specified.
index.js
export const handler = async (event) => {
console.log('Event:', JSON.stringify(event, null, 2));
return {
statusCode: 200,
body: JSON.stringify({
message: 'Hello from Node.js 24!',
timestamp: new Date().toISOString()
})
};
};
package.json
To enable ES Modules, I specified "type": "module".
{
"type": "module"
}
I created a zip file and deployed and executed the Lambda function with the following commands.
# Create zip file
zip function.zip index.js package.json
# Create Lambda function
aws lambda create-function \
--function-name node24-hello-world \
--runtime nodejs24.x \
--handler index.handler \
--role arn:aws:iam::123456789012:role/service-role/lambda-execution-role \
--zip-file fileb://function.zip \
--region us-east-1
# Execute
aws lambda invoke \
--function-name node24-hello-world \
--region us-east-1 \
response.json
Execution Result (response.json)
{
"statusCode": 200,
"body": "{\"message\":\"Hello from Node.js 24!\",\"timestamp\":\"2025-11-28T10:00:00.000Z\"}"
}
I confirmed that deployment to the nodejs24.x runtime via CLI and ES Modules operation were performed normally.
I was also able to confirm the operation of the Node.js 24.x runtime Lambda function in the web console.

2. Deployment with CloudFormation
Next, I verified deployment using a CloudFormation template. When using the ZipFile property, it's not possible to include package.json, so I wrote it in CommonJS format.
template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Node.js 24 Lambda Function Test
Resources:
LambdaExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
Node24Function:
Type: AWS::Lambda::Function
Properties:
FunctionName: node24-cfn-test
Runtime: nodejs24.x
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
Code:
ZipFile: |
exports.handler = async (event) => {
console.log('Event:', JSON.stringify(event, null, 2));
return {
statusCode: 200,
body: JSON.stringify({
message: 'Hello from Node.js 24 via CloudFormation!',
timestamp: new Date().toISOString()
})
};
};
After deployment, I confirmed that the stack status was CREATE_COMPLETE.
I verified that Node.js 24.x can be used without issues in CloudFormation as well.
3. Verifying Behavior of Deprecated Callback Format
Regarding the major change in Node.js 24, "deprecation of callback format," I deployed code in the deprecated format and checked what kind of errors would occur in the logs.
Test Code (callback-handler.js)
exports.handler = (event, context, callback) => {
console.log('Event:', JSON.stringify(event, null, 2));
// This writing style is not supported in Node.js 24
callback(null, {
statusCode: 200,
body: JSON.stringify({
message: 'Hello from callback handler'
})
});
};
Execution Result (Invocation Error)
When executing aws lambda invoke, the following Runtime.CallbackHandlerDeprecated error was returned.
{
"StatusCode": 200,
"FunctionError": "Unhandled",
"ExecutedVersion": "$LATEST"
}
CloudWatch Logs Output
{
"errorType": "Runtime.CallbackHandlerDeprecated",
"errorMessage": "ERROR: AWS Lambda has removed support for callback-based function handlers starting with Node.js 24. You need to modify this function to use a supported handler signature to use Node.js 24 or later. For more information see https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html."
}
As stated clearly in the error message, I confirmed that using callback-based handlers in Node.js 24 or later results in a runtime error and execution fails. This proves that rewriting to async/await is mandatory when migrating existing code.
4. Error Handling Verification
I also checked the behavior of error handling in the async/await pattern.
Test Code (error-handler.js)
exports.handler = async (event) => {
// Error handling with try-catch
try {
if (event.tryCatchError) {
throw new Error('Error caught in try-catch');
}
return { statusCode: 200, body: 'Success' };
} catch (error) {
console.error('Caught error:', error);
return {
statusCode: 500,
body: JSON.stringify({ error: error.message })
};
}
};
Execution Result
Result when sending payload {"tryCatchError":true}.
{
"statusCode": 500,
"body": "{\"error\":\"Error caught in try-catch\"}"
}
As intended, the error was caught in the catch block, and a response with status code 500 was returned. I confirmed that control is possible with the standard JavaScript try-catch syntax, instead of the traditional callback(error).
Summary
From this verification, I confirmed the following behaviors in AWS Lambda's Node.js 24 runtime:
- Deployment to
nodejs24.xcan be performed normally with AWS CLI and CloudFormation. - ES Modules (
type: module) are supported. - Callback format handlers result in a
Runtime.CallbackHandlerDeprecatederror and are completely unexecutable. - Error handling has been unified to standard methods using
async/awaitandtry-catch.
Node.js 24 is scheduled for long-term support (LTS) until April 2028. Since it offers the latest features and a long support period, I recommend adopting this version for new development.
Migration to Node.js 24 involves a significant change with the deprecation of the long-familiar callback format. While code modification costs may be incurred depending on existing assets, consider this an opportunity for complete migration to the async/await pattern, which can improve readability and unify standard error handling as part of modernization.
