AWS Lambda开发中SAM、CodeBuild与配置文件使用咨询

1. sam build/sam deploy 与独立CodeBuild作业的差异、依赖关系 #

• sam build/sam deploy本质是AWS官方提供的本地可运行的命令行封装工具，本身不提供计算资源，核心逻辑是：
  • 解析符合SAM语法的CloudFormation模板，识别所有Lambda、API Gateway等资源定义
  • 对每个资源关联的代码做打包、依赖安装（比如Node.js项目会在代码目录执行生产依赖安装）
  • 将生成的代码制品上传到指定S3桶，把SAM语法的模板转换为标准CloudFormation格式
  • 调用CloudFormation接口创建/更新堆栈，完成资源部署
• 独立搭建的CodeBuild作业本质是AWS提供的托管沙箱执行环境，本身没有内置任何SAM相关逻辑，只是一个可以跑任意构建命令的计算节点，你在上面跑npm run build、手动打zip还是执行sam build，完全由buildspec文件定义，和SAM本身没有绑定关系。
• 明确结论：运行SAM命令完全不需要依托CodeBuild，只要执行环境安装了对应版本的SAM CLI、配置了有效AWS凭证、安装了对应语言的运行时（如Node.js），在本地电脑、EC2、GitHub Actions、自建服务器上都可以正常执行。大家常误以为SAM依赖CodeBuild，只是因为AWS官方提供的流水线模板默认用CodeBuild作为构建环节的执行载体，属于默认推荐方案而非强依赖。

2. sam deploy 可识别的配置文件范围 #

• 首先要明确概念边界：serverless.yml是第三方开源Serverless Framework工具的专属配置文件，和AWS官方的SAM是两套完全独立的技术体系，SAM CLI从设计上就没有对这类文件的解析能力。如果你项目中保留的是serverless.yml文件，整套部署逻辑需要用Serverless Framework CLI（即serverless deploy）来执行，和AWS SAM的命令体系没有交集，不能混用两类工具的配置。
• sam deploy原生只识别符合CloudFormation/SAM语法的模板文件，且默认仅检索当前工作目录下的template.yaml/template.yml文件；如果模板文件名不匹配，必须通过--template-file参数手动指定完整路径，不存在自动递归遍历子目录查找所有配置文件的逻辑。
• 明确结论：sam deploy既不会单独检索serverless.yml，也不会同时识别两类不同体系的配置文件，所有部署目标都需要在执行命令时明确指定。

3. sam.yaml的定位与状态 #

• sam.yaml是AWS SAM刚推出（2017年左右）时的早期默认配置文件名，用于承载模板定义、本地调试参数等内容。
• 2018年之后AWS官方为了和CloudFormation的通用命名习惯对齐，把SAM模板的默认文件名统一调整为template.yaml/template.yml，同时新增了专门存储部署参数的samconfig.toml文件，把原来sam.yaml承载的功能拆分到了上述两个文件中。
• 明确结论：当前版本的SAM CLI已经不再主动识别默认路径下的sam.yaml文件，它属于早期版本的遗留技术产物，除非老项目做历史兼容，否则已经没有实际使用价值。

结合你不想为每个Lambda单独创建CodeBuild作业和buildspec的需求，先纠正一个常见误区：sam deploy不会自动遍历所有子目录下的template.yml或serverless.yml做整体部署，所有部署目标都需要在配置中明确指定。针对你的场景，两个可直接落地的常见实践：

• 方案一：单堆栈统一管理
  • 放弃在每个Lambda目录下放独立serverless.yml的设计，在仓库根目录放置一个全局统一的SAM主模板（template.yml），在模板中定义所有Lambda资源、关联的API Gateway路由、鉴权、集成配置，各个Lambda的代码分别放在独立的子目录即可。
  • 现有CodeBuild作业的buildspec中只需要配置标准的sam build（会自动识别每个Lambda的代码目录，执行Node.js生产依赖安装、打包）和sam deploy命令即可，不需要拆分多个作业。
  • 关于变更更新：CloudFormation本身就具备资源变更检测能力，部署时只会对比当前模板和线上已部署堆栈的差异，仅更新发生变更的Lambda代码、API Gateway路由配置，不会全量重建所有资源。
• 方案二：多堆栈分域管理
  • 如果不同Lambda属于独立业务域，不想全部塞到同一个堆栈里，可以在每个Lambda的子目录下放置独立的SAM模板（注意是标准的template.yml，不是第三方的serverless.yml），然后在根目录的buildspec中写简单的循环逻辑，遍历所有子目录下你明确指定的模板路径，逐个执行sam build和sam deploy。
  • 这种方式同样不需要为每个Lambda单独创建CodeBuild作业和buildspec，每个独立堆栈的部署依然会自动触发CloudFormation的变更检测，只更新对应范围内的变更内容。

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