3. 基础设施即代码核心工具选型
在AWS上落地基础设施即代码（IaC），最常见的三个工具是CloudFormation、AWS CDK和Terraform。它们都能把“点控制台”变成“写代码、走流水线”，但三者的抽象层次、状态管理方式、跨云能力和团队协作模型差异很大。选型不是比谁更“先进”，而是判断哪一种工具能让你的团队在可维护性、变更安全性和交付速度之间取得最合适的平衡。
三者的本质差异：声明式模板、编程语言与多云状态机
CloudFormation是AWS原生的声明式模板服务。你写YAML或JSON，描述“要哪些资源、参数是什么”，CloudFormation负责编排调用AWS API，并维护一个称为Stack的状态记录。它的优势是与AWS新服务同步最快、无需自建状态后端、天然支持回滚和漂移检测。代价是模板冗长，复杂逻辑要靠Conditions、Mappings、Fn::If等内置函数拼装，复用能力有限。
AWS CDK把CloudFormation包了一层。你用TypeScript、Python、Java等语言编写“构造块”（Construct），CDK在部署前通过cdk synth把这些代码合成为标准CloudFormation模板，再交给CloudFormation执行。因此CDK并没有绕开CloudFormation，而是让你用循环、条件、类继承、包管理等编程手段生成模板。它适合资源规模大、需要抽象复用、团队已有编程能力的场景。
Terraform走的是另一条路。它使用HCL声明式配置，通过Provider调用AWS API，并把资源状态保存在state文件中。state是Terraform的核心：它记录“配置文件中的资源”与“真实云上资源”的映射关系。Terraform不依赖CloudFormation，因此可以同时管理AWS、Azure、GCP以及DNS、SaaS等非云资源。代价是state需要自行规划后端（如S3+DynamoDB锁），且AWS新服务支持通常略滞后于CloudFormation。
关键对比维度与选型判断
把三者放在同一张决策表里，可以从六个维度快速判断。下表给出的是典型场景下的倾向性结论，实际选型仍需结合团队技能和存量资产。
| 对比维度 | CloudFormation | AWS CDK | Terraform |
|---|---|---|---|
| 抽象层次 | 资源级声明 | 构造块/面向对象 | 资源级声明 + 模块 |
| 状态管理 | AWS 托管 Stack | 复用 CFN Stack | 自建 state 后端 |
| 跨云能力 | 仅 AWS | 仅 AWS | 多云 + 非云资源 |
| AWS 新服务支持 | 最快 | 跟随 CFN | 通常滞后数周至数月 |
| 团队技能门槛 | 低（会 YAML 即可） | 中高（需编程） | 中（需理解 state） |
| 典型适用场景 | 纯 AWS、合规审计、快速起步 | 大规模 AWS、平台工程、内部抽象 | 多云、混合云、已有 Terraform 资产 |
实际决策路径：从约束出发而不是从偏好出发
选型时建议按以下顺序自问。第一，是否只使用AWS？如果未来明确要接Azure或GCP，Terraform几乎是默认答案；如果确定长期单云，CloudFormation或CDK更贴合。第二，团队是否具备编程能力并愿意维护抽象层？如果团队以运维和网络工程师为主，YAML模板更易审查；如果团队有平台工程能力，CDK能把“一个符合公司安全基线的VPC”封装成一个构造块，显著降低重复劳动。第三，是否已有存量IaC资产？已有大量Terraform模块时，强行迁移到CDK的收益通常低于成本。第四，合规与审计要求是否要求“模板即证据”？CloudFormation的Stack事件和变更集天然可作为审计材料。
一个可执行的选型评分示例
下面给出一个简化的加权评分表，用于团队内部快速对齐。权重和分值均为示例，团队可根据自身情况调整。评分规则：1分=明显不满足，3分=基本满足，5分=非常满足；加权总分越高越优先。
维度 权重 CloudFormation CDK Terraform
单云AWS深度 0.25 5 5 3
多云需求 0.20 1 1 5
团队编程能力 0.15 3 5 4
存量资产复用 0.15 3 2 5
状态治理成本 0.15 5 5 2
审计与合规 0.10 5 4 3
-----------------------------------------------
加权总分 3.55 3.85 3.75
在这个示例中，CDK略高，但如果把“多云需求”权重提高到0.35，Terraform会反超。这说明选型结论对权重非常敏感，因此权重必须由真实业务约束决定，而不是由工具偏好决定。
落地时的关键注意事项
无论选择哪个工具，都要避免把“能创建资源”当成“工程化完成”。CloudFormation要关注嵌套栈的层级和输出传递，避免一个巨型模板；CDK要关注构造块版本管理和cdk diff的审查，防止合成出的模板出现意外删除；Terraform要重点关注state的远程后端、锁机制和terraform plan的人工确认，禁止在本地保存生产state。三者都应纳入CI/CD，做到变更可评审、可回滚、可追溯。
总结来说，CloudFormation适合纯AWS、追求原生与低门槛的团队；CDK适合有编程能力、需要大规模抽象复用的平台团队；Terraform适合多云、混合云或已有成熟Terraform资产的场景。选型的核心不是工具本身，而是把团队技能、云战略、存量资产和治理成本放在同一张表里做加权判断，并确保最终选择能被持续维护。