AWS Lambda Node.js 24: The Upgrade Playbook

AWS Lambda now supports Node.js 24, posted November 25, 2025. For teams running production on serverless JavaScript, this is a pivotal upgrade: the runtime standardizes on async/await (no more callback handlers), aligns with Node.js 24 LTS supported to April 2028, and is available as a managed runtime and container base image across all Regions. If “AWS Lambda Node.js 24” hasn’t hit your sprint board yet, it should this week.

What’s new in Lambda with Node 24

Here’s the thing: this isn’t just a version bump. The combination of Lambda’s runtime change and the Node 24 platform shifts adds up to real work—and real payoff.

• Handlers are async by default. Callback-based handlers aren’t supported in the new runtime. Your functions must return a Promise (or use async).
• Available everywhere. The Node 24 runtime is in all commercial Regions, plus GovCloud and China. Lambda@Edge support applies in the Regions where Edge runtimes are supported.
• Powertools for AWS Lambda (TypeScript) supports Node 24. If you rely on tracing, structured logging, and idempotency utilities, you’re covered.
• Container image option. Prefer containerized functions? Use the Node.js 24 base image to pin dependencies and OS-level packages in a repeatable way.

Why it matters right now

Two hard timelines collide here. Node 24 is Active LTS through October 2026 and receives security fixes until April 2028. Node 18 already hit end-of-life on April 30, 2025. Node 22 moves into maintenance and exits security support in April 2027. If you’re on 18 anywhere, you’re out of runway; if you’re on 20/22, this is the strategic moment to consolidate on a fresh LTS with three more years of security coverage.

Zooming out: Node 24 also modernizes the platform—V8 13.x, npm 11, improved AsyncLocalStorage defaults, a maturing permission model, and expanded Web APIs (like a global URLPattern). Those aren’t academic details; they influence performance, observability, and attack surface across your serverless estate.

Do I have to rewrite my handlers?

Yes—if you still use callbacks. The migration is straightforward. Replace this pattern:

exports.handler = (event, context, callback) => {\n doWork(event, (err, result) => {\n if (err) return callback(err);\n callback(null, result);\n });\n};

With async/await:

export const handler = async (event) => {\n const result = await doWork(event);\n return result;\n};

Most projects can search for callback usage, update signatures, and remove branching that summons context.done. If you’ve wrapped the handler (for logging, tracing, or auth), make sure the wrapper returns a Promise and propagates rejections correctly.

Primary impacts from the Node 24 platform

Node 24 brings several changes you’ll feel in Lambda:

• npm 11 changes install behavior and performance characteristics. Regenerate lockfiles with the new runtime in CI, and re-test workspaces/monorepos to avoid subtle shifts.
• AsyncLocalStorage default moved to an AsyncContextFrame-based implementation. That’s good for tracing and context propagation, but compare logs/traces between Node 22 and 24 before and after to catch behavioral edge cases in custom instrumenters.
• Web APIs and Undici updates tighten HTTP, fetch, and URL handling. If you rolled your own fetch shims, remove them and standardize on the built-in.
• Permission model is no longer just experimental. If you want stricter runtime constraints in Lambda, you can pass Node flags via NODE_OPTIONS or use a wrapper script—carefully.

AWS Lambda Node.js 24: a no-surprises migration checklist

Let’s get practical. This is the sequence we use on real teams to keep rollouts boring (in a good way).

1. Inventory functions and versions. Export a list of Lambdas using Node 18/20/22. Include memory, timeout, Layers, and triggers. Tag ones with callback handlers or legacy middleware.
2. Create a staging environment on Node 24. Duplicate configuration with the new runtime. If you use images, rebuild from the 24 base. Keep IAM roles identical.
3. Update handlers to async. Remove callbacks, return Promises, and ensure wrappers/middleware are async-aware. Write a codemod for common patterns to speed this up.
4. Refresh dependency graphs. Reinstall with npm 11, regenerate lockfiles, and rebuild native modules (if any) against Node 24. Check your Layers—pin versions built for 24.
5. Re-run tests and tracing. Confirm that AsyncLocalStorage-based tracing still correlates requests correctly. Compare logs/traces between 22 and 24 for a high-traffic endpoint.
6. Evaluate permissions (optional, advanced). If you enable the Node runtime permission model, pass flags via NODE_OPTIONS and explicitly allow what you need (env, network, fs). Start with read-only FS and AWS SDK network calls to known endpoints. Validate that DNS, TLS, and any native add-ons still operate within constraints.
7. Bundle and size-check. Keep cold-starts honest: tree-shake, avoid bundling the AWS SDK v3 clients you don’t use, and compress static assets in Layers. Package size and init code paths still dominate cold start more than the minor runtime version differences.
8. Canaries and progressive rollout. Shift a small percentage of traffic to the Node 24 alias, watch error budgets, then ramp. Use provisioned concurrency where latency SLOs are tight.
9. Edge traffic audit. For CloudFront behaviors that call Lambda@Edge, upgrade those functions and confirm the Regions that host them. Evaluate whether some logic belongs in CloudFront Functions instead.

People also ask: common questions we’re getting

Is Node 24 supported in all AWS Regions?

Yes. The managed runtime is available globally, including GovCloud and China. That removes the most common rollout blocker for regulated workloads.

Does Lambda@Edge support Node 24?

Yes, in the Regions where Lambda@Edge supports the runtime family. Treat this as a separate rollout: update your edge functions, publish versions, and attach to CloudFront behaviors with care.

Can I enable Node 24’s permission model in Lambda?

