OpenTofu 与 Terraform 多云基础设施实战：一套代码管理阿里云+AWS（2026版）

Meta Description: 出海企业怎么用一套代码同时管理阿里云和 AWS？OpenTofu/Terraform 多 provider 实战教程：双云 VPC 一键创建、远程 State 与锁、模块化多区域写法、GitHub Actions 自动 plan/apply，附完整配置模板与厂商对比表，可直接复制上手。

关键词： OpenTofu、Terraform、多云IaC、基础设施即代码、阿里云AWS、State管理、多云架构、出海企业

前言

用 Terraform 或 OpenTofu 管理多云基础设施的核心答案是：一套 HCL 代码声明式描述阿里云+AWS 的全部资源，通过多个 Provider 和一份（或按环境拆分的多份）远程 State 统一编排，配合 CI/CD 让每一次变更都经过 plan 评审再 apply——这是当前多云环境下最成熟、生态最完整的 IaC 方案。 手动在阿里云控制台点完再去 AWS 控制台点一遍的时代已经过去了：资源一多，配置漂移、权限混乱、重复造轮子的问题会成倍放大，而多云 IaC 让"两地三中心"这类架构真正具备了可重复、可审计、可回滚的工程基础。

本文以 OpenTofu 为主角（Terraform 的开源分支，命令与生态完全兼容），从工具选型讲起，覆盖安装配置、双云 VPC 实战、State 管理、模块化工程化、CI/CD 集成五大块，所有代码均基于 2026 年 8 月最新的 Provider 版本验证，可直接复制到自己的项目里改参数使用。

一、为什么多云环境必须用 IaC 统一管理

出海企业踩过最痛的坑，往往不是选错云厂商，而是每个云一套管理方式：阿里云资源用控制台点、AWS 资源用 CloudFormation 堆、腾讯云资源靠运维手写脚本，三个环境三种语言，没人说得清线上到底跑着什么。这种"多云混沌"带来的问题非常具体：

1. 配置漂移：上线时手动配的规则，三个月后没人记得谁改过，安全组悄悄多开了一个 0.0.0.0/0 端口，等被扫描器打穿才追悔莫及。
2. 无法重建：没有代码化描述，新环境从零搭建要两周，且永远搭不出和线上一样的东西。
3. 变更不可审计：谁在什么时候改了什么资源，没有任何记录，合规审计一问三不知。
4. 重复成本：同一套网络拓扑、同一份监控告警，在每朵云上都要重写一遍。

IaC（Infrastructure as Code）解决的就是这四个问题：资源声明式定义在代码里，走 Git 版本控制，变更经过 review 和 plan，环境随时可重建，跨云逻辑可复用。而 Terraform/OpenTofu 之所以成为多云 IaC 的事实标准，是因为它的 Provider 架构——每一朵云都有一个官方维护的 Provider 插件，暴露统一的 HCL 语法，你不需要学三套 DSL。

二、Terraform 与 OpenTofu：2026 年怎么选

OpenTofu 诞生于 2023 年 HashiCorp 将 Terraform 从 MPL 2.0 协议改为 BUSL 商业许可证之后，社区将 Terraform v1.5 时代的分支接管并捐赠给 Linux 基金会，以 MPL 2.0 协议永久开源。到今天两者已经并行发展了两年多，命令、Provider、State 格式完全兼容，绝大多数场景可以无缝互换：

结论很直接：没有存量 Terraform Enterprise 绑定的团队，2026 年新项目直接上 OpenTofu 是更稳的选择——协议上不会再有被收紧的风险，功能上 State 加密这种原本企业版才有的能力开源就能用。已有 Terraform 项目的迁移也极简单：alias terraform=tofu 或者直接换二进制，tofu init 会复用已有的 .terraform.lock.hcl，State 文件格式相同，无需转换。本文以下命令以 tofu 为例，Terraform 用户把 tofu 换成 terraform 即可。

三、核心概念：Provider、State 与远程锁

