用 Terraform 落地 Landing Zone：多账号云上基线不要只停在架构图

Landing Zone 要解决什么

很多团队第一次上云时会从单账号开始：一个账号里放开发、测试和生产环境，网络靠人工创建，权限靠临时授权，日志在每个项目里各管各的。项目少时还能运转，一旦组织规模扩大，问题会集中出现。

典型问题包括：生产和测试资源混在一起，审计日志缺失；不同项目网络地址冲突；RAM 或 IAM 权限长期过大；安全组规则没有统一约束；预算无法归因；新项目从申请账号到上线要靠文档复制。Landing Zone 的目标就是把这些基础能力做成可复制的“落地区”，让业务团队在安全边界内快速交付。

社区推荐 Terraform 构建 Landing Zone 的实践，关键启发是使用 IaC 把基线显性化。架构图可以说明目标状态，但只有代码能持续验证当前环境是否偏离目标。

基线应包含哪些层

建议把 Landing Zone 拆成六层。

第一层是账号与组织。至少区分管理账号、日志账号、安全账号、共享服务账号和业务账号。业务账号可以按环境或项目拆分，避免一个账号承载所有生命周期。

第二层是网络。统一规划 VPC CIDR、子网、路由、NAT、对等连接或云连接。网络基线要提前定义地址分配规则，避免后续互联时才发现冲突。

第三层是身份与权限。权限不应从个人开始设计，而应从角色开始，例如只读审计、网络管理员、应用发布、成本查看、安全运营。个人或流水线服务账号再绑定角色。

第四层是日志与审计。关键操作日志、访问日志、流量日志和安全事件要进入集中账号或集中存储，避免业务账号被误删后证据同时消失。

第五层是安全控制。包括基础安全组模板、加密策略、密钥管理、公网暴露白名单、镜像来源约束和漏洞扫描要求。

第六层是成本与标签。资源标签必须在创建时写入，至少包含 owner、env、system、cost_center、data_level。

Terraform 项目结构

landing-zone/
  modules/
    network/
    iam-role/
    logging/
    security-baseline/
    budget-tagging/
  envs/
    dev/
      main.tf
      variables.tf
      terraform.tfvars
    prod/
      main.tf
      variables.tf
      terraform.tfvars
  policies/
    tags.rego
    network.rego

modules 目录放可复用能力，envs 目录放环境装配。这样做可以让开发环境先验证模块，再推广到生产环境。每个环境都应使用独立状态文件，状态文件要放在受控后端，不能提交到 Git。

网络模块示例

下面是一个简化的 VPC 模块，用于说明变量、标签和输出的组织方式。实际资源类型应按团队使用的华为云 Terraform Provider 版本调整。

variable "name" {
  type = string
}

variable "vpc_cidr" {
  type = string
}

variable "tags" {
  type = map(string)
}

resource "huaweicloud_vpc" "this" {
  name = var.name
  cidr = var.vpc_cidr
  tags = var.tags
}

resource "huaweicloud_vpc_subnet" "app" {
  name       = format("%s-app", var.name)
  cidr       = cidrsubnet(var.vpc_cidr, 8, 10)
  gateway_ip = cidrhost(cidrsubnet(var.vpc_cidr, 8, 10), 1)
  vpc_id     = huaweicloud_vpc.this.id
  tags       = var.tags
}

output "vpc_id" {
  value = huaweicloud_vpc.this.id
}

output "app_subnet_id" {
  value = huaweicloud_vpc_subnet.app.id
}

这段代码体现三个原则：CIDR 从变量传入，避免模块内写死；标签作为必填 map 传入，避免资源漏标；输出只暴露必要 ID，减少模块间耦合。

账号初始化流程

新业务账号接入 Landing Zone 时，可以走固定流程。

1. 在账号清单中登记业务系统、负责人、环境、成本中心和数据等级。
2. 分配不冲突的网络地址段。
3. 选择需要启用的模块，例如网络、日志、安全组、预算、只读审计角色。
4. 在合并请求中执行 terraform plan，并由平台团队评审。
5. 合并后由流水线执行 terraform apply。
6. 输出账号基线报告，包括资源清单、角色清单、日志投递状态和标签覆盖率。

账号清单可以是一份 YAML：

accounts:
  - name: order-prod
    env: prod
    owner: order-team
    cost_center: cc-1024
    data_level: confidential
    cidr: 10.42.0.0/16
    modules:
      - network
      - logging
      - security-baseline
      - budget-tagging