You can. Use NODE_OPTIONS to pass --permission and specific allow flags (for example, --allow-net and tightly scoped --allow-fs-read). But there’s a catch: over-constrain and you’ll break things like DNS, TLS, and native modules. Start conservative, monitor, and widen only as needed.

Will Node 24 improve cold starts?

Not magically. Cold-start time is dominated by package size, initialization work, and VPC attachment. Node 24 doesn’t regress, and the platform improvements help, but the big wins still come from smaller bundles, fewer top-level awaits, and provisioned concurrency for latency-critical paths.

Edge, caching, and blast radius

Whenever you change a runtime, revisit your edge and caching strategy. If you’ve pushed logic into the CDN, confirm behavior parity after the upgrade. Also check your fallbacks for upstream timeouts or elevated 5xx at origin. If last year’s outages taught anything, it’s that graceful degradation beats wishful thinking. Our resilience notes from the big incidents still apply—read the Cloudflare outage resilience playbook and make sure your API timeouts, retries, and circuit breakers match the new runtime’s behavior.

For SSR and Next.js teams

Running Next.js on Lambda (or behind API Gateway/ALB) will feel the Node 24 changes too. Start by aligning your framework version and tooling. If you’re eyeing the latest framework release, see our Next.js 16: No‑Surprises Upgrade Playbook for a calm, ordered process. In practice, Node 24’s improved fetch and AsyncLocalStorage help when you have complex data fetching and tracing in SSR/ISR routes, but you still need to mind bundle size and cold starts.

Security and supply chain: npm 11, tokens, and CI

Node 24 ships with npm 11. Regenerate lockfiles and review any scripts that assume npm 8–10 behavior. If your CI uses organization tokens for private registries, double-check scopes, token types, and expirations. We’ve seen too many upgrades stall because a pipeline token quietly expired or lost scope. If your team recently worked through registry auth changes, you’ll recognize the playbook—here’s ours for reference: npm token migration playbook and the follow-up CI fix checklist.

Data-backed snapshot: timelines and versions

Dates matter more than vibes. Here’s the concise view your CTO will ask for:

• Lambda added Node.js 24 on November 25, 2025 (managed runtime and base image).
• Node.js 24 entered Active LTS in late October 2025; security support runs through April 2028.
• Node.js 18 reached end-of-life on April 30, 2025; Node 22 remains in maintenance with security updates until April 2027.
• Lambda@Edge supports the Node 24 runtime in supported Regions; verify attachments per distribution.

Risk and edge cases you should plan for

Every upgrade nudges a few cobwebs:

• Legacy middleware/wrappers. Anything relying on a callback signature will misbehave. Wrap them in util.promisify or refactor.
• Native module rebuilds. If you package native add-ons (image processing, crypto), rebuild against Node 24 and pin the artifact in your Layer or image.
• Permission model gotchas. Enabling --permission without the right allowlist can block DNS, TLS, child processes, or WASI. Start in staging, log failures with the runtime’s permission diagnostics, and add allowances incrementally.
• Lockfile churn. npm 11 can change the lockfile format and selection logic. Update your CI caching and diffs so you aren’t drowning in noisy PRs.

How to structure the rollout (framework you can steal)

Use this simple framework to coordinate across engineering, DevOps, and product:

1. Scope — Agree on the set of functions moving to Node 24 in this wave (e.g., top 10% by traffic plus all Node 18 stragglers). Document owners.
2. Stabilize — Build staging with the new runtime, update handlers, regenerate lockfiles, and fix tests. Attach enhanced logging for permission denials if you’re testing --permission.
3. Simulate — Run synthetic traffic and replay a slice of prod requests. Compare p50/p95 latency and error rates to baseline.
4. Ship — Use weighted aliases to roll out progressively. Announce the change in your status channel and watch dashboards.
5. Simplify — After cutover, delete dead code paths, remove callback utilities, and prune unused dependencies to keep cold start lean.

What about costs?

The runtime itself doesn’t change Lambda pricing, but cleaner async handlers and smaller bundles can reduce duration and memory settings. If this upgrade prompts a broader rethink of where your compute runs (serverless vs containerized services at the edge), we’ve written about cost levers in adjacent stacks—see our take on container CPU pricing and when to flip switches to save money: Cloudflare containers pricing switch. Different provider, same mindset: measure, then change one variable at a time.

What to do next

• Put it on the roadmap this week. Create a ticket for “Migrate top-traffic Lambdas to Node 24.” Assign owners.
• Stand up a staging stack. Same IAM, new runtime. Flip one function and run synthetic traffic.
• Codemod callbacks. Replace handler signatures and promisify old utilities. Commit the diff as a separate PR for clean review.
• Regenerate lockfiles with npm 11. Rebuild layers/images. Run security scans and npm audit.
• Decide on permissions. Either defer, or pilot --permission on a low-risk function with tight observability.
• Plan the edge update. If you use Lambda@Edge, schedule a separate rollout and validation across cache behaviors.
• Need a hand? We help teams ship upgrades without drama—see what we do, browse our client results, or ping us via contact.

The bottom line

AWS Lambda Node.js 24 gives you a long, stable runway and a cleaner programming model. The migration work is real but tractable: update handler signatures, refresh dependencies, validate tracing, and be deliberate if you opt into the permission model. Do that, and you’ll bank years of security coverage and a better developer experience—without breaking your latency budgets or your weekend.

If you want a sounding board for your specific stack—legacy handlers, Layers, Next.js SSR on API Gateway, or aggressive cost targets—reach out. We’ve helped teams plan and ship these upgrades many times. Start the conversation on our services page or just say hello via bybowu.com/contacts.