AWS Lambda (native dependency)

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

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

What it means

A native binary in your package needs a newer glibc than the Lambda runtime's base OS provides.

Why it happens

Native extensions (cryptography, numpy, pydantic-core, grpcio, psycopg2, plus Go/Rust binaries) link against the glibc of the machine that built them. Lambda's glibc is fixed by the runtime's base OS: Amazon Linux 2 runtimes (python3.9 and earlier, nodejs16 and earlier) ship glibc 2.26; Amazon Linux 2023 runtimes (python3.12+, nodejs18+) ship glibc 2.34. A wheel built on a newer box fails to import on an older AL2 runtime.

How to fix it

  1. Best fix: move the function to an AL2023-based runtime (python3.12 / nodejs20+ / nodejs22) whose glibc 2.34 satisfies modern wheels — this also gets you off the deprecated runtime.
  2. Build the dependency for the exact target: `pip install --platform manylinux2014_x86_64 --only-binary=:all: --target ./package <pkg>` (manylinux2014 = glibc 2.17, safe on both AL2 and AL2023).
  3. Or build inside the matching base image (`public.ecr.aws/lambda/python:3.12`) so the binary links the runtime's glibc.
  4. Match the architecture too — x86_64 vs arm64/Graviton wheels are not interchangeable.

Related deadline: Lambda Python 3.9 EOL — 2027-02-01.

Find every instance in your project

The free EOLkits scanner runs in your browser (nothing uploaded) and flags this and related breakages across your IaC and dependency files.

Primary source: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

Get the full migration audit — $299, hash-anchored PDF →