Your Lambda function is almost never alone: it needs libraries (third-party code) to do its job —connect to a database, process images, call an API—. In this subchapter, we’ll see how to include those dependencies in a Lambda and how Layers let you share them and keep your function lightweight.

Imagine a Python Lambda that resizes images. For this, it uses a popular library like Pillow. But that library is not included in Lambda by default: you have to package it along with your code.

If you don’t include the library, the function will fail at runtime with a “module not found” error. So the challenge is: how do I get the libraries into my Lambda?

The most direct way is to include the libraries inside the package you upload to Lambda. You install the dependencies in a folder next to your code and upload everything together, usually as a ZIP file:

This works, but there’s a drawback: if you have many functions that use the same libraries, you end up repeating those libraries in every package. The code is duplicated, the packages get big, and maintenance is a hassle (if you update a library, you have to rebuild all the packages).

A Layer is a package of libraries or common code that you can share among several functions. Instead of putting the libraries in each function, you put them once in a layer and then attach that layer to all the functions that need it.

Each function includes only its own code, and “borrows” the libraries from the layer.

Analogy: a layer is like the shared pantry in an apartment building. Instead of each neighbor having their own sack of flour and sugar (duplicated), there’s a common pantry where everyone takes what they need. If you need to restock the flour, you do it once for everyone.

• Less duplication: common libraries are in one place, not repeated in every function.
• Lighter functions: your package only contains your code, so it’s small and uploads/deploys faster.
• Centralized maintenance: update the library in the layer and all functions benefit.
• Reuse: you can have a “custom utilities” layer shared by all your teams.

Real-world example: a company has 15 Lambda functions that connect to the same database and use the same internal utilities (logging, validation). They create a company-utilities layer with all that common code. The 15 functions use it. When they improve a utility, they update the layer once and all 15 functions inherit it, without touching each function’s code.

To start: if you have a single function or are learning, packaging libraries with your code is the simplest. Layers make sense when you grow and start repeating the same dependencies in several functions.

Lambda has size limits for the code package and layers (we’ll see this in subchapter 14.5). That’s why it’s important not to include libraries you don’t use: the lighter the function, the faster it starts (which connects to “cold starts” in the next subchapter). If your dependencies are very large, there’s also the option to package the Lambda as a container image (think Docker, which we’ll cover in Chapter 17), which allows much larger packages.

• Your Lambda needs its dependencies (third-party libraries) included; if they’re missing, it fails at runtime.
• Option 1 — package with the code: you put the libraries in the ZIP along with your function. Simple, but duplicates libraries if you have many functions.
• Option 2 — layers: you put the libraries or common code once in a layer and share it among several functions. Like a “shared pantry.”
• Layers reduce duplication, keep functions lightweight, and allow centralized maintenance.
• To start, packaging with the code is easiest; use layers when you repeat dependencies in several functions.

In the next subchapter, we’ll tackle one of Lambda’s most characteristic topics: cold starts and how to reduce them.