This chapter covers Lambda Layers, Extensions, and Dependency Management in AWS Lambda. These topics are critical for the DVA-C02 exam, as they directly impact function packaging, code reuse, and operational tooling. Expect approximately 5-10% of exam questions to touch on these areas, often in the context of optimizing deployments, reducing function size, or integrating monitoring agents. You will learn how to structure layers for shared libraries, use extensions for runtime hooks, and manage dependencies efficiently to meet the 250 MB deployment package limit.
Jump to a section
Imagine a large library (the Lambda execution environment) that has a reference section with many books (Lambda Layers) and a special research desk that can call external archives (Lambda Extensions). Patrons (Lambda functions) can request books from the reference section, which are instantly available because they are already on the shelves. If a patron needs a rare manuscript, the research desk calls an external archive, waits for the document, and then hands it to the patron. However, the research desk can also perform other tasks while waiting, like organizing other requests (asynchronous extensions). The key is that the reference books are shared across all patrons, so if one patron brings a book, others can use it too. But patrons cannot change the reference books; they can only read them. The research desk, however, can update its own notes and even modify how it calls archives (init, invoke, shutdown phases). If the research desk takes too long, the library might close (Lambda timeout). The library also has a strict rule: no patron can bring their own books that are larger than 250 MB total, and the reference section can hold up to 5 layers. This system ensures that frequently used resources are quickly accessible, while rare resources are fetched on demand without slowing down everyday operations.
What Are Lambda Layers and Why Do They Exist?
Lambda Layers are a distribution mechanism for libraries, custom runtimes, and other function dependencies. They allow you to centrally manage common code across multiple functions, reducing duplication and speeding up deployments. Without layers, each function would need to include all dependencies in its deployment package, leading to larger packages, slower uploads, and wasted storage. Layers are extracted to the /opt directory in the Lambda execution environment, and the function code can access them just like any other file.
How Lambda Layers Work Internally
When you invoke a Lambda function that uses layers, the following occurs:
The Lambda service retrieves the function code and all specified layer versions.
It extracts the layer contents into the /opt directory in alphabetical order of layer ARN (if multiple layers are specified, later layers can override earlier ones).
The function code runs with the merged filesystem — the function's /var/task directory and the layers' /opt directory are both accessible.
The execution environment caches the combined package for reuse across invocations (if the same version is used).
Key points:
Layers are immutable after creation; you must create a new version to update.
A function can use up to 5 layers at a time.
The total unzipped size of all layers plus the function code cannot exceed 250 MB (temporary storage /tmp is separate, up to 512 MB to 10 GB depending on configuration).
Layer contents are read-only from the function's perspective.
Lambda Extensions: Purpose and Phases
Lambda Extensions are companion processes that augment Lambda functions. They run in the same execution environment but outside the function's runtime. Extensions are used for integrating monitoring, security, or other tooling that needs to run alongside your function. They have three lifecycle phases:
Init phase: The extension starts, performs setup (e.g., connecting to a backend). It runs before the function handler is invoked. The extension can register for the next two phases.
Invoke phase: The function handler runs. Extensions can receive invocation events if they registered for them (via the Extensions API).
Shutdown phase: After the function invocation completes (or times out), the extension gets a shutdown signal to clean up resources (e.g., flush logs).
Extensions communicate with the Lambda service via the Extensions API, which runs on localhost:9001. They can be internal (run in the same process as the runtime) or external (separate processes). External extensions must be precompiled binaries or scripts placed in the /opt/extensions directory of a layer.
Dependencies and the 250 MB Limit
Every Lambda function has a deployment package size limit: 250 MB for the unzipped total (including layers). This includes:
Function code (zipped, max 50 MB for direct upload, 250 MB via S3)
All attached layers (unzipped size)
Custom runtimes (if any)
To manage dependencies:
Use AWS SAM or CloudFormation to define layers.
Package dependencies into layers when they are shared across functions.
For large dependencies, consider using Container Images (up to 10 GB, but cold starts may be slower).
The /tmp directory is separate and can hold up to 10 GB (configurable up to 10 GB as of 2024), but it is not for code dependencies.
Interaction with Related Technologies
AWS SAM: Simplifies layer creation and association. In a SAM template, you define a LayerVersion resource and reference it in the function's Layers property.
CloudFormation: Similar to SAM but more verbose.
AWS CDK: Provides higher-level constructs for layers (e.g., lambda.LayerVersion).
Lambda Runtime API: Layers can include custom runtimes (e.g., Rust, C++). The runtime must be placed in /opt and the function handler must reference it.
Lambda Extensions API: Used by extensions to register for lifecycle events. Endpoints: http://localhost:9001/2020-01-01/extension/register, http://localhost:9001/2020-01-01/extension/event/next.
Configuration and Verification Commands
To create a layer using the AWS CLI:
aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes python3.9To list layers:
aws lambda list-layersTo describe a layer version:
aws lambda get-layer-version --layer-name my-layer --version-number 1To update a function to use a layer:
aws lambda update-function-configuration --function-name my-function --layers arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1To verify the total unzipped size, you can use the AWS Console or CLI with --query to inspect the function's configuration.
Common Pitfalls and Exam Traps
Layer order matters: If two layers provide the same file, the one with the higher priority (later in the list) wins. The exam may ask which layer's version is used.
Layer permissions: Layers can be shared cross-account by adding a permission statement to the layer version.
Extensions must be in a layer: External extensions must reside in /opt/extensions inside a layer. The exam tests this requirement.
Maximum layers: 5 layers per function. Exceeding this causes an error.
Size limit: The unzipped total (code + layers) must be ≤ 250 MB. The exam often gives a scenario where a function exceeds this and asks for the best solution (e.g., use layers, reduce dependencies, or use container images).
Step-by-Step: Creating and Using a Layer
Prepare the layer content: Create a directory structure that matches the expected paths. For example, for Python libraries, place them in python/lib/python3.9/site-packages/. For custom runtimes, use bin/ or lib/.
Zip the content: zip -r layer.zip python/
Publish the layer version: Use the publish-layer-version CLI command.
Attach the layer to a function: Use the update-function-configuration command or the AWS Console.
Test the function: Invoke the function and verify that the layer's libraries are importable.
Extensions: External vs Internal
External extensions: Separate processes that run in the same sandbox. They must be placed in /opt/extensions/ and be executable. They communicate via the Extensions API.
Internal extensions: Run inside the runtime process (e.g., using runtime-specific hooks). They are simpler but less isolated.
Extensions are often used for:
Sending logs to custom destinations (e.g., Datadog, Splunk).
Capturing function metrics.
Integrating secrets managers.
Running health checks.
Dependency Management Best Practices
Use layers for shared dependencies (e.g., AWS SDK, ORM libraries).
For Python, use pip install -t python/lib/python3.9/site-packages/ -r requirements.txt to create a layer.
For Node.js, install packages in nodejs/node_modules/.
For Java, create a layer with JAR files in java/lib/.
Avoid bundling large binaries; use container images if needed.
Use --compatible-runtimes to ensure layers work with the correct runtimes.
Summary of Key Numbers
Maximum layers per function: 5
Maximum unzipped size (code + layers): 250 MB
Maximum zipped size for direct upload: 50 MB
Maximum zipped size via S3: 250 MB
/tmp storage: up to 10 GB (configurable)
Extensions API port: 9001
Extension registration endpoint: /2020-01-01/extension/register
Extension event next endpoint: /2020-01-01/extension/event/next
Prepare Layer Content
Create a directory structure that matches the expected paths for the runtime. For Python, libraries go in `python/lib/python3.9/site-packages/`. For Node.js, use `nodejs/node_modules/`. For custom runtimes, place binaries in `bin/` or `lib/`. Ensure that the directory structure is exactly as the runtime expects; otherwise, the libraries won't be found. The layer can contain multiple directories for different runtimes (e.g., both `python/` and `nodejs/`). This step is critical because the Lambda service extracts the layer contents into `/opt` and the runtime looks for libraries in specific subdirectories under `/opt`.
Zip the Layer Content
Use `zip -r layer.zip python/` (or equivalent) to create a ZIP file of the layer content. The ZIP file should preserve the directory structure. The maximum zipped size for a layer version is 250 MB (same as the function package limit). If the ZIP is larger, you must use S3 to upload. The layer version ARN is generated after a successful publish. The ZIP file must not contain the root directory itself; only the contents (e.g., the `python/` folder should be at the root of the ZIP).
Publish the Layer Version
Run `aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes python3.9`. This creates a new version of the layer. Each version is immutable and has a unique ARN (e.g., `arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`). You can specify multiple runtimes with `--compatible-runtimes` (e.g., `python3.8 python3.9`). The layer version is now available to be attached to functions. You can also add a description and license info.
Attach Layer to Function
Use `aws lambda update-function-configuration --function-name my-function --layers arn:aws:lambda:us-east-1:123456789012:layer:my-layer:1`. You can attach up to 5 layers by specifying multiple ARNs. The order matters: later layers can override files from earlier layers. The function's code and all layer contents are merged into a single filesystem. After updating, the function will use the new layer on the next invocation. If you update a layer version, you must update the function configuration to point to the new version.
Test the Function
Invoke the function using `aws lambda invoke --function-name my-function output.txt`. Check the logs in CloudWatch for any import errors. If the layer was correctly structured, the libraries should be importable. For example, in Python, `import requests` should work if `requests` is in the layer. If there are errors, verify the directory structure inside the layer ZIP. Also ensure that the runtime version matches the layer's compatible runtimes. The function's execution role does not need additional permissions to use layers, but the layer itself may require permissions if it accesses other AWS services.
Scenario 1: Enterprise Shared Libraries
A large financial services company has dozens of Lambda functions across multiple accounts that all use the same internal SDK for risk calculations. Without layers, each function would need to bundle the SDK, leading to 50 MB+ deployment packages and slow deployments. The team creates a single layer containing the SDK and attaches it to all functions. This reduces deployment package sizes to under 10 MB, speeds up CI/CD pipelines, and ensures consistent SDK versions. They manage the layer lifecycle with a separate pipeline that publishes new versions and uses CloudFormation stack sets to update all functions. A common mistake is forgetting to update the layer version reference in all functions after a new SDK release, causing some functions to run outdated code. They use AWS Config rules to enforce that functions use the latest layer version.
Scenario 2: Monitoring Agent as an Extension
A SaaS company wants to capture custom metrics from their Lambda functions and send them to their own monitoring platform. They develop a Lambda Extension that runs as an external process. The extension is placed in /opt/extensions/ inside a layer. During the Init phase, it registers with the Extensions API and opens a TCP connection to their backend. During the Invoke phase, it captures invocation context and sends metrics asynchronously. During the Shutdown phase, it flushes any remaining data. They deploy this layer across all functions in their production environment. A typical issue is that the extension's startup time adds to the Init phase duration, potentially causing timeouts if the function has a short timeout. They mitigate this by setting function timeouts to at least 10 seconds and using asynchronous I/O in the extension. Another issue is that extensions must be compatible with the runtime's architecture (x86_64 or arm64). They publish separate layer versions for each architecture.
Scenario 3: Custom Runtime for Legacy Code
A healthcare company has a legacy C++ library that performs complex analytics. They want to run it as a Lambda function without rewriting it. They create a custom runtime as a layer. The runtime is a binary placed in /opt/bin/ and a bootstrap script that invokes it. They also include the C++ library in the same layer. The function handler is set to bootstrap (the default for custom runtimes). The layer contains the compiled binary and any shared libraries. They test locally using the Lambda Runtime Interface Emulator (RIE). A key challenge is ensuring that the runtime correctly handles the Lambda runtime API (e.g., sending responses, handling errors). They use the provided Runtime API client library. They also need to manage the 250 MB unzipped limit; the C++ library alone is 150 MB, so they must be careful with other dependencies. They use S3 to upload the layer ZIP because it exceeds the 50 MB direct upload limit.
DVA-C02 Objective Coverage
This topic falls under Domain 1: Development with AWS Services, specifically Objective 1.1: Write code for serverless applications. The exam tests your ability to:
Create and manage Lambda layers.
Understand layer limits and compatibility.
Use Lambda Extensions for operational tooling.
Manage dependencies to stay within the 250 MB limit.
Common Wrong Answers and Why
"You can attach up to 10 layers to a function." This is a common trap. The correct limit is 5 layers. Candidates often confuse this with other limits (e.g., 10 VPC connections).
"Layers can be modified after creation." Layers are immutable. You must create a new version. The exam tests this by asking how to update a layer's content.
"Extensions run in a separate container." Extensions run in the same execution environment (same sandbox) as the function, not a separate container. They are separate processes but share the same filesystem and network namespace.
"The layer with the same name as the function code overrides it." Layers are extracted to /opt, while function code is in /var/task. They do not override each other unless the function code explicitly references /opt. However, if two layers provide the same file, the one with higher priority (later in the list) wins.
Specific Numbers and Terms on the Exam
5 layers per function.
250 MB unzipped total (code + layers).
50 MB zipped direct upload limit.
/opt directory for layers.
/opt/extensions for external extensions.
Extensions API on localhost:9001.
Init, Invoke, Shutdown phases.
Layer version ARN format: arn:aws:lambda:region:account-id:layer:layer-name:version.
`--compatible-runtimes` parameter when publishing a layer.
Edge Cases and Exam Traps
Cross-account layers: The layer owner must grant permissions to other accounts using add-layer-version-permission. The exam may ask how to share a layer with another account.
Layer deletion: You cannot delete the default layer version (version 1). You must first create a new version and then delete the old one.
Container images: If using container images, layers are not supported. The entire image is self-contained. The exam may contrast this with the ZIP-based model.
Arm64 vs x86_64: Layers must be compatible with the function's architecture. The exam may test that you need separate layers for each architecture.
Extension errors: If an extension fails during Init, the function invocation may fail. The exam may ask what happens if an extension crashes.
How to Eliminate Wrong Answers
If a question mentions modifying a layer, the correct answer will involve creating a new version, not updating existing.
If a question asks about the maximum number of layers, eliminate any answer with 10 or 15.
If a question involves large dependencies, consider using layers or container images. The exam prefers layers for shared code and container images for large binaries.
For extensions, remember they must be in a layer under /opt/extensions. Any answer that places the extension elsewhere is wrong.
A Lambda function can use up to 5 layers; the total unzipped size of code plus layers cannot exceed 250 MB.
Layers are immutable after creation; to update a layer, you must publish a new version and update the function configuration.
Lambda Extensions run in the same execution environment as the function and have three lifecycle phases: Init, Invoke, and Shutdown.
External extensions must be placed in the /opt/extensions directory of a layer and be executable.
The Extensions API runs on localhost:9001; extensions register using endpoint /2020-01-01/extension/register.
Layer contents are extracted to /opt; function code is in /var/task.
To share a layer cross-account, use the add-layer-version-permission API.
Layers must be compatible with the function's runtime and architecture (x86_64 or arm64).
These come up on the exam all the time. Here's how to tell them apart.
Lambda Layers
Share code across functions; up to 5 layers per function.
Maximum unzipped size: 250 MB (code + layers).
Faster cold starts because only the function code and layers are downloaded.
Supports custom runtimes via layers.
Cannot include large binaries easily; layers are best for libraries and small tools.
Container Images
Self-contained; no sharing mechanism.
Maximum image size: 10 GB (up to 10 GB for ECR).
Slower cold starts due to larger download size.
Supports any runtime that can run in a container.
Ideal for large binaries, heavy dependencies, or legacy applications.
Mistake
Lambda layers are extracted into the same directory as the function code.
Correct
Layers are extracted to `/opt`, while the function code is in `/var/task`. They are separate directories. The runtime's library path includes both, but files do not mix unless explicitly referenced.
Mistake
You can have up to 10 layers per function.
Correct
The correct limit is 5 layers per function. This is a hard limit enforced by the Lambda service.
Mistake
Lambda extensions run in a separate container from the function.
Correct
Extensions run in the same execution environment (same sandbox) as the function. They are separate processes but share the same filesystem, network, and lifecycle.
Mistake
Layers can be updated in place by publishing a new version and the function automatically picks it up.
Correct
Layers are immutable. You must explicitly update the function configuration to reference the new layer version. The function does not automatically use the latest version.
Mistake
The layer ZIP file can be up to 250 MB when zipped.
Correct
The 250 MB limit applies to the unzipped total (code + layers). The zipped layer version can be up to 250 MB when uploaded via S3, but the direct upload limit is 50 MB. The unzipped size must be ≤ 250 MB.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, create a directory named `python` and inside it, create the path `lib/python3.9/site-packages/` (adjust for your Python version). Install your dependencies into that directory using `pip install -t python/lib/python3.9/site-packages/ -r requirements.txt`. Then zip the `python` directory: `zip -r layer.zip python/`. Finally, publish the layer using the AWS CLI: `aws lambda publish-layer-version --layer-name my-layer --zip-file fileb://layer.zip --compatible-runtimes python3.9`. Attach the layer to your function by updating its configuration.
No. If you use a container image for your Lambda function, you cannot attach layers. The container image must include all dependencies. Layers are only supported for functions deployed as ZIP archives. This is a common exam distinction: container images vs. ZIP-based functions.
When multiple layers are attached, they are extracted to `/opt` in the order specified in the function's `Layers` list. If two layers contain the same file path, the layer listed later (higher precedence) will overwrite the earlier one. This is similar to how environment variables are overridden. The exam may test this by asking which version of a library is used.
Check CloudWatch Logs for the extension's output. Extensions typically log to stdout/stderr, which appears in the function's log group. Ensure the extension binary is in `/opt/extensions/` and has execute permissions. Verify that the extension registers correctly with the Extensions API (localhost:9001). Also check that the function's timeout is long enough to accommodate the extension's Init phase (default 3 seconds, but can be up to 900 seconds).
No. Lambda layers are immutable. To change the content of a layer, you must publish a new version. You can then update your functions to use the new version. You can have up to 100 layer versions per layer (soft limit, can be increased).
Layers are used to distribute code and libraries that are loaded by the function runtime. Extensions are separate processes that run alongside the function to provide operational capabilities (e.g., monitoring, logging). Extensions are typically deployed as layers (the extension binary is placed in `/opt/extensions/`), but they are conceptually different: layers provide passive code, while extensions provide active processes.
Use the `add-layer-version-permission` API to grant cross-account access. For example: `aws lambda add-layer-version-permission --layer-name my-layer --version-number 1 --statement-id xaccount --principal 123456789012 --action lambda:GetLayerVersion`. This allows the other account to attach the layer to their functions. The layer ARN remains the same.
You've just covered Lambda Layers, Extensions, and Dependencies — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?