DEV Community: ntoledo319

"error:0308010C:digital envelope routines::unsupported — why Lambda runtime upgrades break your webpack build"

ntoledo319 — Mon, 13 Jul 2026 07:17:03 +0000

If you just bumped your CI pipeline — or your Lambda runtime — to Node.js 18 or 22 and your build step died, this is the wall:

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)

The stack trace points into webpack, react-scripts, or Jest. Your Lambda handler code is untouched. Here is why the runtime label change triggers a build failure.

The cause in two sentences

Node.js 17 switched from OpenSSL 1.1.1 to OpenSSL 3.0. Every Node.js version since — 18, 20, 22 — runs OpenSSL 3. OpenSSL 3 puts legacy algorithms including MD4 into a disabled-by-default "legacy provider." Webpack 4 calls crypto.createHash('md4') to fingerprint chunk content. On Node.js 18+, OpenSSL 3 refuses that call and throws ERR_OSSL_EVP_UNSUPPORTED, which surfaces as the 0308010C error.

Why Lambda teams hit this at runtime-upgrade time

The error lives in your build step, not inside the Lambda execution environment. The two are linked because of the deprecation schedule:

nodejs16.x — the last Lambda runtime on OpenSSL 1.1 — is on the deprecation path. Teams moving to nodejs18.x or nodejs22.x naturally update their CI Node version to match.
The Lambda runtime itself runs your handler fine. OpenSSL 3 does not break ES modules, async/await, or standard crypto like AES-256-GCM or SHA-256.
It breaks build tooling calling createHash('md4') — tooling that runs on your CI machine, not inside Lambda. The runtime upgrade triggers the CI upgrade, which triggers the build failure.

Which Node.js version ships which OpenSSL:

Lambda runtime	Node.js	OpenSSL	`createHash('md4')`
nodejs16.x	16.x	1.1.1	Works
nodejs18.x	18.x	3.0	Fails
nodejs20.x	20.x	3.0	Fails
nodejs22.x	22.x	3.0	Fails

Fix 1 — upgrade webpack or react-scripts (durable)

Webpack 5 replaced the MD4 call with its own pure-JavaScript xxhash64 implementation that does not touch OpenSSL at all.

# webpack-only project
npm install --save-dev webpack@5 webpack-cli@5

# Create React App / react-scripts
npm install --save-dev react-scripts@5

If you cannot upgrade webpack itself, override the hash function in webpack.config.js:

module.exports = {
  output: {
    hashFunction: 'sha256',
  },
};

SHA-256 is in OpenSSL 3's default provider, so this works on all supported Node.js versions without any environment variable changes.

For projects using Jest, the MD4 call was removed from jest-haste-map in 27.4.2. Upgrade your Jest version if the trace points there.

Fix 2 — re-enable the legacy provider (stopgap only)

If you cannot touch the tooling today, set NODE_OPTIONS before running your build:

# .env / CI environment variable
NODE_OPTIONS=--openssl-legacy-provider

# Or inline in package.json scripts
"build": "NODE_OPTIONS=--openssl-legacy-provider react-scripts build"

In a Dockerfile building a Lambda deployment package:

RUN NODE_OPTIONS=--openssl-legacy-provider npm run build

Do not leave this in place permanently. The flag re-enables deprecated algorithms across the entire Node.js process. It is also subject to removal in a future OpenSSL release, meaning it will silently stop working and break the build again.

Confirm no legacy crypto calls remain

After the fix, verify clean with:

# Should print nothing OpenSSL-related
node --trace-deprecation -e "const w = require('webpack'); w({}, () => {})" 2>&1 | grep -i openssl

Check the Lambda runtime version you are targeting:

aws lambda get-function-configuration \
  --function-name <your-function-name> \
  --query Runtime

The pattern to internalize

