AWS Lambda: Runtime.InvalidEntrypoint (exec format error)
Lambda could not start the container image's entrypoint at all. When the detail says exec format error, the image was built for a different CPU from the function: an image built on an Apple silicon Mac is arm64, and a function created with the default x86_64 architecture cannot run it. The same image works with docker run on the machine that built it, which is why people go looking in their code. Less often the ENTRYPOINT script is not executable, or a custom base image lacks the runtime interface client.
Quick fix
Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.
# What architecture is the image?
docker image inspect my-func:latest --format '{{.Os}}/{{.Architecture}}'
# What architecture is the function?
aws lambda get-function-configuration --function-name my-func --query Architectures
# Rebuild for the function, as a single image without an attestation index
docker buildx build --platform linux/amd64 --provenance=false -t my-func:latest --load .
# Or switch the function to match an arm64 image
aws lambda update-function-code --function-name my-func --image-uri <ecr-uri> --architectures arm64
# Test locally under the platform Lambda will use
docker run --rm --platform linux/amd64 -p 9000:8080 my-func:latest
curl -s -XPOST http://localhost:9000/2015-03-31/functions/function/invocations -d '{}'How to diagnose Serverless errors
Serverless errors are shaped by hard platform limits: execution duration, deployment package size, memory, and concurrency. Unlike a server you control, these cannot be tuned away. The fix is to restructure the workload. VPC-attached functions add a second class of problem, because they lose default internet access and depend on ENI capacity and NAT configuration.
If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.
- Check the platform limit before changing code: timeout, package size and memory are all documented, and the error is usually the limit being reported literally.
- For timeouts, add timing logs around each external call. A function that times out is nearly always waiting on one downstream dependency.
- Reduce package size with layers, tree-shaking, and by excluding dev dependencies and the provider SDK that the runtime already includes.
- For VPC functions with no internet access, confirm there is a NAT Gateway or the relevant VPC endpoints. A function in a private subnet cannot reach the public internet by default.
- Measure cold start separately from warm invocation in your metrics, and use provisioned concurrency only after confirming cold starts are the actual problem.
Tools worth reaching for
CloudWatch Logs Insightsaws lambda get-function-configurationX-Ray / distributed tracingsam local invoke
Authoritative references
Primary documentation for this error, worth reading before applying any fix in production.
Related Serverless errors
- API Gateway: {"message": "Endpoint request timed out"}API Gateway stopped waiting for the integration, which for REST APIs happens at 29 seconds by…
- AWS Lambda: ENI limit reached in VPCLambda functions in a VPC create ENIs (Elastic Network Interfaces) and the account or subnet…
- AWS Lambda: Internal server error, malformed Lambda proxy responseAPI Gateway received something it could not turn into an HTTP response. With proxy…
- AWS Lambda: Response payload size exceeded maximum allowed payload sizeSynchronous invocations have a fixed 6 MB limit on the response (and on the request), and it…
- AWS Lambda: Runtime exited with error: signal: killedThe function process was killed for exceeding its memory allocation. Lambda reports this…
- AWS Lambda: Runtime.HandlerNotFound: index.handler is undefined or not exportedLambda found and loaded the file named in the handler setting, but that file has no export…
- AWS Lambda: Runtime.ImportModuleErrorThe runtime could not load the handler module. Either the handler string does not match the…
- AWS Lambda: Runtime.UserCodeSyntaxError: Cannot use import statement outsideThe Node.js runtime decides whether your handler is an ES module or CommonJS from the file…
Browse other categories
- HTTP 494xx client errors, 5xx server errors, redirects, headers and protocol problems.
- JavaScript 42npm resolution, async pitfalls, hydration, memory limits and runtime type…
- Database 41Connections, deadlocks, constraints, replication and memory limits.
- AI 35Rate limits, context windows, GPU memory and model-serving failures.
- Network 35Refused connections, timeouts, resets, MTU problems and port exhaustion.
- Python 35Imports, virtual environments, encoding, concurrency and dependency conflicts.
- Kubernetes 34CrashLoopBackOff, ImagePullBackOff, OOMKilled, RBAC, scheduling and storage.
- Docker 27Daemon connectivity, disk space, image pulls, ports and architecture mismatches.
- System 26Disk space, systemd units, file descriptors, OOM killer and scheduled jobs.
- Cloud 25IAM permissions, quotas, service limits and credential failures.
- Security 25JWT validation, CSRF, OAuth grants, SELinux, SSH host keys and CSP.
- TLS 24Untrusted authorities, expiry, hostname mismatch, chains and cipher negotiation.
Something missing or wrong?
This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.