📚 课程目录第1章课程导入

1. 课程导入

在传统 AWS 使用方式中，工程师通常通过控制台点击创建 EC2、RDS、S3、VPC 等资源。这种方式上手快，但当环境从“一个测试账号”扩展到“开发、测试、预发、生产多账号”时，问题会迅速暴露：谁改了安全组、生产与测试配置为何不一致、如何回滚一次错误发布、如何证明当前环境符合合规要求。基础设施即代码（Infrastructure as Code，IaC）正是为了解决这些问题：把云资源的定义、变更和治理都纳入可版本化、可审查、可自动执行的工程流程。

本课程围绕两条主线展开：一条是“用代码定义和交付 AWS 基础设施”，另一条是“用治理机制约束环境漂移、权限边界和变更风险”。学习目标可以归纳为四点：第一，理解 IaC 的核心概念与 AWS 上的落地方式；第二，能够使用 Terraform 或 AWS CloudFormation/CDK 编写可复用的基础设施代码；第三，掌握多环境隔离、状态管理、模块化与 CI/CD 集成；第四，建立环境治理意识，包括标签策略、合规检查、漂移检测、成本与安全基线。最终目标不是记住某个命令，而是形成一套可重复、可审计、可协作的云环境交付方法。

核心概念速览：IaC 不是“把控制台操作写成脚本”，而是把期望状态声明出来，由工具负责计算差异并执行变更。声明式、幂等性、状态文件、计划与应用、模块化、环境隔离、漂移检测，是贯穿全课程的关键词。

为了看清整体框架，可以把课程内容分为四层。最底层是“账号与网络基座”，包括 AWS Organizations、IAM、VPC、子网、路由和安全组；第二层是“资源定义与编排”，即用 Terraform 或 CloudFormation 描述计算、存储、数据库和负载均衡；第三层是“交付流水线”，把代码提交、计划审查、自动应用和回滚串起来；最上层是“环境治理”，通过标签、策略、合规扫描和成本监控保证多环境长期可控。下面这张图展示了从代码到多环境运行时的整体关系，而不是简单的步骤罗列。

图中左侧是代码仓库，中间是计划与流水线，右侧是多环境运行时，下方是治理层和实战路线图。需要特别注意的是，治理层并不是最后才补上的“附加项”，而是从第一天就要嵌入代码结构、流水线设计和账号策略中的约束条件。例如，标签策略如果不在模块中强制传入，后期再补就会产生大量未标记资源；IAM 权限如果一开始就使用管理员权限，后续再收紧会非常困难。

接下来用一个最小但完整的示例说明 IaC 的工作方式。假设我们要在开发账号中创建一台 EC2 实例，并为其绑定一个安全组，只允许来自公司办公网出口的 SSH 访问。使用 Terraform 时，核心代码大致如下：

provider "aws" {
  region = "ap-southeast-1"
}

resource "aws_security_group" "dev_ssh" {
  name        = "dev-ssh-sg"
  description = "Allow SSH from office CIDR"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Environment = "dev"
    Owner       = "platform-team"
    CostCenter  = "training"
  }
}

resource "aws_instance" "dev_app" {
  ami                    = "ami-0abcdef1234567890"
  instance_type          = "t3.micro"
  subnet_id              = var.subnet_id
  vpc_security_group_ids = [aws_security_group.dev_ssh.id]

  tags = {
    Name        = "dev-app-01"
    Environment = "dev"
    Owner       = "platform-team"
  }
}

这段代码中，provider 指定区域，aws_security_group 声明安全组规则，aws_instance 声明实例并引用安全组 ID。执行 terraform init 初始化后端和插件，terraform plan 会显示将要创建的资源数量与属性差异，terraform apply 才会真正调用 AWS API 创建资源。这里的关键判断依据是 plan 输出：如果 plan 显示“2 to add, 0 to change, 0 to destroy”，说明是首次创建；如果显示“0 to add, 1 to change, 0 to destroy”，则说明只修改了某个属性，需要进一步确认修改是否符合预期。示例中的 AMI ID、CIDR 和实例类型均为教学假设值，实际使用时必须替换为当前区域可用的真实值。

建议在课程初期就养成三个习惯：第一，所有资源必须打上 Environment、Owner、CostCenter 标签；第二，plan 结果必须经过人工或自动审查后再 apply；第三，生产环境变更必须走独立审批，不允许本地直接 apply。

环境治理的核心是“让正确的事情容易做，让错误的事情难以发生”。在 AWS 上，这通常通过组合手段实现：用 AWS Organizations 和 SCP 限制账号可执行的操作范围；用 IAM 角色和权限边界控制谁能改什么；用 AWS Config 或 Terraform 的漂移检测发现控制台手工修改；用标签策略和成本分配标签追踪费用归属；用 CloudTrail 记录所有 API 调用，形成审计链路。治理不是一次性任务，而是持续嵌入在代码审查、流水线门禁和定期巡检中的机制。

本课程的实战路线图按五个阶段推进：第一阶段搭建账号与网络基座，理解多账号结构和 VPC 基础；第二阶段编写资源声明与模块，掌握 Terraform 或 CloudFormation 的核心语法和模块复用；第三阶段管理状态与多环境，学会远程后端、工作区隔离和参数化；第四阶段集成 CI/CD 与审批，把 plan/apply 放入流水线并加入人工门禁；第五阶段建立治理与持续合规，包括标签、漂移检测、成本监控和安全基线。每个阶段都会给出可运行的示例、关键参数和结果判断方法，帮助你把“知道”变成“做到”。

学习本课程不需要先成为 AWS 专家，但需要具备基本的 Linux 命令行操作能力、了解 JSON/YAML 或 HCL 的基本语法，并有一个可用的 AWS 账号（建议使用个人学习账号或沙箱账号，避免直接在生产账号中实验）。如果你已经使用过控制台创建过 EC2 或 S3，那么你已经具备理解本课程的最佳起点：接下来要做的，是把这些点击操作转化为可版本化、可审查、可重复执行的代码与治理流程。