动手之前，先建立三个概念，多云 IaC 的所有设计都围绕它们展开：

• Provider：连接 Terraform/OpenTofu 与云厂商 API 的插件。阿里云是 aliyun/alicloud，AWS 是 hashicorp/aws，腾讯云是 tencentcloudstack/tencentcloud。一个项目里可以同时声明多个 Provider（包括同一朵云的多个 Region 别名）。
• State（状态文件）：记录"代码声明的资源"与"云上真实资源"对应关系的数据库。tofu plan 对比的就是 State 和真实云资源，State 丢了等于失忆。State 绝不能提交进 Git（含敏感信息、明文资源 ID），必须放远程存储并开启锁。
• 远程后端（Backend）+ 锁：State 放在共享存储（阿里云 OSS / AWS S3），配合锁表（Tablestore / DynamoDB）防止两个人同时 apply 造成冲突。这是多人协作的底线配置。

整体架构如下图所示：

graph TD
    A[Git 仓库 infra/ 目录<br/>main.tf variables.tf outputs.tf modules/] --> B[tofu CLI 或 CI/CD 流水线]
    B --> C[远程 State 后端<br/>OSS / S3 + 锁表]
    B --> D[alicloud Provider]
    B --> E[aws Provider]
    D --> F[阿里云: VPC / vSwitch / ECS / SLB]
    E --> G[AWS: VPC / Subnet / EC2 / ALB]
    H[GitHub Actions plan 评审] --> B

用 ASCII 图看数据流更直观：

┌───────────────────────────────────────────────┐
│         Git 仓库  infra/  （唯一事实来源）       │
│   main.tf  variables.tf  outputs.tf  modules/  │
└──────────────────────┬────────────────────────┘
                       │  tofu plan / apply
          ┌────────────┴─────────────┐
          ▼                          ▼
┌───────────────────┐      ┌─────────────────────┐
│  alicloud Provider│      │  aws Provider       │
├───────────────────┤      ├─────────────────────┤
│ VPC / vSwitch     │      │ VPC / Subnet / IGW  │
│ ECS / SLB / SG    │      │ EC2 / ALB / SG      │
└───────────────────┘      └─────────────────────┘
          │                          │
          └────────────┬─────────────┘
                       ▼
        ┌─────────────────────────────┐
        │  远程 State（OSS / S3）       │
        │  + 锁表（Tablestore/DynamoDB）│
        └─────────────────────────────┘

关键认知：Provider 越多，State 的设计越重要。单云项目 State 随便放问题不大，多云项目一旦 State 管理混乱，轻则 plan 输出看不懂，重则 apply 错环境。第四节开始逐步落地。

四、环境准备：安装 OpenTofu 与双云凭证配置

4.1 安装 OpenTofu

RHEL/CentOS 系（含阿里云 ECS 常用镜像）用官方 RPM 源：

// RPM 方式安装（RHEL/CentOS/AlmaLinux）
sudo rpm --import https://rpm.opentofu.org/gpg.key
curl -fsSL https://rpm.opentofu.org/setup-rpm.sh | sudo bash
sudo dnf install -y tofu

// 验证
tofu version
// OpenTofu v1.8.x（兼容 Terraform 1.6+ 的 HCL 与 State）

macOS 用户 brew install opentofu，Ubuntu 用户用 apt 源，Windows 用户用官方二进制或 winget install LinuxFoundation.OpenTofu。安装完建议加一行 shell 别名方便肌肉记忆：alias terraform=tofu。

4.2 双云凭证：绝不写进代码

阿里云和 AWS 的 AccessKey 属于最高敏感级凭证，永远不要出现在 .tf 文件、Git 历史或 plan 输出里。推荐两种方式：

方式一：环境变量（CI 场景首选）

// 阿里云凭证
export ALICLOUD_ACCESS_KEY="LTAI5tXXXXXXXXXXXX"
export ALICLOUD_SECRET_KEY="your-alicloud-secret"

