AWS introduced Lambda Layers at re:invent 2018 as a way to share code and data between functions within and across different accounts. It's a useful tool for sharing large dependencies, such as FFmpeg and Pandoc executables, or data-heavy layers like MaxMind database or SQLite database files. However, it introduces new challenges, including harder to invoke functions locally, test functions, and deal with changes in the layer. Lambda Layers require additional security considerations and introduce new tooling challenges. They do not work well with static languages such as C# and Java, which requires all the application code and dependencies during the compilation process. The versioning scheme is basic and does not support semantic versioning, making it harder to tell if it's safe to upgrade to a new version of a layer. When a layer or a version of a layer is deleted, functions that depend on them can continue to operate, but updating the functions until you upgrade to a newer version or migrate off of the layer is not straightforward. Overall, Lambda Layers should be used for specific AWS Lambda use cases, such as large dependencies or custom runtime, and are a great way to improve deployment speed by automating the bundling and publishing of dependencies.