如何在集成CloudFormation的SAM项目中管理Dev与Prod环境？

核心原则：环境完全隔离 #

直接给出结论：必须为Dev和Prod创建独立的CloudFormation栈，这是AWS环境管理的最佳实践，原因如下：

• 彻底避免开发测试操作影响生产数据与服务稳定性
• 支持独立配置资源参数（比如Lambda内存规格、API限流阈值、Cognito用户池规模）
• 便于单独开展版本迭代、监控告警和成本核算

每个环境的资源（Lambda、API Gateway等）需通过前缀/后缀区分，比如Dev环境的Lambda命名为my-service-dev-process-order，Prod环境为my-service-prod-process-order；API Gateway同理，用dev和prod作为核心标识符。

API Gateway Stage的作用 #

Stage是API Gateway中用于部署API版本的逻辑环境，核心作用与适用场景：

• 同一API的多版本部署：比如在同一个API Gateway下，通过Stage部署v1、v2版本，或为内部测试部署beta阶段
• 配置差异化：不同Stage可设置不同的限流规则、日志级别、自定义域名、环境变量（比如指向同环境内的不同Lambda版本）
• CI/CD集成：通常作为部署管道的目标节点，比如从CodePipeline把API部署到dev Stage完成测试，再推广到prod Stage

注意：Stage不能替代独立CloudFormation栈的环境隔离作用——如果用同一个API Gateway的不同Stage对应Dev和Prod，会导致两个环境共享API Gateway的基础配置（如域名、SSL证书），开发环境的配置变更可能意外影响生产，且资源权限边界模糊，不符合隔离原则。

合理架构搭建步骤 #

1. 模板参数化 #

在SAM模板（template.yaml）中定义环境相关参数，实现配置复用与差异化：

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, prod]
    Description: 目标部署环境
  LambdaMemorySize:
    Type: Number
    Default: 256
    Description: Lambda函数内存规格
  APIRateLimit:
    Type: Number
    Default: 100
    Description: API Gateway限流阈值

在资源定义中引用这些参数，比如Lambda的命名：

Resources:
  ProcessOrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub "my-service-${Environment}-process-order"
      MemorySize: !Ref LambdaMemorySize
      # 其他配置项...

2. 独立部署栈 #

使用SAM CLI分别部署两个环境：

• 部署Dev环境：

sam deploy --stack-name my-service-dev --parameter-overrides Environment=dev LambdaMemorySize=256 APIRateLimit=100 --capabilities CAPABILITY_IAM

• 部署Prod环境：

sam deploy --stack-name my-service-prod --parameter-overrides Environment=prod LambdaMemorySize=512 APIRateLimit=1000 --capabilities CAPABILITY_IAM

3. 环境专属资源配置 #

• Cognito：为每个环境创建独立的用户池与客户端，避免测试用户流入生产系统
• SES/SNS：Dev环境使用沙箱模式或测试主题/邮箱，Prod环境启用正式配置，确保测试邮件不会发送给真实用户
• 监控与日志：为每个环境配置独立的CloudWatch日志组与告警规则，便于区分环境的监控数据

4. CI/CD流程集成 #

• Dev环境：代码提交后自动触发部署，运行单元测试与集成测试
• Prod环境：需手动审批，部署前执行性能测试、安全扫描等严格校验，部署后开展冒烟测试

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