A developer created reusable code that several AWS Lambda functions need to use. The developer bundled the code into a zip archive. The developer needs to deploy the code to AWS and update the Lambda

Lambda functions do not support an 'import path' configuration pointing to S3 for shared code; code must be included in the deployment package or provided via a layer.

Creating a separate Lambda function to run shared code introduces network latency, additional invocation costs, and error-handling complexity compared to a layer that runs in the same execution environment.

A Lambda layer is a zip archive that is independently versioned and can be attached to multiple Lambda functions; the layer contents are extracted to /opt in the function's execution environment, allowing shared libraries or utilities to be maintained in one place and updated independently of the functions that use them.

Using a container image for shared code changes the deployment model for all consuming functions and does not provide the same separation-of-concerns benefit as a layer for code that is logically a shared library.