AWS `Runtime.ImportModuleError`: What It Means and How to Fix It

Runtime.ImportModuleError is the Lambda runtime failing to load your handler — a packaging or path problem, not a code bug. It comes from Lambda, and the message reads:

Unable to import module ‘lambda_function’: No module named ‘requests’

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference

Error	Runtime.ImportModuleError
Service	Lambda
Message	Unable to import module ‘lambda_function’: No module named ‘requests’
Most common cause	A dependency is not in the deployment package

What it actually means

Lambda could not import the module named in the handler configuration. The error fires before any of your code runs, which is why there is no stack trace from your application.

The handler string has the form file.function: lambda_function.lambda_handler means “a file named lambda_function.py at the root of the deployment package, containing a function named lambda_handler”. Both halves have to be exactly right, and “at the root” is where most packaging mistakes show up.

Why it happens

Ranked by how often each one turns out to be the answer.

#	Cause	Fix
1	A dependency is not in the deployment package	Lambda runtimes include the AWS SDK and the standard library, and nothing else. requests, pydantic, numpy — anything third-party has to be bundled or supplied by a layer.
2	The zip has a wrapping directory	Zipping the folder rather than its contents puts everything one level down. cd build && zip -r ../fn.zip . — not zip -r fn.zip build/.
3	The handler string does not match the filename	A file named main.py with a handler configured as lambda_function.lambda_handler fails here.
4	A native dependency built on the wrong platform	Packages with compiled extensions — psycopg2, numpy, cryptography — must be built for Amazon Linux on the right architecture. A wheel built on macOS or for x86 on an arm64 function will not import. Build in a container matching the runtime, or use the platform flags in pip install.
5	A layer mounted at the wrong path	Layers extract to /opt. Python expects python/ or python/lib/python3.12/site-packages/ inside the layer zip; Node expects nodejs/node_modules/.
6	Architecture mismatch	A function set to arm64 with an x86_64 build, or the reverse.

How to tell which one you have

# What is the handler actually set to, and what architecture?
aws lambda get-function-configuration --function-name my-function \
  --query '[Handler,Runtime,Architectures,Layers[].Arn]'

# Inspect the deployed package without redeploying.
aws lambda get-function --function-name my-function \
  --query 'Code.Location' --output text | xargs curl -s -o /tmp/fn.zip
unzip -l /tmp/fn.zip | head -30

That listing answers most cases immediately: look for the handler file at the root and the dependency directories beside it.

Preventing it

Build in a container that matches the runtime:

docker run --rm --entrypoint /bin/sh \
  -v "$PWD":/var/task public.ecr.aws/lambda/python:3.12 \
  -c "pip install -r requirements.txt -t /var/task/package"

Or specify the target explicitly:

pip install --platform manylinux2014_aarch64 --target ./package \
  --implementation cp --python-version 3.12 --only-binary=:all: -r requirements.txt

Better still, use container image packaging for anything with native dependencies — the image you test locally is byte-for-byte the one that runs.

Related errors

• Task timed out after N seconds — Lambda
• Lambda in a VPC cannot reach the internet — Lambda
• All AWS error references — the full index

---

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.