How do Lambda packages, layers, and extensions work?

Choose a deployment package format

ZIP archives work well for conventional runtime projects and can be uploaded directly or through Amazon S3. Container images use the Lambda container contract and support larger artifacts and image-based build workflows, but they do not turn the function into a general-purpose container service.

Choose one format from dependency needs, build reproducibility, security scanning, artifact size, and team tooling. The execution model, scaling behavior, and function limits remain Lambda's in either case.

Use layers for a concrete ownership benefit

A layer can provide libraries, custom runtimes, certificates, configuration helpers, or shared tooling to multiple functions. Lambda extracts layer contents into the execution environment in a defined order.

Layers add version and compatibility relationships. Prefer them when independent ownership or reuse is valuable; do not split every dependency into a layer if one self-contained artifact is easier to test, deploy, and roll back.

Understand extension lifecycle and cost

Extensions can run as external processes or integrate with a runtime. They participate in initialization, invocation, and shutdown and can send telemetry, retrieve configuration, or enforce controls.

An extension consumes execution-environment resources and can affect startup and duration. Treat it as production code: pin versions, test failure behavior, monitor overhead, and give it only the permissions it requires.

Build a controlled software supply chain

Lock dependencies, produce artifacts in a repeatable build, scan them, record provenance, and deploy immutable versions through infrastructure as code. Remove compilers, tests, documentation, and packages that are not required at runtime.

A small artifact is not the only goal. Prefer an understandable artifact with explicit dependencies, compatible architecture and runtime settings, and a tested rollback path.