When you upgrade a Lambda function's runtime, for example from Python 3.9 to Python 3.12 or from Node.js 16 to Node.js 18, you may encounter an unexpected error during a cold start: /lib64/libc.so.6: version `GLIBC_2.28' not found. The message indicates that a native library (such as a Python wheel or a .node addon) cannot be loaded because it was linked against a newer version of glibc than the one available on the runtime's base operating system. Your application code hasn't changed, but the runtime upgrade modifies the underlying compatibility layer. This issue is not a bug in your logic; it's a mismatch between the glibc version used to compile the binary and the version provided by the execution environment.
To understand the root cause, you need to look at the base images used by AWS Lambda. Older runtimes like Python 3.9 and Node.js 16.x run on Amazon Linux 2 (AL2), which includes glibc 2.26. Newer runtimes like Python 3.12 and Node.js 20.x use Amazon Linux 2023 (AL2023), which comes with glibc 2.34. When you install a dependency with a native extension —for example, cryptography, numpy, pydantic-core, grpcio or psycopg2— the binary is linked against the glibc of the machine where it was built. If your CI/CD pipeline uses a modern runner with a recent glibc (such as Ubuntu 22.04 with glibc 2.35) and you download a manylinux_2_28 wheel, that binary will request GLIBC_2.28, which does not exist on AL2. The result is an import-time error that only appears when the Lambda container starts from scratch, i.e., during a cold start.
This failure most often occurs during partial runtime migrations. Imagine your AWS account has Lambda functions spread across old and new runtimes. A team updates the continuous integration pipeline to build dependency packages using an AL2023 base image or a runner with modern glibc. Functions still running on AL2 start failing on the next deployment, even though their code hasn't changed. The impact can be severe: production service interruptions, difficult-to-debug errors, and loss of confidence in the upgrade process.
The definitive solution is to complete the migration to an AL2023-based runtime, such as Python 3.12 or Node.js 20.x onward. Doing so provides glibc 2.34, which is sufficient for any modern wheel. Furthermore, you get ahead of AWS deprecation policies: older runtimes have scheduled block windows, and keeping functions on them poses security and availability risks. If you need to keep a function on an older runtime temporarily for compatibility or roadmap reasons, you can force dependency builds targeting the manylinux2014_x86_64 platform, which requires glibc 2.17 at minimum. That binary will run on both AL2 (glibc 2.26) and AL2023 (glibc 2.34). For example, use pip install --platform manylinux2014_x86_64 --only-binary=:all: --target ./package . You can also build inside the exact runtime base image using Docker: docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. This method guarantees that binaries are linked against the same glibc they will encounter in production.
Don't forget to check processor architecture. Lambda functions can run on x86_64 or arm64 (Graviton). A binary compiled for the wrong architecture will produce a different but equally opaque error. Ensure your pipeline uses the correct platform and architecture: manylinux2014_aarch64 for arm64, for example. In enterprise environments managing dozens or hundreds of Lambda functions, detecting these issues before they reach production is critical. A recommended practice is to perform cold start tests locally using the same base image you deploy: docker run public.ecr.aws/lambda/ .... You can also audit your functions looking for native dependencies that may cause glibc conflicts. Cloud risk analysis tools, like those we offer at Q2BSTUDIO, can scan your AWS account in seconds to identify functions with deprecated runtimes and potential ABI incompatibilities.
At Q2BSTUDIO we are a software development and technology company specialized in AWS and Azure cloud. We help our enterprise clients migrate serverless architectures safely, avoiding this kind of error through solid build and deployment practices. Our team integrates custom software solutions with a cloud-native approach, using artificial intelligence to automate anomaly detection and AI agents that monitor the health of your Lambda functions. Additionally, we combine these capabilities with cybersecurity services to protect your serverless environments, and with cloud solutions on AWS and Azure that ensure every deployment meets compatibility and performance requirements. We also offer Business Intelligence consulting with Power BI to analyze Lambda logs and anticipate incidents like the GLIBC 2.28 error. Our AI agents can even automatically suggest the most suitable runtime version for each function based on its dependency tree.
If you are in the middle of a runtime migration and encounter this error, remember it's not a code problem but an environment one. The cleanest fix is to finalize the migration to AL2023. If you need a temporary patch, build your dependencies with manylinux2014 or inside the correct base image. And to avoid surprises, automate cold start testing and compatibility auditing. At Q2BSTUDIO we accompany you through the entire process, from initial analysis to implementing a robust CI/CD pipeline that automatically manages glibc versions and architectures. Don't let a dynamic linking error stop your cloud innovation.