This error is not a crypto vulnerability — it is a dependency age signal. Webpack 4 and react-scripts 4 were released in 2020. The projects that hit this error in 2026 are the same ones that will hit node-module-version-mismatch (native addons), Cannot find module 'aws-sdk' (SDK v2 removal), and crypto.createCipher is not a function (removed in Node.js 22). An OpenSSL 3 error is a useful proxy for "this build pipeline has not been reviewed since the nodejs16.x era."

Fix the hash function, then audit the rest of the dependency tree before your next Lambda runtime deadline.

Not sure which of your Lambda functions are still on deprecated runtimes or blocked SDKs? Run a free EOLkits scan — it maps every function to its runtime deprecation date and flags the issues before AWS does.

"Error: Cannot find module 'aws-sdk'" on Lambda — migrating to @aws-sdk v3

ntoledo319 — Mon, 06 Jul 2026 07:17:03 +0000

If you upgraded a Lambda function from nodejs16.x to nodejs18.x (or nodejs20.x / nodejs22.x) and your logs now show:

Runtime.ImportModuleError: Error: Cannot find module 'aws-sdk'

you're not missing a locally installed package. AWS deliberately stopped bundling it.

Why this happens

Until nodejs16.x, Lambda preinstalled aws-sdk v2 (require('aws-sdk')) in every Node.js runtime. It was free — zero deployment overhead, no package.json entry needed.

