2. AWS环境标准化工程基础

在AWS上做IaC，真正决定长期可维护性的往往不是Terraform写得多漂亮，而是环境边界是否清晰。开发、测试、预发、生产四套环境如果命名混乱、标签缺失、账号混用，那么再好的模块化设计也会在半年后变成一堆无法追溯的资源。本节围绕三个基础工程要素展开：命名规范、标签策略、账号与区域划分原则。

一、命名规范：让资源名自带环境与用途信息

命名规范的目标是：看到资源名就能判断它属于哪个环境、哪个业务、哪个区域、什么类型。推荐采用分段式命名，用连字符分隔，全小写，避免下划线和大写混用（部分AWS资源名对大小写敏感，统一小写可减少歧义）。

一个可落地的命名模板为：

{org}-{env}-{region}-{service}-{resource}-{seq}

示例：
acme-dev-cn-north-1-order-sg-01
acme-prod-cn-north-1-order-rds-01
acme-stg-cn-north-1-payment-lambda-01

其中 env 建议固定为四个短码：dev、tst、stg、prd。不要用 development、test、staging、production 这类长词，因为很多资源名有长度限制（如S3桶名最长63字符、Lambda函数名最长64字符），短码能留出更多空间给业务标识。

需要特别注意两类资源：

• S3桶名：全局唯一，必须包含账号或组织标识，例如 acme-prd-cn-north-1-order-logs，避免与他人冲突。
• IAM角色与策略：建议用 acme-prd-order-lambda-exec 这种“环境+服务+用途”结构，便于审计时快速定位。

命名规范一旦确定，应写入IaC的变量默认值或模块输入约束中，而不是靠人工记忆。例如在Terraform中通过 locals 统一拼接：

locals {
  name_prefix = "${var.org}-${var.env}-${var.region}"
}

resource "aws_s3_bucket" "logs" {
  bucket = "${local.name_prefix}-order-logs"
}

二、标签策略：用标签承载成本、归属与生命周期

标签是AWS环境中成本分摊、权限控制、自动化运维的核心元数据。命名解决“叫什么”，标签解决“归谁、花多少、何时清理”。建议每个可打标签的资源至少包含以下五类标签：

标签策略要解决两个实际问题：一是强制性与默认值，二是成本与清理。在AWS Organizations中可以使用Tag Policies强制某些标签键必须存在；在IaC侧则通过模块的 default_tags 统一注入，避免每个资源重复写：

provider "aws" {
  default_tags {
    tags = {
      Environment = var.env
      Project     = "order-platform"
      Owner       = "team-payment"
      ManagedBy   = "terraform"
    }
  }
}

对于临时环境（如dev、tst），建议额外增加 ExpireDate 或 AutoCleanup=true 标签，配合Lambda定时任务扫描并清理过期资源，防止开发环境长期占用成本。

三、账号与区域划分原则

账号划分的核心原则是按环境隔离，按业务聚合。推荐使用AWS Organizations，将生产环境放在独立账号，开发、测试、预发可以合并到同一账号但用VPC和标签隔离，也可以各自独立账号。判断依据是合规要求与爆炸半径：生产账号必须独立，因为生产资源的误删、误改影响面最大；预发环境如果与生产配置高度一致，也建议独立账号，避免测试流量污染生产数据。

区域划分遵循三条原则：

1. 主区域固定：每个环境选定一个主区域（如 cn-north-1 或 us-east-1），所有核心资源默认部署在主区域，减少跨区域延迟和流量费用。
2. 灾备区域明确：生产环境需要明确灾备区域（如 cn-northwest-1），但灾备区域的资源应由独立的IaC工作区或目录管理，避免与主区域状态耦合。
3. 区域写入命名与标签：区域代码应出现在资源名和标签中，便于多区域资源统一检索。

下面这张图展示了四套环境在账号、区域、命名前缀与标签上的对应关系，以及IaC如何通过变量将三者串联起来。

从图中可以看出，四套环境共享同一套IaC模块，差异只体现在 var.env、账号和区域变量上。这种“同构不同参”的方式，正是环境标准化的核心：结构一致、参数隔离、边界清晰。

四、落地检查清单

在项目启动阶段，建议用以下清单逐项确认，避免后期返工：

• 命名模板是否已写入IaC变量默认值或模块约束？
• 四套环境的 env 短码是否统一为 dev/tst/stg/prd？
• 是否使用 default_tags 统一注入 Environment、Project、Owner、ManagedBy？
• 生产账号是否独立？预发是否与生产隔离？
• 主区域与灾备区域是否明确，且灾备资源是否独立管理？
• 临时环境是否配置 AutoCleanup 与 ExpireDate 标签？
• 标签键大小写是否统一？

命名、标签、账号与区域这三件事，看起来是“规范”，实际上是IaC能否规模化的地基。地基打牢之后，后续的模块设计、状态管理、CI/CD流水线才有稳定的输入和可预期的输出。