AWS SAM多环境部署：参数覆盖配置的替代方案咨询

你当前在samconfig.toml中罗列长串parameter_overrides的写法不属于SAM多环境部署的标准实践，这种写法仅适合参数极少的测试场景，一旦环境数量增加、单环境参数变多，很容易出现参数写错、漏配、不同环境配置串用的问题，维护成本很高。

以下是业内更通用、维护成本更低的实现方案：

方案1：拆分独立环境参数文件 #

SAM原生支持引用外部JSON/YAML格式的参数文件，你可以把每个环境的参数单独存为独立文件，不需要把所有参数都堆在samconfig.toml里。

• 首先在项目根目录创建config文件夹，分别存放dev.json、staging.json、prod.json三个参数文件，以dev环境为例，参数文件内容格式如下：

[
  {"ParameterKey": "MY_ENV", "ParameterValue": "dev"},
  {"ParameterKey": "APIDomain", "ParameterValue": "application-dev.example.com"},
  {"ParameterKey": "APIDomainARN", "ParameterValue": "arn:aws:acm:XX-YYYY-Z:123456789123:certificate/12345678-1234-1234-1234-123456789123"},
  {"ParameterKey": "APIDomainZoneID", "ParameterValue": "ABCDEGHIJ"},
  {"ParameterKey": "CorsOrigins", "ParameterValue": "https://other.example.com"}
]

• 之后简化samconfig.toml配置，直接引用对应环境的参数文件即可：

version = 0.1
[dev]
[dev.deploy]
[dev.deploy.parameters]
stack_name = "application-dev"
s3_bucket = "application-dev.example.com"
s3_prefix = "dev-env"
region = "XX-YYYY-Z"
capabilities = "CAPABILITY_IAM"
parameter_overrides = "file://config/dev.json"

[staging]
[staging.deploy]
[staging.deploy.parameters]
stack_name = "application-staging"
s3_bucket = "application-staging.example.com"
s3_prefix = "staging-env"
region = "XX-YYYY-Z"
capabilities = "CAPABILITY_IAM"
parameter_overrides = "file://config/staging.json"

[prod]
[prod.deploy]
[prod.deploy.parameters]
stack_name = "application-prod"
s3_bucket = "application.example.com"
s3_prefix = "prod-env"
region = "XX-YYYY-Z"
capabilities = "CAPABILITY_IAM"
parameter_overrides = "file://config/prod.json"

部署时只需要指定对应的环境配置段即可，比如部署dev环境直接执行sam deploy --config-env dev，不需要手动传入零散参数。

方案2：通过模板内置Mappings收敛环境规则 #

你的三个环境的域名、资源命名本身存在固定规则，完全可以把这些固定配置直接写在template.yaml的Mappings块中，外部只需要传入一个环境标识参数，模板会自动匹配对应环境的配置值，从根源上减少需要外部传入的参数量。

• 首先修改template.yaml，新增环境参数和环境映射配置：

Parameters:
  Env:
    Type: String
    AllowedValues: [dev, staging, prod]
    Description: 目标部署环境

Mappings:
  EnvConfig:
    dev:
      APIDomain: application-dev.example.com
      APIDomainARN: arn:aws:acm:XX-YYYY-Z:123456789123:certificate/12345678-1234-1234-1234-123456789123
      APIDomainZoneID: ABCDEGHIJ
      CorsOrigins: https://other.example.com
    staging:
      APIDomain: application-staging.example.com
      APIDomainARN: arn:aws:acm:XX-YYYY-Z:staging环境对应证书ARN
      APIDomainZoneID: staging环境对应HostedZone ID
      CorsOrigins: staging环境对应CORS源
    prod:
      APIDomain: application.example.com
      APIDomainARN: arn:aws:acm:XX-YYYY-Z:prod环境对应证书ARN
      APIDomainZoneID: prod环境对应HostedZone ID
      CorsOrigins: prod环境对应CORS源

• 把模板中原来引用参数的位置，改为通过!FindInMap从映射中取值，比如原来的DomainName: !Sub "${APIDomain}"改为DomainName: !FindInMap [EnvConfig, !Ref Env, APIDomain]，证书ARN、ZoneID、CORS配置都用同样方式取值。
  这种方式下samconfig.toml里的parameter_overrides只需要传一个Env参数即可，所有环境固定配置都收敛在模板文件中，不会出现配置散落在多个文件难以维护的问题。如果有需要临时覆盖的配置，再单独追加参数即可。

方案3：CI/CD流水线动态注入参数 #

如果你的部署流程走自动化流水线，可以把环境相关的配置、敏感凭证存在流水线的变量管理/密钥管理服务中，部署时动态拼接参数传入，不需要把敏感配置硬编码在代码仓库里，适合对配置安全性要求高的生产场景。

注意：使用AWS::Serverless::HttpApi的Domain配置块时，需要提前在对应区域的ACM中完成各环境域名证书的创建和DNS验证，同时给SAM部署角色授予Route53记录修改、API Gateway域名关联的对应权限，否则部署时会出现资源关联失败的错误。

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