出海企业多云账号治理 Landing Zone 实战：阿里云资源目录+AWS Organizations统一管控指南（2026版）

Meta Description: 出海企业同时用阿里云和AWS，账号怎么管？本文给出多云Landing Zone完整方案：账号结构设计、管控策略SCP、统一身份、日志审计集中化，附阿里云资源目录+AWS Organizations+腾讯云企业组织实操命令与三厂商能力对比表。

关键词： Landing Zone、多账号治理、阿里云资源目录、AWS Organizations、SCP管控策略、多云管理、出海企业云架构、云治理中心

前言

出海企业用多朵云已经是常态——业务放AWS、合规数据留阿里云、测试用腾讯云，三套账号体系各自为政，半年后账号几十个、权限靠截图交接、账单没人看得懂。多云Landing Zone就是把这几十个账号收编成一套可治理体系的标准做法：用阿里云资源目录+AWS Organizations做账号骨架，用管控策略（SCP）统一划权限边界，用集中日志账号收审计数据。本文不重复之前的AWS单云治理文章，而是给出同时管三朵云的可落地方案，从账号结构设计到Terraform落地，一条龙讲完。

为什么出海企业必须做多云账号治理

先看三个真实场景，中招的出海团队不在少数：

1. 账号像野草一样长：每个项目组自己注册云账号，付费用主账号信用卡，半年后没人说得清有多少账号、每个账号里跑着什么；
2. 权限边界失控：一个员工离职，要跑三朵云各删一遍权限；开发环境误删生产库，因为没有环境隔离；
3. 审计无从谈起：海外融资尽调、ISO 27001审计、GDPR合规检查时，拿不出一份"谁在什么时候对哪朵云的什么资源做了什么"的统一记录。

这些问题的根子是同一个：把"开账号"的权力散落在每个工程师手里，却没有配套的治理框架。Landing Zone（着陆区）正是为此而生——它不是某个云厂商的产品，而是一套账号结构+基线策略+集中管控的组织方式：先定义好账号怎么分、权限怎么划、日志怎么收，再让业务团队在划好的跑道里自由起飞。

一、Landing Zone 的核心概念：账号、OU、管控策略、基线

Landing Zone 由四个积木组成，多云和单云的逻辑完全一致：

理解这四个积木后，多云治理就变成一个机械动作：在每朵云里搭同样的骨架，把同样的策略和基线铺进去。下面按"结构→策略→网络→日志"四层拆开讲。

二、多云账号结构设计：三层树形架构

无论哪朵云，推荐的结构都是三层树：根节点→环境层OU→业务账号。环境层按"生产/预发/开发"切分（比按部门切分更安全），业务账号按产品线命名。

graph TD
    Root[根目录 Root] --> Mgmt[管理账号<br/>运维+安全+日志]
    Root --> Prod[OU: 生产环境]
    Root --> Staging[OU: 预发环境]
    Root --> Dev[OU: 开发环境]
    Prod --> P1[业务A生产账号]
    Prod --> P2[业务B生产账号]
    Staging --> S1[业务A预发账号]
    Dev --> D1[开发沙箱账号]

ASCII 全景图（双云视角）：

┌─────────────────────────────────────────────────────┐
│              阿里云资源目录 (root)                     │
│  ┌─────────┐  ┌──────────────────────────────┐      │
│  │ 管理账号 │  │ 资源夹: production            │      │
│  │ 运维/审计 │  │  ├─ 电商生产账号              │      │
│  └─────────┘  │  ├─ 支付生产账号              │      │
│               │ 资源夹: staging / development  │      │
│               └──────────────────────────────┘      │
├─────────────────────────────────────────────────────┤
│              AWS Organizations (root)                │
│  ┌─────────┐  ┌──────────────────────────────┐      │
│  │ Mgmt acct│  │ OU: Production               │      │
│  │ audit/log│  │  ├─ ecommerce-prod           │      │
│  └─────────┘  │  ├─ payment-prod              │      │
│               │ OU: Staging / Dev             │      │
│               └──────────────────────────────┘      │
└─────────────────────────────────────────────────────┘
        两朵云共享同一套命名与分层规范

命名规范建议：账号名统一 {业务}-{环境}（如 ecommerce-prod），并在每朵云的管理账号里维护一份账号清单表（账号ID、负责人、预算归属、创建日期）。这套规范是后续成本分账（Chargeback）和权限审计的数据地基。

