🌺The Begin🌺点点关注，收藏不迷路🌺 ⬇ ⬇ 底部 ⬇ ⬇

---

当你决定用"基础设施即代码"（IaC）管理云资源时，第一个灵魂拷问就是：Terraform 还是 CloudFormation？ 两者都能编排云资源，但它们的理念、生态、使用体验却大相径庭。选错工具可能导致后期迁移成本高昂。

📈 IaC 工作流程对比图

先通过一张图理解两种工具在基础设施编排中的角色和流程差异：

核心差异： Terraform是客户端工具，自己管理状态；CloudFormation是AWS托管服务，状态由AWS维护。

---

一、产品本质：第三方工具 vs 云原生服务

这是两者最根本的区别，决定了后续所有差异。

维度	Terraform	CloudFormation
开发方	HashiCorp（第三方）	AWS（云厂商原生）
产品形态	客户端CLI工具	AWS托管Web服务
运行方式	本地/CI服务器执行	提交模板后AWS执行
资源编排引擎	Terraform Core（自研）	AWS CloudFormation Engine
费用	开源免费（TFC收费）	免费（仅付资源费）

理解要点：

• Terraform是你自己运行的程序，读取 .tf 文件后调用AWS API创建资源，创建完成后将资源信息记录在本地 terraform.tfstate 文件中。
• CloudFormation是你提交模板给AWS，AWS的后台服务帮你创建资源，资源状态完全由AWS云端维护，你无需关心状态文件。

---

二、语言与语法：HCL vs JSON/YAML

1. Terraform：HCL（HashiCorp Configuration Language）

Terraform HCL 示例（创建EC2实例）：

