4. AWS CloudFormation模板工程化

CloudFormation 模板不是“能跑就行”的 YAML 文件，而是基础设施的源代码。工程化的核心目标有三个：可复用（同一模板适配多环境）、可预测（变更前能推断结果）、可追溯（输出与标签能定位资源归属）。本节围绕模板的六大构件——结构、参数、映射、条件、输出、伪参数——说明它们各自解决什么问题，以及在实际项目中如何组合使用。

一、模板结构：先定骨架，再填资源

一个标准模板由若干顶层段组成，顺序不影响执行，但固定顺序能显著提升可读性。推荐顺序为：AWSTemplateFormatVersion、Description、Metadata、Parameters、Mappings、Conditions、Transform、Resources、Outputs。其中 Resources 是唯一必填段，其余均可省略。

工程实践中，模板头部应写清用途与约束。例如：

AWSTemplateFormatVersion: "2010-09-09"
Description: "标准三层Web应用 - 支持dev/staging/prod环境"
Metadata:
  Owner: platform-team
  Version: "2.3.0"
Parameters:
  EnvType:
    Type: String
    AllowedValues: [dev, staging, prod]
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !FindInMap [EnvMap, !Ref EnvType, InstanceType]

注意 Metadata 段不参与资源创建，但可用于记录负责人、版本号，便于审计。模板文件建议按“一个逻辑应用一个模板”拆分，避免单文件超过 500 行；跨应用共享的部分用嵌套栈或模块化片段管理。

二、参数：把环境差异外置

参数是模板的输入接口。设计参数时遵循三条原则：只暴露真正变化的量、给默认值与约束、用 AllowedValues 限制取值。常见参数类型包括 String、Number、CommaDelimitedList、AWS::EC2::KeyPair::KeyName 等。

一个易犯的错误是把所有值都做成参数，导致调用时需传十几个值。更好的做法是：环境级差异（如实例规格、副本数）用参数；环境内固定值（如端口、路径）直接写死或用映射。参数应设置 Default 和 AllowedValues，让模板在无参调用时也能安全运行。例如：

Parameters:
  EnvType:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]
    Description: "部署环境类型"
  InstanceCount:
    Type: Number
    Default: 1
    MinValue: 1
    MaxValue: 10

参数变更会触发栈更新，因此不要用参数传递频繁变动的值（如时间戳），否则每次部署都会产生无意义的变更集。

三、映射与条件：让模板具备分支能力

映射（Mappings）是静态查找表，适合存放“环境 × 属性”的二维配置。它不参与运行时计算，只在模板解析时取值，因此比条件更轻量。典型用法是把实例类型、AMI ID、子网 CIDR 按环境映射：

Mappings:
  EnvMap:
    dev:
      InstanceType: t3.micro
      MinSize: 1
    prod:
      InstanceType: m6i.large
      MinSize: 3

条件（Conditions）则用于控制资源是否创建或属性是否生效。它基于参数和伪参数做布尔判断，常与 Fn::If 配合。例如生产环境才创建多可用区数据库：

Conditions:
  IsProd: !Equals [!Ref EnvType, prod]
Resources:
  Database:
    Type: AWS::RDS::DBInstance
    Condition: IsProd
    Properties:
      MultiAZ: true

映射与条件的分工可以这样理解：映射回答“值是多少”，条件回答“要不要做”。两者结合，一个模板就能覆盖多环境，而不需要维护多份副本。

四、输出与伪参数：连接栈与外部世界

输出（Outputs）用于暴露栈内资源的关键属性，供其他栈引用或供运维查看。输出应包含 Description，跨栈引用时用 Export 导出名称。例如：

Outputs:
  WebServerPublicIP:
    Description: "Web服务器公网IP"
    Value: !GetAtt WebServer.PublicIp
    Export:
      Name: !Sub "${AWS::StackName}-WebIP"

伪参数是 CloudFormation 在运行时自动注入的值，最常用的有：AWS::Region、AWS::AccountId、AWS::StackName、AWS::StackId、AWS::NoValue、AWS::Partition。它们让模板具备“位置无关性”——同一模板在不同区域、不同账号下都能正确工作。例如用 !Sub "${AWS::Region}" 构造区域相关的 ARN，用 AWS::NoValue 在条件中移除某属性。

五、组合实践：一个可复用的模板骨架

把上述构件组合起来，可以形成一套稳定的模板骨架。以下示例展示一个 Web 应用模板如何同时使用参数、映射、条件、伪参数和输出：

Parameters:
  EnvType:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]

Mappings:
  EnvMap:
    dev:  { InstanceType: t3.micro,  MinSize: 1 }
    staging: { InstanceType: t3.small, MinSize: 2 }
    prod: { InstanceType: m6i.large, MinSize: 3 }

Conditions:
  IsProd: !Equals [!Ref EnvType, prod]

Resources:
  WebASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: !FindInMap [EnvMap, !Ref EnvType, MinSize]
      LaunchTemplate:
        LaunchTemplateId: !Ref WebLT
        Version: !GetAtt WebLT.LatestVersionNumber
      AvailabilityZones: !GetAZs !Ref "AWS::Region"

Outputs:
  ASGName:
    Description: "AutoScaling组名称"
    Value: !Ref WebASG
    Export:
      Name: !Sub "${AWS::StackName}-ASG"

这段模板中，EnvType 决定实例规格与最小容量；IsProd 可用于后续给生产环境附加告警或备份策略；!GetAZs !Ref "AWS::Region" 利用伪参数自动获取当前区域可用区，使模板不绑定具体区域；Outputs 导出 ASG 名称供其他栈引用。

最后，模板工程化不是一次性工作。建议把模板纳入版本控制，配合 aws cloudformation validate-template 和变更集（Change Set）在部署前预览影响。每次修改后，用 describe-stacks 检查输出是否符合预期，用 describe-stack-resources 确认资源状态。只有把模板当作代码来管理，才能真正实现环境标准化。