Let's say we are developing multiple Python functions. Each function uses a number of Python modules that are packaged and deployed with the code each time you create or update a function. A lot of these modules are likely to be common across the Lambda functions, so we are duplicating the amount of storage space that's needed for each function. This has an impact on cost and function initialization performance since each time an execution is scheduled on a new host, it needs to pull the deployment package from S3. It also has an impact on the manageability of module versions if they are spread across multiple locations.

The following diagram shows two Lambda functions, both using the same libraries (A and B), but each have been deployed individually:

To address these inefficiencies, Amazon introduced Lambda layers. A Lambda layer is a ZIP file that contains the libraries, modules, binaries, and other data that you want to share between functions. An example might be Lib A and Lib B from the preceding diagram. The layer can be referenced from multiple lambda functions, much like we do for other modules and libraries. 

Here is a diagram showing Lib A and Lib B now separated from both Lambda functions and into a layer. Each function references the layer and can access both libraries:

Another benefit is that you can now separate the build, test, and deployment process of your business logic from your other libraries or dependencies. You might have another team developing and providing a library or SDK to access their service, and this could be worked on independently and then published as a layer for other development teams to consume. This allows the team writing the business logic to iterate and release faster. Lambda layers supports resource-based IAM policies, which means you can also publish layers to multiple accounts or organizations or even publicly. 

Each layer gets its own identifier, an Amazon Resource Number (ARN), and can also be versioned much like a function. The layers themselves are immutable, which means that, if you're using a layer in your Lambda, you can't make changes to it, which may affect other functions using the same layer. When including a layer in your Lambda, the package is extracted into the /opt directory of the Lambda runtime. The directory structure under that will be particular to the runtime you are developing against. You can reference up to five layers per function, and the overall size of the function, including the layers, can be up to 250 MB when unzipped. One of those layers can be a custom runtime. Typically, the interpreter binary of a custom-built runtime can be in the megabytes size range. Lambda layers are a really good way of sharing around these binaries to keep your deployment size down. If you reference multiple layers, you can also specify the order in which the layer is installed.

An example of how you might use multiple layers could consist of three types:

• Dependencies: One or more layers with shared libraries, middleware, or common code
• Management: Another layer that adds security or monitoring functionality
• Custom runtime: Sharing your runtime binary and bootstrap file

Now that we understand what a Lambda layer is, we can create our own.