使用CloudFormation部署Lambda报Internal Server Error，换sls deploy正常排查咨询

• Lambda基于资源的调用权限配置缺失
  这是最高发的踩坑点。Serverless Framework（sls）部署时会自动添加允许API Gateway调用Lambda的资源策略，很多人手写CloudFormation模板时会漏掉这个配置：没有对应AWS::Lambda::Permission资源给API Gateway的服务主体放行调用权限，直接触发时Lambda拒绝请求，API Gateway就会返回无差别Internal Server Error。
  同时要检查Lambda执行角色的权限：sls默认会自动给执行角色配齐CloudWatch Logs的写权限（创建日志组、写入日志流的权限），如果CFN模板里的IAM角色没加这部分权限，Lambda启动时就会因为写日志失败直接崩溃，抛出500错误。
• 代码打包内容/路径不匹配
  aws cloudformation package命令只负责把本地的代码目录上传到S3、替换模板里的代码路径，不会自动处理依赖安装、压缩包层级对齐的逻辑。和sls自动打包的效果对比，常见的不匹配点包括：
  • 压缩包内的文件层级不对，Lambda无法定位到配置的handler入口（比如把代码文件放在了压缩包的二级子目录里）
  • 没预先安装Lambda对应运行时的第三方依赖（比如Python的第三方库、Node.js的node_modules），运行时出现import报错
  • 压缩包整体大小超出Lambda的限制
    可以直接在Lambda控制台对比两个部署版本的上传包大小、内部文件结构，快速定位差异。
• 配套运行配置不对齐
  对比sls部署版本的配置项，检查CFN模板里的配置：
  • 环境变量：有没有把代码依赖的数据库连接串、第三方服务密钥、开关配置完整同步，漏配会导致Lambda运行时读不到配置直接报错
  • 运行时参数：内存大小、超时时间是否和sls版本一致，很多人CFN里配的超时时间过短，代码执行到一半就被强制中断，触发500
  • 运行时版本：是否和代码适配的版本一致，比如代码用了Python 3.10以上的语法特性，CFN里配成Python 3.7会直接加载失败
  • 网络配置：CFN里是不是误把Lambda加入了没有公网出口、没有关联下游服务子网的VPC，导致代码无法连接依赖的外部服务
• API Gateway集成配置错误
  检查CFN里的API Gateway配置：
  • 集成类型是不是选成了MOCK而不是AWS_PROXY，导致请求根本没传到Lambda层就返回了错误
  • 响应映射规则是不是和Lambda返回的格式不匹配，比如Lambda返回的JSON结构和网关配置的响应模型对不上，网关会直接抛500

最快定位问题的方式：直接打开CloudWatch Logs里对应Lambda的日志组（路径为/aws/lambda/<你的Lambda函数名>），找500报错时间点的运行堆栈，日志会直接标注崩溃原因，不需要盲猜排查。

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