实操：搭建资源目录与组织

阿里云侧，开通资源目录并创建资源夹：

// 开通资源目录（企业实名账号，一天内生效）
aliyun resourcemanager EnableResourceDirectory --Mode Enterprise

// 查看根资源夹 ID
aliyun resourcemanager GetResourceDirectory

// 创建生产环境资源夹
aliyun resourcemanager CreateFolder --ParentFolderId r-xxxx \
  --FolderName "production"

// 把已有账号移入生产资源夹
aliyun resourcemanager MoveAccount --AccountId 1234567890 \
  --DestinationFolderId fd-prod-xxxx

AWS 侧，开通 Organizations 并创建 OU：

// 开通 Organizations（全部功能）
aws organizations create-organization --feature-set ALL

// 创建 Production OU
aws organizations create-organizational-unit \
  --parent-id r-xxxx --name Production

// 创建新账号并指定到 OU（账号需邮箱验证）
aws organizations create-account \
  --email [email protected] \
  --account-name ecommerce-prod

三、管控策略：给所有账号划权限边界

账号多了以后，最大的风险是"账号内权限开太大"——比如生产账号给管理员、未使用区域未关闭。管控策略（SCP/管控策略）解决的是权限上限问题：它在账号所有 IAM 权限之上再加一道"天花板"，账号里的管理员也没法突破。

实战场景一：禁止关闭审计日志

AWS SCP（JSON 策略，附加到根 OU）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "s3:PutBucketPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/governance": "audit"
        }
      }
    }
  ]
}

阿里云管控策略（同样附加到资源夹）：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "actiontrail:StopTrail",
        "actiontrail:DeleteTrail",
        "oss:PutBucketPolicy"
      ],
      "Resource": "*"
    }
  ]
}

实战场景二：只允许使用合规区域

很多出海企业只允许业务使用新加坡+法兰克福区域，SCP 一附上，其他区域即使开了也建不了资源：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-southeast-1", "eu-central-1"]
        }
      }
    }
  ]
}

关键提醒：SCP 是"白名单思维"还是"黑名单思维"要提前定。AWS SCP 默认 Deny 一切、需要显式 Allow；阿里云管控策略默认不拦截、只拦截显式 Deny 的 Action。两者默认语义不同，落地时别想当然——先在测试 OU 上验证再推广到生产。

四、统一身份与权限基线：先建身份，再建账号

多账号治理的前提是统一身份。让员工用一套 SSO 登录三朵云，用角色而不是长期密钥干活，账号治理才有意义（身份联邦的完整做法见本站《多云统一身份认证实战》）。落地基线两条：

1. 禁止创建长期 AccessKey：生产账号一律用角色+STS 临时凭证，SCP 直接 Deny iam:CreateAccessKey；
2. 权限最小化：每个账号只给该业务需要的服务权限，用标签做 ABAC 收敛。

// AWS: 用 IAM Identity Center 为 OU 分配权限集
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx \
  --name DevOpsReadOnly

// 附加 AWS 托管策略（只读）
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxx \
  --permission-set-arn arn:aws:sso:::permissionSet/xxxx \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

五、多云网络基线：中心辐射拓扑

账号隔离之后，网络不能各玩各的。标准做法是中心辐射（Hub-Spoke）：一个中心网络账号放转发/防火墙/专线，其他业务账号的 VPC 都挂到中心。

// 阿里云：把生产账号的 VPC 加入 CEN
aliyun cen AttachCenChildInstance \
  --CenId cen-xxxx \
  --ChildInstanceId vpc-prod-xxxx \
  --ChildInstanceType VPC \
  --ChildInstanceRegionId ap-southeast-1 \
  --ChildInstanceOwnerId 1234567890

建议：中心账号只放网络与安全组件（NAT、防火墙、VPN/专线网关），业务流量南北向统一走中心，东西向在 CEN/TGW 内按需放通。这样安全策略只需在中心管一份。

六、日志与审计集中化：一个账号收三朵云的账

合规审计最怕"日志散落在各个账号，出事时捞不出来"。基线做法：每个云单独建一个日志账号（或日志资源夹），所有账号的审计日志强制投递进去，保留期≥1年。

