如何使用Terraform管理跨多账户多区域的AWS基础设施？

嘿，这个问题太常见了——当基础设施跨多个AWS账户和区域时，核心就是把你已经写好的VPC、ECS这些模块高效复用，同时把各个环境的状态和权限管好。我结合实际踩过的坑，给你梳理几个关键实践：

1. 用Provider配置灵活切换账户和区域 #

每个AWS账户/区域都需要独立的Provider配置，别硬编码凭证或区域，用变量动态指定才是正道。推荐用IAM角色切换（assume_role），比硬存Access Key安全太多，尤其是结合AWS Organizations的权限管控：

# 定义核心变量
variable "aws_account_id" {
  type        = string
  description = "目标AWS账户ID"
}

variable "aws_region" {
  type        = string
  description = "目标AWS区域"
}

# 配置带别名的Provider，方便跨账户调用
provider "aws" {
  alias   = "target"
  region  = var.aws_region
  assume_role {
    role_arn = "arn:aws:iam::${var.aws_account_id}:role/TerraformExecutionRole"
  }
}

调用模块时，直接指定对应的Provider即可：

module "ecs_cluster" {
  source     = "./modules/ecs-cluster"
  providers = {
    aws = aws.target
  }
  # 模块的其他自定义参数...
}

2. 状态文件绝对要隔离，别混在一起 #

这是最容易踩坑的地方！不同账户/区域的Terraform状态绝对不能共用，否则一不小心就会误删其他环境的资源。常用的隔离方案：

• 按账户+区域拆分工作目录：比如创建prod-us-east-1、stage-eu-west-1这样的独立目录，每个目录有自己的terraform.tfvars和状态配置，彻底物理隔离。
• 远程状态存储必开：不管用哪种目录结构，都把状态文件存在S3（每个账户单独建桶，或者按account/region前缀区分），同时开启版本控制和DynamoDB锁，防止多人并发修改搞乱状态。比如桶名可以设为tf-state-${aws_account_id}-${aws_region}，权限锁死只有Terraform执行角色能访问。
• 如果你不想拆太多目录，也可以用Terraform工作区（Workspace），但它更适合同一个账户下的多环境（比如prod/stage），跨账户还是推荐目录拆分，避免变量冲突。

3. 用变量和参数实现模块的环境适配 #

既然你已经有了核心模块，那就通过模块的输入变量来适配不同账户/区域的差异：

• 比如VPC模块可以暴露cidr_block、az_count变量，不同区域可用区数量不同，就在对应的prod.tfvars、stage.tfvars里配置。
• 把账户ID、区域、资源规格这些环境专属参数单独放在变量文件里，执行时用terraform apply -var-file=prod.tfvars加载，不用每次手动敲参数。

4. 批量管理的进阶技巧 #

如果账户和区域数量多，手动一个个执行太麻烦，可以试试这些方法：

• Terraform Cloud/Enterprise：用它的Workspace来管理每个账户/区域的配置，设置变量集批量复用参数，还能自动触发运行、做权限管控，适合团队协作场景。
• 脚本封装：写个简单的Shell脚本遍历你的账户/区域列表，自动加载对应变量文件执行Terraform命令，比如：

#!/bin/bash
# 定义环境列表：环境名 区域 账户ID
environments=(
  "prod us-east-1 123456789012"
  "stage eu-west-1 987654321098"
  "dev ap-southeast-1 456789012345"
)

for env in "${environments[@]}"; do
  read -r name region account <<< "$env"
  echo "===== 部署${name}环境（${region}/${account}） ====="
  terraform apply -var-file="${name}.tfvars" -var "aws_account_id=${account}" -var "aws_region=${region}" -auto-approve
done

• 结合AWS Organizations：如果是用Org管理账户，可以用aws_organizations_account数据源批量获取账户列表，再用Terraform的for_each循环批量部署标准化资源。

5. 权限控制的最佳实践 #

• 每个AWS账户都创建专门的Terraform执行角色，遵循最小权限原则，只给它部署对应资源需要的权限，别开管理员权限。
• 用AWS Organizations的SCP（服务控制策略）给整个OU的账户设置权限边界，防止Terraform角色越权。
• 绝对不要在本地存储AWS凭证，一律用assume_role或者EC2/ECS实例角色（如果是在AWS内部运行Terraform）。

内容的提问来源于stack exchange，提问作者Akshay Gopani