Lambda Layers and Deployment Packages

Lambda deployment packages must be self-contained—all dependencies (libraries, SDKs, binaries) must be included in the ZIP. This quickly inflates package size: a Python data science function with NumPy, Pandas, and SciPy can exceed 200 MB uncompressed. Every update to your function code requires re-uploading the entire bundle including unchanged libraries. Lambda Layers solve this by separating shared dependencies from your function code.

A Lambda Layer is a ZIP archive that contains libraries, custom runtimes, data, or configuration files. Layers are stored separately from your function code and mounted into the function's execution environment at /opt. Multiple functions can share the same layer—update the layer once and every function using it benefits. Each Lambda function can have up to 5 layers, and the combined unzipped size must stay under 250 MB.

To create a layer, package your dependencies in the correct directory structure for your runtime (e.g., python/lib/python3.12/site-packages/ for Python), compress to a ZIP, and publish it. Once published the layer gets a version ARN. Reference this ARN when attaching the layer to a function. A new version is created each time you update the layer; functions continue using the version they were configured with until you explicitly update them.

Add layers to a function using the --layers parameter when creating or updating a function. Lambda mounts all attached layers into /opt before the function starts. Python packages under /opt/python are automatically on the Python path; Node.js modules under /opt/nodejs/node_modules are automatically found. Your function code can import or require layer packages as if they were installed locally.

AWS publishes official layers you can use without building your own. Examples include the AWS Lambda Powertools layer (structured logging, tracing, feature flags), database driver layers, and the AWS Parameters and Secrets Lambda Extension layer for caching SSM/Secrets Manager values locally. Third-party vendors like Datadog and New Relic also publish public layers for their monitoring agents. Check the Serverless Application Repository and the Lambda console for available public layers.

Lambda Extensions run as separate processes alongside your function code within the same execution environment. They hook into Lambda lifecycle events (init, invoke, shutdown) to perform tasks like telemetry collection, security scanning, or configuration caching. Extensions are distributed as Lambda Layers. AWS provides the CloudWatch Lambda Insights extension and the AWS AppConfig extension; vendors provide custom monitoring agents as extensions.

Lambda supports two deployment formats:

• ZIP (up to 50 MB compressed, 250 MB unzipped): fast upload, supports layers, works with all runtimes.
• Container Image (up to 10 GB): stored in Amazon ECR, uses standard Docker tooling, no layer support, ideal for very large dependencies (ML models, large binaries).

Container images must implement the Lambda Runtime Interface (using the base images AWS provides) so Lambda knows how to invoke your handler.

Building and deploying a Lambda container image follows a standard container workflow: build with docker build, push to Amazon ECR, and reference the image URI when creating or updating the Lambda function. Container images are immutable—each image tag corresponds to a specific function version. Lambda caches container images in its infrastructure, so subsequent cold starts after the first are faster.

Lambda Versions are immutable snapshots of your function code and configuration. Every time you publish a version, Lambda freezes the deployment package, environment variables, and layers. Aliases are named pointers to specific versions—prod might point to version 5, staging to version 6. You can also use weighted aliases to route a percentage of traffic to a new version for canary deployments (e.g., 10% to v6, 90% to v5).

Layers are also versioned. When you publish a new layer version, existing functions continue using their pinned version until you update them. This means you can safely update a shared layer without breaking all functions simultaneously—roll out the new version incrementally. Eventually, deprecate old layer versions to reduce storage and maintenance burden. Lambda retains layer versions even if you delete them from the console, until no functions reference them.

Use Layers when your total unzipped size fits under 250 MB, you want to share dependencies across multiple functions, and you want fast iteration (update layer once, all functions benefit). Use Container Images when dependencies exceed 250 MB, you need to use custom base OS packages, you have existing Docker workflows, or you want to bundle large assets (ML models, reference databases). Container images are not compatible with Lambda Layers but offer greater flexibility.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Lambda Layers package shared dependencies separately from function code, reducing package size and enabling reuse across multiple functions, Container Images (up to 10 GB via ECR) are the right choice when dependencies exceed the 250 MB ZIP limit or when Docker workflows are already in use, and Versioning and Aliases enable immutable releases and canary deployments with weighted traffic splitting. Next up we explore Lambda@Edge and event-driven patterns.