From nodejs18.x onwards AWS replaced it: only AWS SDK for JavaScript v3 (the @aws-sdk/* modular packages) is bundled. The monolithic aws-sdk v2 package is gone from the runtime environment entirely.

There is a second reason not to reach for the "just bundle v2" escape hatch: aws-sdk v2 reached end-of-support on September 8, 2025 and no longer receives security patches.

Fix A — Migrate to @aws-sdk v3 (durable)

v3 is modular: instead of one ~75 MB monolith, you install only the services you need. Each service lives in its own package.

Before (v2 — S3):

const AWS = require('aws-sdk');
const s3 = new AWS.S3({ region: 'us-east-1' });
const result = await s3.getObject({ Bucket: 'my-bucket', Key: 'file.json' }).promise();

After (v3 — S3):

const { S3Client, GetObjectCommand } = require('@aws-sdk/client-s3');
const s3 = new S3Client({ region: 'us-east-1' });
const result = await s3.send(new GetObjectCommand({ Bucket: 'my-bucket', Key: 'file.json' }));

Three things change in every service:

Import the specific Client and Command classes from @aws-sdk/client-<service>
Wrap parameters in a Command object and pass it to client.send(...)
Drop .promise() — v3 returns native promises directly

DynamoDB DocumentClient (before / after):

// v2
const doc = new AWS.DynamoDB.DocumentClient();
const res = await doc.get({ TableName: 'users', Key: { id: '123' } }).promise();

// v3
const { DynamoDBClient } = require('@aws-sdk/client-dynamodb');
const { DynamoDBDocumentClient, GetCommand } = require('@aws-sdk/lib-dynamodb');
const client = DynamoDBDocumentClient.from(new DynamoDBClient({ region: 'us-east-1' }));
const res = await client.send(new GetCommand({ TableName: 'users', Key: { id: '123' } }));

For DynamoDB, @aws-sdk/lib-dynamodb is the high-level v3 equivalent of DocumentClient. It marshals/unmarshals attribute types, so the call-site feels similar.

Automate the mechanical rewrites with codemod

AWS ships a codemod that handles most of the straightforward conversions:

npm install -g aws-sdk-js-codemod

# Single file
npx aws-sdk-js-codemod -t v2-to-v3 src/handler.js

# Whole project
npx aws-sdk-js-codemod -t v2-to-v3 'src/**/*.js'

The codemod is reliable on simple patterns. Review the diff: dynamic service selection, callback-style calls, and chained middleware usually need manual cleanup.

Fix B — Bundle aws-sdk v2 in your package (stopgap only)

If you cannot migrate immediately:

{
  "dependencies": {
    "aws-sdk": "^2.1692.0"
  }
}

Include node_modules in your deployment ZIP or a Lambda layer. This unblocks deploys but adds ~25 MB of cold-start weight and leaves your functions on an end-of-support library. Treat it as a bridge, not a destination.

What if the error comes from a dependency, not your code?

Run npm ls aws-sdk to find who imports it transitively. Most major packages (Amplify, CDK custom resources, Middy middleware) have published v3-compatible versions — upgrade first. If no upgrade exists, Fix B applies at the layer level until an upstream fix lands.

Scan before you flip the runtime

Before changing nodejs16.x → nodejs18.x across your stack, find every v2 import:

grep -r "require('aws-sdk')\|require(\"aws-sdk\")\|from 'aws-sdk'" src/

Any hit needs to be migrated or bundled before the runtime label changes, or the function will fail its first invocation.

Bundler gotcha: esbuild 0.22+

If you use esbuild to package your functions (SAM's default from v1.x), note that esbuild 0.22+ changed its default to treat node_modules as external — meaning even if you add aws-sdk to package.json, esbuild may exclude it from the ZIP. Force bundling:

# SAM template.yaml
Metadata:
  BuildMethod: esbuild
  BuildProperties:
    Packages: bundle

Or with the CLI flag: esbuild --packages=bundle.

Every deprecated Lambda runtime across your account — including every function still wired to nodejs16.x — shows up in a free EOLkits scan. Run it before the next deploy, not after: eolkits.com/scan

Python 3.13 on AWS Lambda — cgi, telnetlib, crypt, lib2to3 removed (PEP 594)

ntoledo319 — Mon, 29 Jun 2026 07:17:03 +0000

AWS Lambda launched the python3.13 runtime in November 2024 — Amazon Linux 2023, Python 3.13.x, LTS support through October 2029. If you're still on python3.9 or python3.10, the create-block deadline hits 2027-02-01; python3.11 create-blocks at 2027-07-31. Many teams are jumping straight to python3.13 to bank the longest runway.

What bites them isn't the runtime label change. It's PEP 594 — the "dead batteries" cleanup that deprecated 19 stdlib modules in Python 3.11 (warnings only) and deleted all of them in Python 3.13. Cold start, hard crash, ModuleNotFoundError. Here are the four that actually appear in Lambda functions and their transitive dependencies.

`ModuleNotFoundError: No module named 'cgi'`

The cgi and cgitb modules are gone in Python 3.13.

# Breaks on python3.13
from cgi import parse_qs, FieldStorage, escape
import cgitb; cgitb.enable()

Fixes:

cgi.parse_qs / cgi.parse_qsl → urllib.parse.parse_qs / urllib.parse.parse_qsl
cgi.escape → html.escape
Multipart form parsing (FieldStorage) → multipart library, or your framework's built-in (werkzeug.formparser, starlette.requests.Request.form(), etc.)
Drop cgitb.enable() — use structured logging (logging.exception) instead

The most common place this surfaces in Lambda is a dependency that still imports cgi for query-string parsing — pip show -f <package> to locate it, then upgrade.

`ModuleNotFoundError: No module named 'telnetlib'`

import telnetlib  # removed in Python 3.13
tn = telnetlib.Telnet("host", 23)

Fixes:

Network/device automation: replace with telnetlib3 (asyncio-native, maintained) or Exscript.
Better: switch to SSH where the device supports it — paramiko or netmiko.
Pinning to python3.12 still includes telnetlib, but python3.12 itself will eventually deprecate — treat that as a stopgap, not a fix.

`ModuleNotFoundError: No module named 'crypt'`

The Unix password-hashing module was removed because its underlying algorithms (DES-crypt, MD5-crypt) are cryptographically broken and belong nowhere near new code.

import crypt
hashed = crypt.crypt("password", crypt.mksalt(crypt.METHOD_SHA512))

Fixes:

New password hashing: passlib (bcrypt, argon2-cffi) or hashlib.scrypt / hashlib.pbkdf2_hmac.
Verify existing crypt(3) hashes: passlib.hash.sha512_crypt.verify(password, stored_hash) — it implements the same crypt(3) schemes so you can verify old hashes during a migration window.
There is no stdlib drop-in replacement. Don't reach for hashlib.md5 — that's not a password hash.

This one shows up most often in provisioning scripts and user-management Lambda functions inherited from old EC2 tooling.

`ModuleNotFoundError: No module named 'lib2to3'`

lib2to3 (and the 2to3 command-line tool) were removed because the internal grammar couldn't track new Python syntax — it was itself becoming obsolete.

from lib2to3 import pygram, pytree  # gone in Python 3.13

Fixes:

Code parsing/transformation: LibCST or parso.
If this comes from a dependency (build tools, older linters, black < 24), upgrade it — modern versions have already removed the lib2to3 dependency.
For a one-off Python 2→3 migration: run 2to3 from a Python ≤ 3.12 environment before upgrading the runtime.

Grep your dependencies before deploying

PEP 594 removed 19 modules in total. The four above are the ones that appear in Lambda workloads, but also removed were: aifc, audioop, chunk, cgitb, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, uu, xdrlib.

A quick scan before you flip the runtime:

# Run from your virtualenv or package directory
python3.13 -c "
import importlib, sys
dead = ['cgi','cgitb','telnetlib','crypt','lib2to3','aifc','audioop',
        'chunk','imghdr','mailcap','nis','nntplib','ossaudiodev',
        'pipes','sndhdr','sunau','uu','xdrlib']
for m in dead:
    try:
        importlib.import_module(m)
        print(f'WARN: {m} somehow importable')
    except ModuleNotFoundError:
        pass
print('Scan complete')
"

Better yet, test your handler locally on a Python 3.13 environment before deploying to Lambda. The errors above are cold-start killers — they won't appear until the function is invoked.

Timeline recap

Runtime	Deprecated	Create blocked	Update blocked
`python3.9`	2025-12-15	2027-02-01	2027-03-03
`python3.10`	2026-03-31	2027-02-01	2027-03-03
`python3.11`	2027-06-30	2027-07-31	2027-08-31
`python3.12`	not yet deprecated	—	—
`python3.13`	not yet deprecated	—	—

Sources: AWS Lambda runtime deprecation table, Python 3.13 What's New, PEP 594.

The free EOLkits scanner detects deprecated Lambda runtimes and flags known packages that still import the removed modules — in your browser, nothing uploaded. Full per-error fixes and the migration deadline timeline: eolkits.com/migrate/lambda-python-3.11-eol.

Python 3.12 on AWS Lambda — distutils, imp, and collections are gone

ntoledo319 — Tue, 23 Jun 2026 07:17:03 +0000

AWS Lambda's python3.9, 3.10, and 3.11 runtimes are on the deprecation track; python3.12 (on Amazon Linux 2023) is the target. The runtime swap is one line — but Python 3.12 itself removed a pile of long-deprecated stdlib, so code that ran on 3.9 throws on import.

The removals you'll hit

ModuleNotFoundError: No module named 'distutils' — removed in 3.12 (PEP 632). Replace with setuptools + packaging (e.g. packaging.version.Version instead of distutils.version.LooseVersion). Interim: pip install 'setuptools<81' (still vendors a shim).

ModuleNotFoundError: No module named 'imp' — removed in 3.12. Use importlib (importlib.util.find_spec, import_module).

AttributeError: module 'collections' has no attribute 'Mapping' — the ABCs moved to collections.abc (removed from collections in 3.10). from collections.abc import Mapping.

DeprecationWarning: datetime.datetime.utcnow() is deprecated — use datetime.now(datetime.timezone.utc).

The one that isn't in your code

/lib64/libc.so.6: version `GLIBC_2.28' not found

Native wheels (cryptography, numpy, pydantic-core…) link against the glibc of the box that built them. AL2 runtimes ship glibc 2.26; AL2023 (python3.12) ships 2.34. Build for the target: pip install --platform manylinux2014_x86_64 --only-binary=:all: --target ./package <pkg>, or build inside public.ecr.aws/lambda/python:3.12. Match the arch (x86_64 vs arm64) too.

When AWS blocks you

The runtime parameter of python3.9 is no longer supported for creating or updating AWS Lambda functions

That's the block date. Set Runtime: python3.12 (SAM/CFN), lambda.Runtime.PYTHON_3_12 (CDK), or runtime = "python3.12" (Terraform), fix the imports above, redeploy.

The free EOLkits scanner flags every deprecated runtime and the dependency breaks above from your requirements.txt / pyproject.toml / IaC — in your browser, nothing uploaded. There's an MIT CLI (python-pivot) that codemods most of it, and a hash-anchored audit if you want it scored and done for you.

Cited deadlines + per-error fixes: eolkits.com/migrate · eolkits.com/fix

Migrating AWS Lambda from Node.js 20 to 22 — every breaking change

ntoledo319 — Mon, 22 Jun 2026 21:11:30 +0000

AWS deprecates Lambda runtimes on a 3-phase schedule: Phase 1 ends security patches, Phase 2 blocks creating new functions, Phase 3 blocks updating existing ones. Once Phase 3 hits, a frozen function's only path forward is a full redeploy on a new runtime. nodejs20.x is on that track; nodejs22.x is the target (LTS, maintained into 2027).

Most code moves cleanly. Here's the set that doesn't.

1. `aws-sdk` v2 is no longer bundled

On nodejs16.x and earlier, AWS preinstalled the v2 SDK. From nodejs18.x onward, only v3 (@aws-sdk/*) is bundled. So:

Error: Cannot find module 'aws-sdk'

Fix: migrate to modular v3 clients, e.g. const { S3Client } = require('@aws-sdk/client-s3'). v3 also returns promises directly (no .promise()), and response shapes differ. Quick unblock: bundle aws-sdk in your package (adds cold-start weight).

2. Import assertions → import attributes

Node 22 ships the finalized spec, which renamed assert to with:

// Node 20 (valid)  -> Node 22 (broken)
import cfg from './config.json' assert { type: 'json' };
// Node 22 (valid)
import cfg from './config.json' with { type: 'json' };

3. Native addons must be rebuilt

Error: The module was compiled against a different Node.js version using NODE_MODULE_VERSION

Native modules (sharp, bcrypt, better-sqlite3…) are tied to the Node ABI. Rebuild on the target version, or bump to a release with a Node 22 prebuild. Dead packages (node-sass, fibers) must be replaced.

4. OpenSSL 3

Node 17+ ships OpenSSL 3, which rejects legacy hashing some older tooling relies on:

Error: error:0308010C:digital envelope routines::unsupported

Fix: upgrade the tool (webpack 5, react-scripts 5+). --openssl-legacy-provider is a stopgap only.

5. `crypto.createCipher` removed

crypto.createCipher / createDecipher were removed in Node 22 — switch to createCipheriv with an explicit key + IV (scrypt/pbkdf2 + randomBytes).

I wrote an open-source CLI (lambda-lifeline) that scans for all of these, codemods what's mechanical, patches your IaC, and stages a canary with rollback — plus a free browser scanner that flags them in your config in ~30 seconds, nothing uploaded: eolkits.com/scan.

Full guide with every case + captured output: eolkits.com/blog/migrating-lambda-nodejs-20-to-22

Amazon Linux 2 is EOL on June 30, 2026 — here's everything that breaks

ntoledo319 — Mon, 22 Jun 2026 21:10:09 +0000

Amazon Linux 2 reaches end of life on June 30, 2026. After that: no security patches, no new AMIs, no extras updates. Anything still pinned to AL2 in a launch template, EKS node group, ECS task, Beanstalk platform, or container base image is running unpatched from that day on.

Here's what actually changes when you move to Amazon Linux 2023 — the stuff that breaks boot scripts and CI.

What changes on AL2023

Area	Amazon Linux 2	Amazon Linux 2023
Package manager	`yum`	`dnf` (a `yum` symlink remains)
Extras	`amazon-linux-extras`	removed — packages are default, version-namespaced (`python3.11`, `nginx1.24`), or in SPAL
Time sync	`ntpd`	`chronyd`
Firewall	`iptables`	`nftables`
Python	2.7 and 3.x	3.x only — no Python 2
glibc	2.26	2.34

The errors you'll hit (and the fix)

amazon-linux-extras: command not found — it doesn't exist on AL2023. Install directly with dnf, version-namespaced, or via SPAL.
Failed to start ntpd.service: Unit ntpd.service not found — use chronyd instead.
/usr/bin/env: 'python2': No such file or directory — there's no Python 2; port the script to python3.
Error: Unable to find a match: <package> — the package was renamed/version-namespaced/moved to SPAL. dnf search for the real name.

The migration checklist

Inventory every AL2 AMI, launch template, EKS node group, ECS task, Beanstalk platform, and container base image.
Rebuild the base AMI on AL2023 (Packer / EC2 Image Builder).
Package manager: move yum usage to dnf, drop amazon-linux-extras.
Services: ntpd → chronyd, iptables → nftables.
Python: port python2 scripts/shebangs to python3.
Test boot, app start, networking, and time sync on a canary.
Roll out staged (5 → 25 → 50 → 100%) with a tested rollback.

I got tired of grepping for this by hand, so I built a free scanner — drop your Terraform / CloudFormation / Packer / Ansible into the browser and it flags every AL2 reference and the errors above, with the AWS source for each. Nothing is uploaded. Try it free → eolkits.com/scan. There's also an MIT CLI that does the codemods, and a paid audit if you want it done for you.

Full checklist with the per-error fixes: eolkits.com/amazon-linux-2-eol-checklist

DEV Community: ntoledo319

"error:0308010C:digital envelope routines::unsupported — why Lambda runtime upgrades break your webpack build"

The cause in two sentences

Why Lambda teams hit this at runtime-upgrade time

Fix 1 — upgrade webpack or react-scripts (durable)

Fix 2 — re-enable the legacy provider (stopgap only)

Confirm no legacy crypto calls remain

The pattern to internalize

"Error: Cannot find module 'aws-sdk'" on Lambda — migrating to @aws-sdk v3

Why this happens

Fix A — Migrate to @aws-sdk v3 (durable)

Automate the mechanical rewrites with codemod

Fix B — Bundle aws-sdk v2 in your package (stopgap only)

What if the error comes from a dependency, not your code?

Scan before you flip the runtime

Bundler gotcha: esbuild 0.22+

Python 3.13 on AWS Lambda — cgi, telnetlib, crypt, lib2to3 removed (PEP 594)

ModuleNotFoundError: No module named 'cgi'

ModuleNotFoundError: No module named 'telnetlib'

ModuleNotFoundError: No module named 'crypt'

ModuleNotFoundError: No module named 'lib2to3'

Grep your dependencies before deploying

Timeline recap

Python 3.12 on AWS Lambda — distutils, imp, and collections are gone

The removals you'll hit

The one that isn't in your code

When AWS blocks you

Migrating AWS Lambda from Node.js 20 to 22 — every breaking change

1. aws-sdk v2 is no longer bundled

2. Import assertions → import attributes

3. Native addons must be rebuilt

4. OpenSSL 3

5. crypto.createCipher removed

Amazon Linux 2 is EOL on June 30, 2026 — here's everything that breaks

What changes on AL2023

The errors you'll hit (and the fix)

The migration checklist

`ModuleNotFoundError: No module named 'cgi'`

`ModuleNotFoundError: No module named 'telnetlib'`

`ModuleNotFoundError: No module named 'crypt'`

`ModuleNotFoundError: No module named 'lib2to3'`

1. `aws-sdk` v2 is no longer bundled

5. `crypto.createCipher` removed