AWS Lambda Node.js 24: The 2025 Upgrade Plan

AWS turned on a new runtime wave for serverless teams: AWS Lambda Node.js 24 went live on November 25, 2025, and it removes callback-based handlers entirely. In the same fortnight, Lambda added Python 3.14 (October 7 final upstream) and Java 25 LTS. There’s also a Kafka Event Source Mapping update that can slash polling costs. If you own production Lambdas, this is your cue to schedule an upgrade sprint this week. (aws.amazon.com)

What just shipped, exactly?

Here are the high-signal changes and their dates:

• Node.js 24 runtime is available as a managed runtime and container base image. Lambda focuses fully on modern async/await; callback-style handlers are no longer supported. Posted November 25, 2025. (aws.amazon.com)
• Python 3.14 is available as managed runtime and base image (released upstream on October 7, 2025). In Lambda, free‑threaded mode and the experimental JIT are not enabled in the managed build. Posted November 18, 2025. (aws.amazon.com)
• Java 25 LTS runtime landed November 14, 2025, bringing language and perf improvements (e.g., primitive types in patterns, flexible constructor bodies, AOT ergonomics). SnapStart remains supported. (aws.amazon.com)
• Kafka ESM (Provisioned mode) now supports higher poller density and grouping via PollerGroupName, enabling up to 90% cost reduction for low-throughput workloads. Posted November 21, 2025. (aws.amazon.com)

Why AWS Lambda Node.js 24 changes your handler code

Here’s the thing: Lambda’s Node.js 24 runtime ships with a new Runtime Interface Client and drops the callback-based handler signature. If your code still does (event, context, callback), it won’t run on Node 24. Move to async handlers and return a Promise. Lambda 24 supports TypeScript-friendly tooling and works with AWS Powertools for TypeScript out of the box. (aws.amazon.com)

// Before (Node 16/18/20/22 tolerated)
exports.handler = (event, context, callback) => {
  try {
    callback(null, { statusCode: 200, body: "ok" });
  } catch (err) {
    callback(err);
  }
};

// After (Node 24)
export const handler = async (event) => {
  // await downstream IO
  return { statusCode: 200, body: "ok" };
};

Worth noting: Node 24 is Active LTS and supported by the Node project until the end of April 2028, so upgrading buys you a long runway. (nodejs.org)

People also ask: Does Lambda still support callback handlers?

No—not on Node 24. Async/await is the path going forward. If you need time to refactor, pin your functions to Node 22 temporarily, but plan your move now since 22 goes out of Maintenance LTS in April 2027. (aws.amazon.com)

Python 3.14 on Lambda: what’s in and what’s intentionally out

Python 3.14 brings real upstream changes (including better free‑threaded support and other improvements), but Lambda’s managed build keeps things conservative: no free‑threaded mode and no JIT in the stock runtime. If you want those, bring your own container image with a custom build. On the upside, you get the modern Amazon Linux 2023 base and production stability. (aws.amazon.com)

What about support windows? Python 3.14’s published timeline shows security fixes into October 2030. That longer runway matters for enterprises that dislike frequent base image churn. (endoflife.date)

Can I use free‑threaded Python on Lambda?

Yes, but only if you ship a custom runtime or container image compiled for it. The managed runtime disables free‑threaded mode, and that’s by design to protect single‑thread performance and ecosystem compatibility. If you do go free‑threaded, test your C‑extensions carefully. (aws.amazon.com)

Java 25 on Lambda: practical wins

Java 25 in Lambda taps a set of language and runtime improvements that are actually useful in serverless deployments: primitive types in patterns, flexible constructor bodies, and AOT ergonomics that can help cold starts. SnapStart support continues where available. The AWS announcement also notes updated defaults in the JIT pipeline and other tweaks. If you’re on Java 17 or 21 today, put 25 on your roadmap for new functions; migrate hot paths where you can measure cold‑start or memory benefits. (aws.amazon.com)

New: a cost win for event-driven shops (Kafka ESM)

Provisioned mode for Kafka Event Source Mappings (ESMs) just got far cheaper for low-throughput streams. Each Event Poller Unit (EPU) still covers up to 20 MB/s, but Lambda now packs 10 pollers per EPU by default (up from 4) and lets you group ESMs in a VPC with PollerGroupName to share capacity. AWS claims up to 90% cost reduction for the low‑throughput end of your fleet. If you’ve been avoiding Provisioned mode because it looked pricey, re-run the math. (aws.amazon.com)

# Example: group ESMs to share capacity
aws lambda create-event-source-mapping \
  --function-name processKafka \
  --event-source-arn arn:aws:kafka:... \
  --scaling-config MinimumEventPollers=2,MaximumEventPollers=6 \
  --self-managed-event-source Endpoints={KafkaBootstrapServers=[...] } \
  --provisioned-poller-config PollerGroupName=prod-streams

The 72‑hour upgrade playbook

You can modernize with minimal risk if you treat this as a short, focused sprint. Here’s a pragmatic plan my team uses with clients.

Day 1: Inventory, risk triage, and CI pinning

