Main Ecosystems
HomePython CorePandas ReferenceNumPy ScientificFastAPI & PydanticDjango Enterprise
More Ecosystems
Environment & SetupRequests & HTTPAsyncIO ConcurrencyObject-Oriented OOPPyTorch Deep LearningScikit-Learn MLFlask FrameworkWeb ScrapingDatabase & ORMDevOps & Docker

AWS Lambda Layer Pandas and NumPy Binary Dependency Error

Verified FixPython 3.10+Pandas 2.2+ / NumPy 1.26+Silo: pandas

Quick Fix / Solution Rapide

Package Lambda layers inside an Amazon Linux Docker container matching the Lambda architecture (x86_64 vs arm64) using pip install --platform manylinux2014_x86_64.

Root Cause Analysis

This error occurs when Python running inside an AWS Lambda function attempts to import pandas or numpy from an attached Lambda layer, but the compiled shared object libraries (.so files) were built for a different OS or processor architecture.

1. Local OS vs Amazon Linux ABI Incompatibility

Creating a zip file of site-packages on macOS or Windows and uploading it as a Lambda layer fails because AWS Lambda executes on Amazon Linux (Linux ELF format). macOS .dylib or Windows .dll binaries cannot be executed by the Linux dynamic linker.

2. Architecture Mismatch (x86_64 vs arm64 / Graviton2)

Configuring a Lambda function for arm64 while bundling x86_64 binary wheels (or vice-versa) causes ELF class dynamic linker crashes.

3. Incorrect Directory Structure Inside the Layer Zip

AWS Lambda expects Python layer packages to be located specifically inside a top-level python/ directory within the zip archive (e.g., python/pandas/). Placing files at the root of the zip archive prevents Python from discovering them on sys.path.

4. Size Limits and Uncompressed Zip Bloat

Unzipped Lambda layers exceeding the 250 MB quota will fail to deploy properly or experience truncated file extractions.

Reproduction Code (MCVE)

Example: Bug Reproduction
# **Note de reproductibilité :** Spécifique aux environnements cloud serverless AWS.
raise ImportError("Unable to import module 'lambda_function': No module named 'numpy.core._multiarray_umath' (ELF binary incompatible architecture)")

Solution 1: Build Layer in Matching Amazon Linux Docker Container

Use official AWS SAM or Amazon Linux Docker containers to download and package Linux-compatible wheels with the correct folder hierarchy.

Example: Recommended Solution
print('Build AWS Lambda Layer with Docker:')
print('docker run --platform linux/x86_64 -v "$(pwd)":/var/task \\')
print('    public.ecr.aws/sam/build-python3.12 \\')
print('    pip install pandas numpy -t /var/task/python')
print('# Then zip the python/ directory:')
print('zip -r pandas_layer.zip python/')

Solution 2: Use Pip Target Platform Flags Directly

Use pip's --platform and --only-binary flags on your local machine to download the correct Amazon Linux wheels without Docker.

Example: Alternative Solution
print('Direct pip download command for AWS Lambda (x86_64):')
print('pip install \\')
print('    --platform manylinux2014_x86_64 \\')
print('    --target ./python \\')
print('    --implementation cp \\')
print('    --python-version 3.12 \\')
print('    --only-binary=:all: --upgrade \\')
print('    pandas numpy')

A very frequent mistake is omitting the top-level python/ folder in the zip file. If your zip contains pandas/ directly at the root, AWS Lambda will mount it at /opt/ and Python will not find it without manual sys.path.append('/opt'). Always ensure the archive structure is layer.zip -> python/ -> pandas/. Another edge case is exceeding layer limits: combine NumPy and Pandas, strip .dist-info and tests, or use AWS Container Images for Lambda (Docker) if payloads exceed 250 MB. Contrast this error with RuntimeError: Resource limit exceeded, which occurs when Lambda memory limits are exceeded during runtime.