// AWS 凭证
export AWS_ACCESS_KEY_ID="AKIAXXXXXXXXXXXX"
export AWS_SECRET_ACCESS_KEY="your-aws-secret"
export AWS_DEFAULT_REGION="ap-southeast-1"

方式二：共享凭证文件（本地开发首选）

// 阿里云：~/.alibabacloud/credentials
[default]
type = access_key
access_key_id = LTAI5tXXXXXXXXXXXX
access_key_secret = your-alicloud-secret
region_id = ap-southeast-1

// AWS：~/.aws/credentials
[default]
aws_access_key_id = AKIAXXXXXXXXXXXX
aws_secret_access_key = your-aws-secret

~/.gitignore 里必须包含以下条目（防止手滑提交凭证文件）：

*.tfstate
*.tfstate.*
.terraform/
*.tfvars
*.tfvars.json

安全底线：给云账号的子账号（RAM 用户 / IAM User）签发凭证，并只授予 IaC 所需的最小权限（如 VPC 全读写、ECS 全读写），主账号密钥一律禁用。生产环境强烈建议结合 08-07 那篇多云 IAM 方案做角色联邦，让 CI 用临时凭证而非长期密钥。

五、实战：一套代码创建阿里云 + AWS 双 VPC

现在写真正的多云配置。目标：新加坡区域（ap-southeast-1）同时创建阿里云 VPC 和 AWS VPC，各带一个公网 vSwitch/Subnet，打上统一标签。项目结构：

infra/
├── main.tf          // Provider 与资源定义
├── variables.tf     // 变量声明
├── outputs.tf       // 输出：VPC ID、网段等
└── versions.tf      // 版本与后端约束

5.1 versions.tf —— 锁定版本与声明后端

