能否创建带自有依赖的自定义代码AWS Lambda层作为共享代码库？

自定义依赖层可行性及创建方法 #

完全可以创建带有自有依赖的Lambda层作为多函数的共享代码库，Lambda层的核心设计目标就是解决公共依赖、通用代码的复用问题，避免重复打包。针对你需要的带aws-sdk访问DynamoDB的Node.js环境层，创建步骤如下：

• 本地创建指定结构的目录：必须新建名为nodejs的文件夹，所有依赖和自定义代码都放在该目录下，Lambda运行时会自动将/opt/nodejs/node_modules加入模块搜索路径
• 进入nodejs目录，执行npm install <所需依赖包名>安装你需要的aws-sdk版本、DynamoDB相关依赖，你封装的通用DynamoDB操作代码也可以放在该目录下，比如nodejs/utils/dynamoHelper.js
• 选中nodejs目录直接打包为zip文件，不要打包外层的父目录，否则会导致路径匹配失败
• 进入AWS Lambda控制台，选择「层」→「创建层」，上传zip包后选择兼容的Node.js运行时版本即可完成创建
• 后续Lambda函数绑定该层后，可直接通过require('aws-sdk')调用层内的依赖，通过require('/opt/utils/dynamoHelper.js')调用层内的自定义公共代码

注意：Node.js 18及以上版本的Lambda运行时默认预装AWS SDK v3，如果你需要使用v2版本或者特定版本的SDK，必须手动将对应版本安装到层的node_modules目录中。

两种替代方案的优劣及适用场景 #

方案一：自定义npm包引入每个Lambda函数 #

• 适用场景：公共代码版本迭代频繁，需要为不同Lambda函数指定不同的公共代码版本，或者公共代码仅在小范围业务线内复用
• 优点：版本管控灵活，本地开发调试和普通npm包使用逻辑完全一致，不需要额外维护Lambda层的版本发布流程
• 缺点：每个Lambda函数打包时都会包含完整的公共代码，会增大单个函数的部署包体积，公共代码更新后需要所有调用方函数重新打包部署

方案二：新增公共Lambda函数供其他函数调用 #

• 适用场景：公共逻辑是完整的独立业务流程，比如统一的DynamoDB读写鉴权、数据清洗、埋点统计，需要对公共逻辑做统一的限流、监控管控
• 优点：公共逻辑更新不需要修改任何调用方函数，仅需升级公共函数即可，可快速实现全链路的规则调整
• 缺点：每次调用都会产生额外的Lambda调用费用，会增加链路延迟，还需要额外处理公共函数的调用超时、错误重试等异常逻辑

选型建议 #

• 若你需要共享的是工具类代码、第三方依赖库，优先选择Lambda层方案，无需重复打包，更新层版本后仅需函数重新绑定即可生效，成本最低
• 若公共代码需要跨团队共享、且不同团队对版本要求不同，选择自定义npm包方案灵活度更高
• 若公共逻辑是可独立运行的完整业务流程，有统一管控需求，选择公共Lambda函数方案更匹配

内容的提问来源于stack exchange，提问作者Donatic