[FEEDBACK REQUEST] Should AWS Lambda deprecate callback-style function handlers for Node.js 24 and later?

[maxday]

UPDATE
Node.js 24 support in Lambda is now Generally Available.
https://aws.amazon.com/about-aws/whats-new/2025/11/aws-lambda-nodejs-24/
https://aws.amazon.com/blogs/compute/node-js-24-runtime-now-available-in-aws-lambda/
https://www.amazonaws.cn/en/new/2025/amazon-lambda-adds-support-for-node-js-24-in-amazon-web-services-china-regions/

We have made the change discussed in this proposal. Callback-based function handlers are not supported in the Lambda Node.js 24 runtime. Support for callback-based function handlers in Node.js 22 and earlier runtimes is not affected.

To clarify: the non-async function handler signature that takes event and (optionally) context parameters, without a callback, is not deprecated:

export const handler = (event) => { };

export const handler = (event, context) => { };

If your function is using the handler signature that includes a callback parameter, but doesn't actually use the callback, then you can switch to one of these function signatures without making other code changes.

For more details, see Valid handler patterns for Node.js functions in our documentation.

We are working through the necessary changes to the examples in the API Gateway and Lambda@Edge documentation.

Thank you all for the feedback and discussion.

👍 👎 The AWS Lambda Runtimes team would love your thoughts! Please upvote/downvote to indicate if you support this change.

Currently, AWS Lambda supports both callback-style and async/await function handler signatures. Considering Node.js has fully embraced async/await, we are considering removing support for callback style function handlers starting with our Node.js 24 release later this year. With this change, customers currently using the callback signature will need to update their code to use the async/await signature when migrating their functions to Node.js 24 or later runtimes.

This proposal applies to Node.js 24 and later runtimes only. We will continue to support both callback and async/await function handler signatures in our existing Node.js 18, Node.js 20, and Node.js 22 runtimes.

Current callback-style: (to be removed)

exports.handler = (event, context, callback) => {
  // ... handler logic
  callback(null, { statusCode: 200, body: 'Success!' });
};

Async/await style: (to be kept as-is)

export const handler = async (event, context) => {
  // ... handler logic
  return { statusCode: 200, body: 'Success!' };
};

Should we make this change? Please vote!
👍 : Yes, in favor of deprecating the callback handler signature.
👎 : No, keep the callback handler signature.

Please also share any feedback in the comments.

[astuyve]

Definitely deprecate it.

People either use it accidentally (due to old examples or documentation), or think that setting callbackWaitsForEmptyEventLoop to false is a way to perform compute after the handler exits (not realizing that those promises are only driven during subsequent invocations and can fail silently or dropped entirely on shutdown/timeout/suppressed init).

[arnabrahman]

Yes, sir

[dvddpl]

absolutely deprecate it please!

[willfarrell]

I've add this to the Middy roadmap to revisit for future major releases. We dropped support for callbacks many yers ago, but still have references within the code.

[TrickSumo]

Yes

[dreamorosi]

I literally never use it and I agree with the general sentiment of deprecating it, but the proposal is missing some info on what are the benefits of doing this. Will it help customers in any way, or will it bring performance improvements, or?

I imagine that having this info would help others who still use it better evaluate the tradeoffs.

[dignat]

Yes deprecated please

👍

[uafaruqi]

+1

I literally never use it and I agree with the general sentiment of deprecating it, but the proposal is missing some info on what are the benefits of doing this. Will it help customers in any way, or will it bring performance improvements, or?

I imagine that having this info would help others who still use it better evaluate the tradeoffs.

[aripalo]

Yes please, deprecate the callback pattern.

Although not a major issue, but currently having that callback pattern as an option can sometimes lead to people (i.e. developers new to Lambda) to use it "accidentally" (meaning without understanding there are better patterns. So deprecating that callback pattern would mean one thing less to teach / advocate (against) about.

[maxday]

Firstly, thank you so much for your feedback!

Here are a few more details on why we're thinking about deprecating the callback handler:

1. Modernization. async/await has been introduced in ES2017 and Node.js has fully embraced it. If you're using a third-party package which uses async functions, you'll need to wrap it around promises and this adds complexity.

2. Simplicity. As mentioned by @astuyve and @aripalo, having multiple ways of defining a handler leads to confusion. You can achieve the same behavior using one or the other, so keeping both of them might be confusing.

[lmammino]

I agree with the idea of deprecating the callback pattern.

One thing to consider is that communication might be more challenging than usual in this case. How can we ensure that all AWS examples, documentation, and repositories are properly updated to reflect this change?

It’s probably a good idea to issue warnings well in advance, just in case anyone is still relying on this feature. A more cautious approach could be to introduce a deprecation warning in the logs whenever the callback is used, starting with the Node.js 24 runtime. It would be even better if this could also be applied to previously supported runtimes. The feature could then be fully removed in the next major runtime release, such as Node.js 26.

[leleofg]

yessss

[Rexben001]

I agree! The async/await pattern has been the standard in modern JavaScript for years and is more intuitive and less error-prone than callback-based code.

[caiorhian]

I agree, should be deprecated!