# 声明式语法，支持变量、循环、条件
variable "environment" {
  default = "production"
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = var.environment == "production" ? "t3.medium" : "t3.micro"
  
  tags = {
    Name        = "web-${var.environment}"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

# 支持模块化，复用代码
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
  
  name = "my-vpc"
  cidr = "10.0.0.0/16"
}

HCL 特点：

• 专为基础设施设计的领域特定语言。
• 支持变量、函数、条件表达式、循环（for_each/count）。
• 内置模块系统，可引用公共Registry的模块。

---

2. CloudFormation：JSON/YAML

CloudFormation YAML 示例（创建EC2实例）：

Parameters:
  Environment:
    Type: String
    Default: production

Conditions:
  IsProduction: !Equals [!Ref Environment, production]

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0c55b159cbfafe1f0
      InstanceType: !If [IsProduction, t3.medium, t3.micro]
      Tags:
        - Key: Name
          Value: !Sub web-${Environment}
        - Key: Environment
          Value: !Ref Environment
        - Key: ManagedBy
          Value: CloudFormation

YAML/JSON 特点：

• 通用数据格式，无学习曲线。
• 使用**内部函数**（!Ref、!Sub、!If）实现逻辑。
• 不支持自定义模块（需用嵌套栈实现复用）。

---

语法对比总结

特性	Terraform HCL	CloudFormation YAML
可读性	⭐⭐⭐⭐⭐ 优秀	⭐⭐⭐ 中等（长模板冗长）
表达能力	⭐⭐⭐⭐⭐ 强（变量/循环/条件）	⭐⭐⭐ 中等（依赖内部函数）
代码复用	模块化（Registry）	嵌套栈/宏
IDE支持	IntelliJ/VS Code插件优秀	AWS Toolkit支持
学习曲线	需要学HCL语法	熟悉JSON/YAML即可

---

三、状态管理：本地文件 vs 云端托管

1. Terraform：显式状态管理

Terraform将资源与实际基础设施的映射关系存储在**状态文件**（terraform.tfstate）中。这是Terraform的核心机制，也是需要特别小心的地方。

状态管理命令：

# 查看当前状态
terraform show

# 刷新状态（同步云端实际资源）
terraform refresh

# 导入已存在的资源到状态
terraform import aws_instance.web i-1234567890abcdef0

# 状态文件远程存储（团队协作必备）
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

⚠️ 状态文件风险：

• 状态文件包含敏感信息（如数据库密码），必须安全存储。
• 多人协作时必须使用远程Backend（S3、Consul、Terraform Cloud）并启用状态锁（DynamoDB）。

---

2. CloudFormation：托管状态（无状态文件）

CloudFormation的状态由AWS自身维护。你只需关注模板，AWS的CloudFormation引擎自动跟踪每个Stack的资源状态。

优势：

• 无需管理状态文件，零运维负担。
• Stack漂移检测（Drift Detection）：自动发现手动修改。

劣势：

• 无法直接导入已存在的资源（需借助资源导入功能，功能受限）。
• Stack状态完全由AWS掌控，无法本地查看/修改。

---

四、多云与跨平台支持：开放生态 vs 厂商锁定

云平台/服务	Terraform	CloudFormation
AWS	✅ 完整支持	✅ 原生完整支持
Azure	✅ 完整支持	❌
Google Cloud	✅ 完整支持	❌
阿里云	✅ 完整支持	❌
Kubernetes	✅ Provider支持	❌
GitHub	✅ Provider支持	❌
Datadog	✅ Provider支持	❌

关键结论：

• 如果你只用AWS，两者都可以。
• 如果涉及**多云架构或需要管理非AWS资源**（如K8s、监控、GitHub仓库），Terraform是唯一选择。

Terraform 多云示例（同一项目管理AWS+K8s）：

# AWS 资源
provider "aws" {
  region = "us-east-1"
}
resource "aws_eks_cluster" "main" {
  name = "my-cluster"
  # ...
}

# Kubernetes 资源（同一份配置中）
provider "kubernetes" {
  host                   = aws_eks_cluster.main.endpoint
  cluster_ca_certificate = base64decode(aws_eks_cluster.main.certificate_authority[0].data)
}

resource "kubernetes_deployment" "app" {
  metadata {
    name = "web-app"
  }
  spec {
    # ...
  }
}

---

五、运行模式与集成：客户端 vs 托管服务

1. 执行方式对比

阶段	Terraform	CloudFormation
计划预览	terraform plan（本地执行）	Change Set（AWS计算）
应用变更	terraform apply（本地或CI）	执行Change Set
删除资源	terraform destroy	删除Stack
回滚	不支持自动回滚（需手动修复）	自动回滚到上一个稳定状态

CloudFormation 最大优势： 创建/更新失败时自动回滚，保证不会留下半成品资源。Terraform失败后需手动 terraform destroy 清理残留。

2. CI/CD 集成

两者都可以在Jenkins、GitLab CI中执行，但方式不同：

Terraform CI 示例（GitLab CI）：

terraform-plan:
  script:
    - terraform init
    - terraform plan -out=tfplan
  artifacts:
    paths:
      - tfplan

terraform-apply:
  when: manual
  script:
    - terraform apply tfplan

CloudFormation CI 示例：

# 使用AWS CLI
aws cloudformation deploy \
  --template-file template.yaml \
  --stack-name my-stack \
  --capabilities CAPABILITY_IAM

---

六、生态系统与社区

维度	Terraform	CloudFormation
Provider/资源类型	3000+ Provider	仅AWS资源
模块/模板市场	Terraform Registry	AWS Samples/Template Snippets
社区规模	极庞大（GitHub 40k+ Stars）	AWS用户社区
新资源支持速度	快（Provider独立发布）	较快（AWS官方维护）
文档质量	优秀（统一格式）	优秀（AWS官方文档）

---

📊 六大维度综合对比

对比维度	Terraform	CloudFormation	胜出
多云/混合云支持	⭐⭐⭐⭐⭐	⭐	Terraform
语法与代码复用	⭐⭐⭐⭐⭐	⭐⭐⭐	Terraform
状态管理复杂度	⭐⭐⭐（需自行管理）	⭐⭐⭐⭐⭐（托管）	CF
失败自动回滚	⭐⭐	⭐⭐⭐⭐⭐	CF
AWS新服务支持速度	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	CF
学习曲线	⭐⭐⭐	⭐⭐⭐⭐	CF（更低）

---

💎 终极选型建议

选 Terraform，如果你：

1. 需要多云管理：同时使用AWS+Azure+Kubernetes。
2. 管理非云资源：如GitHub仓库、Datadog监控、PagerDuty告警。
3. 追求代码复用：模块化设计，使用公共Registry。
4. 团队技术栈多样：不想绑定单一云厂商。

选 CloudFormation，如果你：

1. 纯AWS环境：只用AWS，且无多云规划。
2. 需要免费托管：不想维护状态文件和Backend。
3. 看重自动回滚：创建失败自动恢复，零残留。
4. AWS新服务刚发布：CloudFormation第一时间支持。

折中方案：

不少企业采用Terraform管理基础设施 + CloudFormation管理部分AWS专属资源的混合策略。也可以使用 AWS CDK（底层生成CloudFormation，但用Python/TypeScript编写），兼顾开发者体验和原生服务保障。

---

📚 常见误区澄清

误区	真相
“Terraform比CF快”	CF有预热机制，部分场景反而更快
“CF不能做循环”	可以用 Count 宏或Transforms实现
“Terraform不需要学习”	HCL语法虽简洁，但理解State/Dependency/Module仍需时间
“CF只支持YAML”	也支持JSON，还可以用CDK生成模板

---

💎 总结

Terraform 和 CloudFormation 不是替代关系，而是两种理念的产物：

• Terraform = 开源的、客户端驱动的、多云IaC瑞士军刀。
• CloudFormation = 原生的、托管式的、AWS深度集成的IaC服务。

选择哪一个，取决于你的云策略边界和团队运维能力。无论选哪个，拥抱IaC都是迈向云原生运维的第一步！

🌺The End🌺点点关注，收藏不迷路🌺 ⬆ ⬆ 顶部 ⬆ ⬆