流水线读取这份清单生成 tfvars，或者由平台工程师按模板填充。重点是让账号开通过程可审计，而不是靠聊天记录和人工截图。

策略即代码：把规则挡在 apply 之前

Landing Zone 的价值不只是创建资源，还要阻止明显不合规的资源进入环境。可以在 Terraform plan 后加入策略检查。

常见规则包括：

1. 生产环境禁止创建 0.0.0.0/0 入方向管理端口。
2. 所有资源必须带 owner、env、cost_center 标签。
3. 生产账号禁止直接创建公网 IP，除非在白名单中。
4. 数据等级为 confidential 的存储必须开启加密。
5. 安全日志投递目标不能位于业务账号。

一个简化的标签检查思路如下：

package terraform.tags

required_tags := {"owner", "env", "cost_center"}

deny[msg] {
  resource := input.resource_changes[_]
  resource.change.after.tags == null
  msg := sprintf("resource %s has no tags", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  missing := required_tags - {tag | resource.change.after.tags[tag]}
  count(missing) > 0
  msg := sprintf("resource %s missing tags %v", [resource.address, missing])
}

策略检查失败时不要让流水线继续 apply。这样平台团队不会在资源创建后再追着业务方补标签或关公网端口。

常见坑位

第一个坑是过度追求一次性大而全。Landing Zone 可以先覆盖账号、网络、日志、标签四件事，再逐步扩展安全扫描、预算和合规报表。

第二个坑是状态文件管理混乱。生产环境的 Terraform state 必须有访问控制、版本保留和锁机制，不能放在个人电脑上。

第三个坑是模块过度抽象。模块不是越通用越好。一个模块如果有几十个开关，使用成本会超过复制少量代码。

第四个坑是没有导入存量资源。已经手工创建的关键资源应通过 terraform import 或迁移计划纳入管理，避免 Terraform 认为环境为空而重复创建。

第五个坑是忽视例外流程。现实中总会有临时公网、特殊路由或第三方接入需求。例外要有过期时间、审批记录和自动复查，而不是永久白名单。

验证方法

Landing Zone 上线后，可以从四个维度验证。

资源维度：随机抽取业务账号，检查 VPC、子网、日志投递、角色和标签是否符合模板。

权限维度：用只读账号确认能查看审计数据，但不能修改生产资源；用发布账号确认只能操作指定命名空间或项目。

网络维度：验证开发、测试、生产地址段不冲突，关键路由符合设计，管理端口没有意外暴露。

漂移维度：定期执行 terraform plan，发现手工变更后进入评审，而不是直接覆盖。

从存量环境迁移的路线

大多数团队不是从零开始建设 Landing Zone，而是已经有一批手工创建的账号和资源。迁移时不要急着把所有资源一次性导入 Terraform，风险太高。更稳妥的路线是先冻结新增入口，再分层纳管。

第一阶段只做盘点和标签补齐。通过资源清单识别账号、VPC、子网、EIP、安全组、日志桶、密钥和数据库实例，补齐 owner、env、cost_center 等标签。这个阶段不改变网络和权限，主要建立可见性。

第二阶段纳管公共基线。优先把日志投递、只读审计角色、预算告警和默认安全组规则纳入 Terraform。这些资源对业务影响相对可控，但能快速提升治理能力。

第三阶段迁移网络和权限。网络路由、对等连接、NAT 和生产权限变化影响面大，必须逐账号制定窗口和回滚方案。迁移前先用 terraform import 导入当前状态，再执行 plan，确认没有意外销毁或重建。

第四阶段才考虑业务资源。数据库、缓存、负载均衡等有状态资源不一定都要立即纳管，尤其是历史命名和依赖复杂的系统。Landing Zone 的优先目标是让新项目走标准基线，让存量项目逐步减少漂移。

每个阶段都应该产出验收证据，而不是只看 Terraform 执行成功。证据可以包括资源清单、标签覆盖率、策略检查报告、审计日志投递截图或导出文件，以及本阶段未纳管资源列表。未纳管并不等于失败，只要原因、负责人和后续计划清楚，平台团队就能持续推进，而不会把治理工作变成一次短促的大迁移。

总结

Landing Zone 的本质是把组织的云上治理经验沉淀成可执行基线。Terraform 适合承担这件事，因为它让账号、网络、权限、日志、安全和成本规则都能被代码审查、流水线验证和持续回放。不要把 Landing Zone 做成一次性咨询文档，也不要急着覆盖所有云服务；先把新账号创建和核心安全边界做稳，后续每个业务系统都会受益。