使用Terraform部署对接S3、数据库的Lambda是否需要额外配置资源？

现有部署方式的潜在问题 #

你当前的部署方式存在多个隐性风险，不是所有场景都能正常运行：

• 权限缺失风险：如果你绑定的角色策略中没有显式包含S3读写、数据库访问的权限条目，就算Lambda代码里写了对应逻辑也会直接报AccessDenied错误。Lambda本身没有任何默认的AWS资源访问权限，所有权限都需要手动在角色策略中声明。
• 资源依赖不一致风险：S3桶、数据库资源没有在当前Terraform栈中定义，意味着这些资源是手动创建或者在其他栈管理，跨环境部署时很容易出现资源名称、配置和Lambda代码中硬编码的参数不匹配的问题，同时也没有统一的生命周期管理，销毁栈时会产生孤儿资源。
• 网络连通性风险：如果你的数据库是VPC内部署的私有资源（比如RDS），没有给Lambda配置VPC访问权限、对应安全组规则的话，Lambda完全无法连通数据库。如果S3开启了VPC端点访问限制，没有对应配置也会访问失败。
• 敏感信息泄露风险：当前逻辑下S3桶名、数据库连接地址、凭证大概率是硬编码在Lambda代码中，不仅变更需要重新打包发布Lambda，还会有密码泄露的安全隐患。

需要额外添加的配置项 #

你需要根据场景补充以下配置，不需要所有项都加，但至少要满足权限要求：

• 补全Lambda执行角色的权限策略：必须在角色的inline policy或者托管策略中添加对应资源的访问权限，示例如下：

  // S3读写权限示例
  {
    "Effect": "Allow",
    "Action": ["s3:PutObject", "s3:GetObject"],
    "Resource": "arn:aws:s3:::<你的S3桶名>/*"
  }
  

  如果使用RDS还要加rds:Connect权限，如果用Secrets Manager存储数据库密码还要加secretsmanager:GetSecretValue权限。
• 资源引用/定义配置：如果S3、数据库是提前创建的，建议在Terraform中用data数据源引用对应资源，校验资源存在性的同时可以把资源地址、桶名等参数通过环境变量注入Lambda，避免硬编码。如果是全新部署的环境，建议直接把S3桶、数据库实例、安全组等资源都纳入当前Terraform栈统一管理。
• 网络配置：如果数据库在VPC内，需要给Lambda配置对应的VPC子网、安全组，同时在数据库的安全组中添加入站规则，允许Lambda的安全组访问数据库端口。
• 敏感信息配置：用Lambda环境变量、AWS Secrets Manager或者Parameter Store存储数据库凭证、桶名等配置，不要硬编码在代码中，Terraform可以直接把这些参数注入到Lambda的环境变量里。

误区澄清 #

Lambda本身只是运行代码的无服务器计算环境，AWS SDK只是封装了服务调用的API逻辑，没有内置任何资源的默认访问权限或者连通规则，所有权限、网络配置都需要你显式声明才可以正常访问对应资源。

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