如何基于Terraform实现Lambda函数的独立部署与全量部署

原独立后端+状态导入思路的局限性 #

你最初设想的单函数独立后端的方案，核心问题不是导入操作复杂，而是会带来长期的状态分裂风险：

• 同一Lambda资源会被两个独立状态同时持有引用：一个是你在单函数目录存的状态，另一个是terraform/目录下批量部署用的全局状态，两边都能发起变更，时间久了必然出现状态漂移，轻则apply报资源重复存在，重则出现误删其他团队部署的生产资源。
• 状态导入本身操作门槛很低，但后续跨状态同步、核对版本的维护成本，远高于方案带来的收益，不符合Terraform单一可信状态源的最佳实践。

适配现有目录结构的最优实现方案 #

完全不需要推翻现有代码结构，只需要做少量调整，就能同时满足单函数独立部署、全量批量部署、并行开发无冲突的需求，核心思路是统一公共后端、按函数粒度拆分状态存储路径、避免重复持有资源引用：

• 后端配置统一化，不拆分独立后端实例
  所有单函数的部署配置，全部沿用你现在terraform/目录使用的同一个S3状态后端，不新建独立的后端存储桶、不配置独立的权限策略，避免重复维护多套后端配置。
  只需要在每个函数的配置目录（比如js/jsFunction1）的main.tf里补充后端配置，和根目录的后端参数完全一致，仅修改状态文件的key路径：
  • 原全局状态的key路径为：env/stage/lambdas/global.tfstate
  • 单函数独立部署的状态key路径为：env/stage/lambdas/{function_name}.tfstate
    这样做的好处是所有状态都存在同一个可信存储里，不会出现跨存储的状态同步问题，每个函数的状态锁也是独立粒度的，并行开发时不会出现抢锁冲突。
• 单函数部署逻辑适配，不触发其他函数的构建流程
  你现在在js/jsFunction1目录下写的模块引用逻辑本身是合理的，只需要移除terraform/main.tf里直接source各函数目录的写法，避免根目录解析配置时触发所有函数的依赖构建、zip打包动作。
  当你在单函数目录下执行terraform init、terraform apply时，Terraform只会解析当前目录下的配置，不会扫描其他函数的目录，自然不会触发其他函数的依赖安装、包上传逻辑，完全满足“部署单函数时无需构建其他函数依赖包”的核心诉求。
• 全量批量部署能力兼容，不破坏现有流程
  在terraform/global目录下新增全量编排配置，不要直接把各函数目录当模块引入，而是通过terraform_remote_state数据源，读取每个单函数对应的独立状态文件，聚合生成全量Lambda资源的视图。
  当需要做批量部署时，只需要在terraform/global目录下执行terraform plan，就能看到所有Lambda的当前实际状态、待变更内容，确认无误后即可统一执行部署，完全不需要逐个函数目录跑apply操作。

存量资源的迁移操作（如果采用上述方案） #

根本不需要逐资源执行terraform import，迁移成本极低：

• 先从原来terraform/main.tf对应的全局状态文件中，按模块路径拆分出每个函数对应的资源块（也就是所有以module.{function_name}为前缀的资源定义、输出值）
• 把拆分出来的内容直接写入对应函数独立的状态文件中，因为单函数目录下的模块路径和原全局状态里的模块路径完全一致，不需要调整任何资源路径映射
• 在单函数目录下执行一次terraform plan，确认没有无意义的diff之后，就可以正常使用独立部署能力了。

并行开发场景的适配效果 #

• 两个开发者同时修改不同的Lambda函数时，各自在自己的函数目录下执行操作，操作的是完全独立的状态文件，不会出现状态锁冲突，也不会影响其他人的部署动作
• 开发者只需要构建、上传自己修改过的函数的部署包，不需要关心其他函数的版本状态，从根源上避免了未改动函数因为批量构建、版本不匹配导致的部署问题

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