• Export a list of Lambda functions by runtime. Flag Node 18/20/22, Python 3.11/3.12/3.13, Java 17/21. Group by business criticality.
• In your CI, add matrix jobs for Node 24, Python 3.14, and Java 25. Fail fast on type errors, linting, and min test suites.
• For Node stacks, scan for callback usage, context.done, or libraries that assume callbacks. Replace with promise/async versions. Consider moving from aws-sdk v2 to modular v3 to shrink bundle size and tighten cold starts.
• For Python, check wheels for C‑extensions (Pandas, SciPy, cryptography). Make sure you can resolve manylinux/aarch64 wheels that match Amazon Linux 2023. Note that Lambda Python 3.12+ returns raw Unicode in JSON responses; review clients that expect escaped sequences. (docs.aws.amazon.com)
• For Java, test SnapStart compatibility on functions with heavy class initialization; validate any reflection or dynamic proxies work with snapshotting.

Day 2: Runtime migrations and shadow deploys

• Node: Flip a subset of low‑risk functions to Node 24 in a staging account. Validate telemetry and error rates. If you rely on callback-only middleware, fork or replace it. Enable AWS Powertools for structured logging and idempotency utilities. (aws.amazon.com)
• Python: Move a couple of CPU‑bound handlers to 3.14 and measure p95 latency. If you truly need free‑threading, build a custom image and run it in a canary alias; watch for import‑time GIL re‑enablement from unsupported wheels. (aws.amazon.com)
• Java: Recompile on 25 and enable AOT ergonomics where appropriate. Probe memory/CPU limits because Lambda’s constrained environment surfaces regressions quickly. (aws.amazon.com)
• Kafka ESM: Consolidate low‑throughput mappers with PollerGroupName. Start at 10 pollers/EPU default; verify lag and cost deltas after 24 hours. (aws.amazon.com)

Day 3: Cutover and guardrails

• Use Lambda aliases for safe rollouts. Start with 5–10% traffic to the new runtime alias and watch alarms. Scale to 50%, then 100% if clean.
• Enable structured logs, X-Ray (or your APM), and profiling (where supported). Wire alarms to error budgets, not just 5XX counts.
• Document runtime diffs (Node async-only, Python Unicode responses, Java 25 language features) in your engineering handbook so new services start on the modern baseline. (aws.amazon.com)

Gotchas we keep seeing

Here are the mistakes that burn calendar time.

• Callback residue in Node 24. If any package wraps your handler and expects a callback, your function will fail. Replace with an async‑aware wrapper or move to middleware that supports promises. AWS’s Node 24 post is explicit about this removal. (aws.amazon.com)
• Python wheels and AL2023. If you compile locally on macOS, you’ll ship incompatible binaries. Build on Amazon Linux 2023 or in a CI environment that matches it.
• Free‑threaded Python assumptions. Many blog posts assume “3.14 = no GIL”. That’s not the case on Lambda’s managed runtime; you only get it via custom builds. Check sysconfig.get_config_var("Py_GIL_DISABLED") if you’re unsure. (aws.amazon.com)
• Java cold start tuning. SnapStart helps but isn’t magic. Measure before/after; AOT flags can shift CPU curves. (aws.amazon.com)
• Kafka ESM over‑provisioning. Without grouping, you pay for idle pollers. The new defaults and PollerGroupName were designed to eliminate that waste—use them. (aws.amazon.com)

Is it safe to wait for deprecations?

You can delay a couple of weeks for high‑traffic holidays, but don’t punt for months. Node 24 gives you support through April 2028, which likely outlasts your current app’s lifecycle. Python 3.14’s security window through October 2030 is another reason to consolidate on one modern baseline across teams. The longer you run mixed runtimes, the slower every change gets. (nodejs.org)

Let’s get practical: a one‑page upgrade checklist

• Node 24: refactor handlers to async. Replace callback‑only libs. Test top‑level await. Verify Powertools integration. (aws.amazon.com)
• Python 3.14: rebuild dependencies on AL2023; watch Unicode JSON response behavior in 3.12+; confirm no reliance on free‑threaded features unless using a custom runtime. (docs.aws.amazon.com)
• Java 25: compile and run perf tests with SnapStart; consider patterns and constructor flexibility for cleaner code; check memory headroom. (aws.amazon.com)
• Kafka ESM: set PollerGroupName, verify 10 pollers/EPU defaults, measure lag and cost after 24 hours. (aws.amazon.com)
• CI: add matrix for runtime coverage; fail builds on incompatible handlers or missing wheels.
• Ops: rollout with aliases; wire SLO‑based alarms; document the new baseline.

Related deep dives on bybowu.com

If Node is your main workload, pair this article with our focused playbook Lambda Node.js 24 upgrade guide for step‑by‑step diffs and code mods. If you run edge logic, our analysis of CloudFront’s flat‑rate pricing explains how to tune Lambda@Edge usage alongside origin costs. And if your Node supply chain has grown sprawl‑y, bookmark the npm supply chain attack playbook for a hardened dependency workflow. For hands‑on help, see what we do and drop us a note.

What to do next (this week)

• Book a 90‑minute migration review with your platform lead; pick two services (one high‑traffic, one batch) and run the Day‑1 checks.
• Turn on Node 24 for a low‑risk function and ship behind an alias. Measure cold starts and memory.
• Switch one Python service to 3.14; verify JSON response encoding and wheel compatibility.
• Trial Java 25 on a cold‑start‑sensitive function with SnapStart.
• Group Kafka ESMs with PollerGroupName and snapshot the before/after bill.

Zooming out

This Lambda wave tightens the modern baseline: async/await everywhere for Node, a clean Python track with a long security horizon, and Java 25 for teams that need a conservative LTS with real language upgrades. The Kafka ESM changes aren’t flashy, but they compound over time—especially if you have lots of small topics. Move now, measure, and bank the gains.