Creating a lambda function in AWS from zip file
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
AWS Lambda still supports deployment packages as .zip archives, and for many small to medium functions that is the simplest packaging model. The basic workflow is to package your handler code and dependencies into a zip file, then create the function with the correct runtime, handler name, and IAM execution role.
When a Zip Package Is the Right Choice
Lambda supports both container-image deployments and .zip archives. A zip package is usually the better choice when:
- the function is relatively small
- the runtime is one of Lambda’s standard managed runtimes
- you want a fast, familiar packaging workflow
If the dependency set becomes very large or the build process is highly custom, a container image may be a better fit.
A Minimal Python Example
Create a simple handler file named lambda_function.py.
The handler string for this file is lambda_function.lambda_handler, which means module_name.function_name.
Build the Zip Package
Package the handler file from the directory that contains it.
If the function has dependencies, install them into a build directory first and zip the whole directory so the libraries sit next to the handler code at the package root.
That layout matters. Lambda expects the handler module to be at the correct location inside the archive.
Create the Function with the AWS CLI
You need an execution role ARN before creating the function. Once that exists, create the Lambda function from the zip archive.
The CLI uploads the archive and registers the function configuration in one step.
Updating the Function Later
Once the function exists, code updates are separate from configuration updates.
If you also need to change runtime, environment variables, timeout, or memory, use update-function-configuration separately.
Native Dependencies and Build Environment
One of the most common Lambda packaging mistakes is building dependencies on a machine that does not match the Lambda execution environment closely enough. Pure Python dependencies are usually easy. Native extensions are not.
If your package includes compiled libraries, build them in an environment compatible with the Lambda runtime or use a deployment pipeline that produces Lambda-compatible artifacts. Otherwise the function may upload successfully but fail at import time.
Use Layers When It Helps
If several Lambda functions share the same dependency bundle, Lambda layers can reduce duplication. The handler zip can then stay focused on your application code while the shared dependency archive lives in a separate layer.
That is optional, not required. For small functions, a single deployment zip is often the cleanest setup.
Common Pitfalls
- Zipping the parent folder instead of the package contents can put the handler in the wrong path inside the archive.
- Using the wrong handler string is a frequent creation-time mistake.
- Forgetting the execution role prevents the function from being created at all.
- Building native dependencies on an incompatible machine can cause runtime import failures.
- Mixing code updates and configuration changes mentally leads to confusing deploy steps.
Summary
- A Lambda zip deployment contains your handler code and any dependencies the function needs.
- The handler string must match the module and function inside the archive.
- Use
aws lambda create-functionfor the initial creation andupdate-function-codefor later code changes. - Keep the archive layout correct so Lambda can import the handler.
- Be careful with native dependencies, because upload success does not guarantee runtime compatibility.