terraform {
  required_version = ">= 1.6"

  required_providers {
    alicloud = {
      source  = "aliyun/alicloud"
      version = "~> 1.220"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}

5.2 main.tf —— 双 Provider + 双 VPC

// ===== Provider 声明 =====
provider "alicloud" {
  region = "ap-southeast-1"   // 新加坡
}

provider "aws" {
  region = "ap-southeast-1"   // 新加坡
}

// ===== 统一标签 =====
locals {
  common_tags = {
    Env        = "prod"
    Owner      = "platform"
    CostCenter = "app-2026"
  }
}

// ===== 阿里云 VPC =====
resource "alicloud_vpc" "main" {
  vpc_name   = "tofu-alicloud-vpc"
  cidr_block = "10.1.0.0/16"
  tags       = local.common_tags
}

resource "alicloud_vswitch" "public" {
  vpc_id     = alicloud_vpc.main.id
  cidr_block = "10.1.1.0/24"
  zone_id    = "ap-southeast-1a"
}

// ===== AWS VPC =====
resource "aws_vpc" "main" {
  cidr_block           = "10.2.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags                 = merge(local.common_tags, { Name = "tofu-aws-vpc" })
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.2.1.0/24"
  availability_zone = "ap-southeast-1a"
  tags              = merge(local.common_tags, { Name = "tofu-aws-public" })
}

5.3 outputs.tf —— 输出给下游使用

output "alicloud_vpc_id" {
  value = alicloud_vpc.main.id
}

output "aws_vpc_id" {
  value = aws_vpc.main.id
}

output "aws_vpc_cidr" {
  value = aws_vpc.main.cidr_block
}

5.4 执行流程

cd infra
tofu init          // 下载两个 Provider 插件，生成 .terraform.lock.hcl
tofu plan          // 输出双云资源创建计划，重点看 "+ create" 列表
tofu apply         // 确认后执行，两端 VPC 同时创建
tofu state list    // 查看 State 中管理的全部资源

一次 apply 的典型输出尾部（节选）：

alicloud_vpc.main: Creation complete after 8s
aws_vpc.main: Creation complete after 3s
aws_subnet.public: Creation complete after 2s
alicloud_vswitch.public: Creation complete after 6s

Apply complete! Resources: 4 added, 0 changed, 0 destroyed.

就这么简单——控制台里二十分钟的手工活，代码化之后每次创建只需 30 秒，而且永远一致。后续加 ECS/EC2、SLB/ALB、安全组，都是在 main.tf 里追加资源块再 tofu apply。

六、State 管理：单 State 还是多 State？

这是多云 IaC 项目里争论最多、踩坑最多的设计决策。两种模式各有适用场景：

生产环境推荐"多 State + 分层"：按云拆分（state-alicloud / state-aws）+ 按环境拆分（prod / staging），网络层、应用层、数据层各自独立 State。跨层引用用数据源读取，而不是硬编码：

// 从 AWS 网络层 State 读取 VPC ID
data "terraform_remote_state" "aws_network" {
  backend = "s3"
  config = {
    bucket = "my-company-tofu-state"
    key    = "envs/prod/aws-network.tfstate"
    region = "ap-southeast-1"
  }
}

resource "aws_security_group" "app" {
  vpc_id = data.terraform_remote_state.aws_network.outputs.vpc_id
  // ...
}

无论单 State 还是多 State，远程后端 + 锁都是必须的。阿里云 OSS 后端配置：

terraform {
  backend "oss" {
    bucket               = "my-company-tofu-state"
    prefix               = "envs/prod/multicloud"
    region               = "ap-southeast-1"
    // 锁表：Tablestore 实例
    tablestore_endpoint  = "https://tofu-lock.ap-southeast-1.ots.aliyuncs.com"
    tablestore_table     = "terraform-lock"
  }
}

AWS S3 后端配置：

terraform {
  backend "s3" {
    bucket         = "my-company-tofu-state"
    key            = "envs/prod/aws-network.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-lock"
  }
}

⚠️ 高频事故提醒：多人共享 State 却不加锁，两人同时 tofu apply，轻则 State 冲突需要 tofu force-unlock，重则资源被错误修改。锁表（Tablestore/DynamoDB）就是干这个的，务必配上。

七、模块化与循环：多区域、多环境的工程化写法

资源一多，main.tf 会膨胀到几千行。工程化的第一步是抽模块（Module），第二步是用 for_each 消灭重复代码。

7.1 模块：双云共享同一套模板

把"VPC + 子网 + 安全组"抽成模块 modules/vpc/，阿里云和 AWS 各自实例化：

// modules/vpc/main.tf（以 AWS 为例）
variable "name" { type = string }
variable "cidr"  { type = string }
variable "tags"  { type = map(string) }

resource "aws_vpc" "this" {
  cidr_block = var.cidr
  tags       = merge(var.tags, { Name = var.name })
}

顶层调用：

module "vpc_singapore" {
  source   = "./modules/vpc"
  name     = "sg-prod-vpc"
  cidr     = "10.2.0.0/16"
  tags     = local.common_tags
}

module "vpc_oregon" {
  source   = "./modules/vpc"
  name     = "us-prod-vpc"
  cidr     = "10.3.0.0/16"
  tags     = local.common_tags
}

7.2 for_each：一个 Provider 别名循环多区域

AWS 侧需要多区域时，用 Provider 别名 + for_each：

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

provider "aws" {
  alias  = "oregon"
  region = "us-west-2"
}

resource "aws_vpc" "multi" {
  for_each = {
    singapore = "10.4.0.0/16"
    oregon    = "10.5.0.0/16"
  }
  provider   = aws.singapore // 说明：多区域场景建议按区域拆 State，
                             // 单 State 多 provider 别名只适合少量固定区域
  cidr_block = each.value
  tags       = merge(local.common_tags, { Region = each.key })
}

工程化三原则：① 变量化一切（区域、网段、实例规格都走 variables.tf + .tfvars）；② 环境用目录拆分（envs/prod/、envs/staging/ 各一份 backend 配置）；③ 所有资源强制打标签（Env/Owner/CostCenter），这是后续成本分账和权限治理的前提。

八、CI/CD 集成：GitHub Actions 自动 plan/apply

多云 IaC 的终极形态是代码合并即变更。用 GitHub Actions 实现"PR 触发 plan、合并主分支触发 apply"的黄金流程：

// .github/workflows/tofu.yml
name: OpenTofu

on:
  pull_request:
    paths: ["infra/**"]
  push:
    branches: [main]
    paths: ["infra/**"]

jobs:
  plan:
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.8.x
      - run: tofu init
        working-directory: infra
      - run: tofu plan -no-color
        working-directory: infra
        env:
          ALICLOUD_ACCESS_KEY: ${{ secrets.ALICLOUD_ACCESS_KEY }}
          ALICLOUD_SECRET_KEY: ${{ secrets.ALICLOUD_SECRET_KEY }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

  apply:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.8.x
      - run: tofu init
        working-directory: infra
      - run: tofu apply -auto-approve -no-color
        working-directory: infra
        env:
          ALICLOUD_ACCESS_KEY: ${{ secrets.ALICLOUD_ACCESS_KEY }}
          ALICLOUD_SECRET_KEY: ${{ secrets.ALICLOUD_SECRET_KEY }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

落地要点：

• Secrets 存 GitHub 仓库的 Secrets 区，工作流里只引用 ${{ secrets.* }}，日志默认脱敏；
• environment: production 启用 GitHub 的审批门——apply 前需要指定 reviewer 手动批准，杜绝"合并即炸"；
• plan 的产物可以上传 artifact 供 reviewer 下载核对，或让机器人把 plan 输出贴到 PR 评论里；
• 更进阶的团队用 Atlantis 或 Terraform Cloud/OpenTofu 的 OSS 版做 PR 内自动评论 plan，体验更顺。

九、三朵云 Provider 能力对比与参考价格

多云 IaC 的另一半决策是"哪朵云管什么"。三大厂商的官方 Provider 成熟度如下：

以新加坡区域 2核4G 通用型实例为例（按量付费，2026 年 8 月官网公开价，实际以官网实时报价为准）：

选型建议：IaC 管理下切换成本大幅降低，所以更应"按业务选云"——面向东南亚用户的低延迟业务放新加坡双活（可参考本站双活架构文章），合规要求高的欧洲业务放 AWS 欧洲区，需要国内互通资源选腾讯云或阿里云。代码化之后，这个选择随时可以调整，这正是多云 IaC 的隐藏红利。

总结

多云 IaC 的本质，是把"在多朵云之间来回点控制台"的混乱，收敛成一份代码、一次评审、一次 apply 的工程纪律。本文从工具选型（OpenTofu 开源可控）、核心概念（Provider/State/锁）、双云 VPC 实战、多 State 拆分、模块化工程化到 GitHub Actions 自动化，给出了一条可以直接照抄的落地路径。记住三个关键结论：新项目优先 OpenTofu（协议安全、功能不落后）；生产环境必须远程 State + 锁（多人协作的底线）；按云拆 State、按环境拆目录（变更风险隔离的工程化基石）。把这套体系搭起来之后，你会发现多云不仅不再是负担，反而成了业务随时可以在不同云之间迁移和比价的底气。

🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。从多云 IaC 体系搭建、双活架构设计、CI/CD 流水线到 FinOps 成本治理，我们提供一站式企业级云服务。

相关阅读

• Terraform vs CloudFormation：AWS 基础设施即代码深度对决 — 单云场景下的 IaC 选型对比，与本文多云视角互补
• 企业出海多云架构设计：阿里云+AWS双活方案实战指南 — 用 IaC 落地双活架构的完整网络与数据层设计
• 多云统一身份认证实战：Keycloak 接入阿里云RAM与AWS IAM — IaC 凭证安全的上层方案：角色联邦与临时凭证
• 海外云服务器成本优化实战：预留+Spot+自动伸缩组合策略 — 资源代码化之后，下一步就是让成本代码化

本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多