// AWS：创建组织级 CloudTrail，日志集中到审计账号的 S3
aws cloudtrail create-trail \
  --name org-audit-trail \
  --s3-bucket-name audit-logs-company \
  --is-organization-trail \
  --is-multi-region-trail

// 阿里云：开通操作审计并投递到中心日志账号的 OSS
aliyun actiontrail CreateTrail \
  --Name org-actiontrail \
  --OssBucketName audit-logs-company \
  --IsOrganizationTrail true \
  --TrailRegion All

日志账号的权限用 SCP 锁死：Deny 删除审计桶、Deny 修改日志保留期。这样即使某个生产账号被入侵，攻击者也抹不掉审计记录——这是海外合规审计（SOC 2、ISO 27001、GDPR）最看重的一条。

七、用 Terraform 把 Landing Zone 变成代码

手工点控制台建几十个账号不现实，Landing Zone 必须 IaC 化。Terraform 的 provider 原生支持阿里云资源目录和 AWS Organizations，双云一份代码：

// 阿里云资源夹
resource "alicloud_resource_manager_folder" "prod" {
  name             = "production"
  parent_folder_id = "r-xxxx"
}

// AWS OU
resource "aws_organizations_organizational_unit" "prod" {
  name      = "Production"
  parent_id = aws_organizations_organization.org.roots[0].id
}

// 管控策略（双云各一份）
resource "alicloud_resource_manager_control_policy" "deny_unused_regions" {
  policy_name = "DenyUnusedRegions"
  policy_document = jsonencode({
    Version   = "1"
    Statement = [{ Effect = "Deny", Action = "ecs:CreateInstance", Resource = "*" }]
  })
}

resource "aws_organizations_policy" "deny_unused_regions" {
  name    = "DenyUnusedRegions"
  type    = "SERVICE_CONTROL_POLICY"
  content = jsonencode({
    Version   = "2012-10-17"
    Statement = [{ Effect = "Deny", Action = "ec2:RunInstances", Resource = "*" }]
  })
}

账号结构、策略、日志投递全部进 Git，改结构走 PR 评审——这就是把治理从"人治"变成"代码治"。规模化之后，配合 Terragrunt/Atlantis 做多账号的 plan/apply 审批门（见本站《Terragrunt+Atlantis 企业级IaC管理平台》），几十个账号的变更也可以全部受控。

八、三厂商 Landing Zone 能力对比

选型建议：如果主力云是 AWS，优先用 Control Tower（开箱即用的托管 Landing Zone）；如果国内业务+海外业务双线，用阿里云资源目录做国内合规骨架、AWS Organizations 管海外，两者通过统一身份层（Keycloak/RAM联邦/SSO）串起来——这正是本文推荐的多云治理形态。

九、参考价格表（新加坡区域）

治理控制面本身大多免费（资源目录、Organizations、管控策略均不单独收费），成本主要来自被治理的计算资源与日志存储：

实际以官网实时报价为准；治理控制面（资源目录/Organizations）本身不额外收费，日志存储是主要增量成本。

十、90 天多云治理落地路线

总结

多云 Landing Zone 的本质，是把"开账号"从自由行为变成受管流程：三层账号树定结构，SCP/管控策略定边界，统一身份定入口，集中日志定审计，Terraform 定基线。这套框架在阿里云、AWS、腾讯云上都能落地，且互不冲突——两棵树的根通过统一身份层连接，规范与基线完全对齐。出海企业的云账号会越来越多，治理框架越早搭，后期省下的不仅是钱，还有一次次合规审计前的通宵。

🚀 企业出海需要云架构咨询？通过 7.chengzicloud.cloud 联系我们，获取专属方案。从多云账号结构设计、Landing Zone 落地、SCP/管控策略规划到日志审计集中化，我们提供一站式企业级云治理服务。

相关阅读

• 多云统一身份认证实战：Keycloak+RAM联邦+IAM Identity Center — 账号治理的前置条件，先统一身份再统一账号
• AWS 企业级多账号治理：Landing Zone 五维统一管控 — AWS 单云视角的 VPC/IAM/监控/IaC/WAF 管控，本文是其多云扩展
• Terragrunt+Atlantis 企业级IaC管理平台实战 — 账号树 IaC 化后的规模化审批与依赖管理
• 企业FinOps成本管理体系建设实战 — 账号结构建好后，用标签与财务单元做跨云分账

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