腾讯云国际版组织架构 TCO 实战：多账号统一管控、财务托管与 SCP 权限边界完整指南（2026）

Meta Description: 腾讯云国际版 TCO 组织架构实战：TCO 零服务费，但 5 层部门、20 个子部门、可创建成员 5 个、20 条自定义登录权限等硬限额必须先算清；SCP 默认全放行且未命中即拒绝，财务托管 10 个权限 ID、SAML/SCIM 单点登录与 CloudAudit 审计一次讲透。

关键词：腾讯云国际版、组织架构、TCO、Tencent Cloud Organization、多账号管理、SCP 服务控制策略、财务托管、代付、成员账号、Identity Center、SAML SSO、SCIM、CloudAudit、Savings Plan 共享

先说结论：腾讯云国际版的组织架构服务（Tencent Cloud Organization，简称 TCO）本身 0 USD 服务费——官方 Purchase Guide 的原话是"TCO is free of charge, and you only need to pay for the Tencent Cloud resources used under your account"。这句话很容易让人误以为它是个"随手就能开"的附属功能，但它其实是一整套带硬边界的治理框架，开之前有三道墙必须知道：

第一道墙是账号关系上的单向性：一个账号只能加入一个组织，创建了组织之后，只要组织不删除，你就不能再加入别的组织；而官方限额表里，无论是直销客户还是分销子客，成员"退出组织"都写着 Not Supported。

第二道墙是数量上的硬限额：部门最多 5 层、单个节点下最多 20 个子部门、通过"新建"方式产生的成员最多 5 个（受实名认证主体数量限制）、自定义登录权限最多 20 条，每条最多挂 30 条预置策略 + 1 条自定义策略。这些数字不会因为你付钱而变大。

第三道墙，也是最反直觉的一道，是服务控制策略（SCP）的默认状态和判定逻辑：SCP 功能默认关闭；一旦开启，组织内所有部门和成员会被自动绑定系统策略 FullQcloudAccess（等于全放行）；而判定时不是"没命中就放过"，而是"既没命中允许、也没命中拒绝 = 显式拒绝"。换句话说，SCP 定义的是权限边界，不是权限本身——它从来不给任何人授权，只会砍掉一部分权限。

这篇文章按"要不要开 → 开了怎么划 → 划完怎么管钱 → 怎么管人和怎么留证"的顺序，把 TCO 的概念模型、三张限额表、直销客户与分销子客的能力差异、SCP 的判定流程与可直接抄的策略、财务托管的 10 个权限 ID、Identity Center 的 SAML/SCIM 落地路径、以及 CloudAudit 审计与 Savings Plan 白名单共享全部拆开。所有限额、参数、错误码取自腾讯云国际站官方文档（TCO 产品文档 1031，2026 年 10 月复核）。

一、多账号不是架构选择，而是一条单行道

先说清楚什么时候不该开 TCO。如果你的公司只有一个腾讯云账号、一个结算主体、不超过二十个人碰控制台，那么用 CAM 子账号 + 权限策略就够了，上组织架构纯属给自己加一层管理成本——因为 TCO 的价值全部来自"账号之间"的关系，单账号场景下它没有抓手。

反过来，只要出现下面三个信号中的任何一个，多账号就已经在事实上发生了，只是还没被治理：

信号一：账单需要按业务线/子公司拆开。 当财务开始问"这个月 A 业务花了多少、B 业务花了多少"，而你的答案是"都在一个账号里，得靠标签手工摊"，多账号就已经是必然结果。标签是事后分摊，账号是事前隔离，两者的可靠度不在一个量级——标签可以被漏打、被打错、被后来的人改掉，账号不会。

信号二：权限开始互相打架。 研发要能删测试环境的数据库、但不能碰生产；外包要能看日志、但不能动网络；财务要能看账单、但不能看任何业务数据。单账号里这些诉求最后都会退化成一堆互相覆盖的 CAM 策略和"大家都用管理员"的妥协。而跨账号的权限天然是隔离的：账号 A 的管理员天生碰不到账号 B 的资源，你要给的只是"从一个账号跳到另一个账号"的那把钥匙。

信号三：出现了合规/审计上的"边界"要求。 等保、ISO 27001、客户的安全问卷里都会问同一类问题：生产环境和管理后台是不是隔离的？谁能一次性访问全部资源？操作日志保留多久、存在哪？单账号对这些问题的回答永远是"通过策略实现"，而策略是可以被有权限的人改掉的——边界必须是结构性的，这就是多账号存在的理由。

一旦接受多账号，紧接着就是三个绕不开的管理问题：谁付钱（财务）、谁能进哪个账号（身份）、出了事查什么（审计）。TCO 恰好就是这三件事的集中管理层，而不是"多账号"本身——账号是你自己拆的，TCO 只是让拆完之后不至于失控。

把单账号和多账号的取舍压成一张表：

这张表最后一行是关键：TCO 的经济性随账号数增长而改善，随账号数过少而变差。3 个账号以下硬上 TCO，你付出的复杂度换不回任何收益；10 个账号以上不用 TCO，你付出的是每次审计都要重新解释一遍"为什么大家都在一个账号里"。

二、四个概念，把组织结构说清楚

TCO 的模型只有四个名词，但每个都带数量约束，理解成本主要花在"约束"上而不是"概念"上。

四个概念里最容易踩坑的是 Department 的层级含义。官方写的是"An organization can contain up to five levels of department relationships"，而控制台里 root 本身不算一层——也就是说你的树形结构是 root → L1 → L2 → L3 → L4 → L5，最底下那层还能挂账号。实践中的建议是不要用满 5 层：三层（业务集团 → 子公司/业务线 → 环境）已经能覆盖 99% 的治理需求，用满的结果是每加一个部门都要想"它该挂第几层"，而 SCP 是逐层继承的，层数越深，排查一条权限为什么被拒时你要翻的层级越多。

另一个容易被忽略的事实：成员账号有两种产生方式，代价完全不同。一种是"邀请已有账号加入"（InviteOrganizationMember），账号的历史资源、账单、实名主体都保留；另一种是"在组织内直接创建"（CreateOrganizationMember），新账号默认继承管理账号的实名认证主体，官方限额表把"可创建的成员数量"直接写成 5（括号里注明是"the number of identity verification accounts"，即受实名主体数量约束）。这句话的实际含义是：别指望靠"在组织里批量新建账号"来搭几十个环境，那是邀请模式该干的事，而邀请模式要求对方账号的实名主体与管理账号一致或者是已关联的互信主体。

三、先把钱的事说清楚：TCO 免费，但"免费"有三个前提

官方 Purchase Guide 只有一句话："TCO is free of charge, and you only need to pay for the Tencent Cloud resources used under your account. For example, you need to pay standard fees for any CVM instances you use."

这句话是真的，但"免费"在两个地方会让你产生错觉，必须提前拆开：

错觉一：以为开了 TCO 账单会合并成一张、金额会变少。 不会。TCO 不改变任何资源的计价方式，它改变的是账单的归属和可见性：管理账号能看到成员的账单、能代成员付款、能合并下载账单，但每个成员的资源还是按原价计费。合并的是"付款动作"，不是"价格"。想真的降成本，动作在别处——Savings Plan、预留、竞价实例、带宽包，这些跟 TCO 是两件事。

错觉二：以为"免费"就等于"没有新增计费项"。 TCO 自身不收费，但它打开的几扇门后面全都通向计费产品：

所以真实的成本结构是：TCO 的服务费 = 0，但你为了"治理"而额外打开的三个东西（日志投递、SP 承诺、成员账号的固定件）才是有账单的部分。这三项正好对应本文的第十、八、六节，下面逐个拆。

顺带回答一个高频问题：成员账号是不是要单独买"账号"？ 不要。腾讯云账号本身不收费，成员账号里跑的资源才收费。真正的隐性成本是"每个账号都得配一套最小可用的固定件"——VPC、安全组、日志、告警、密钥管理，这套东西不会因为账号只跑一个小服务就变小。这也是为什么多账号策略里最常见的浪费不是"买贵了"，而是"每个账号都买了一整套其实用不满的基础设施"。

四、三张限额表：这些数字决定了你的组织能长多大

TCO 的官方限额散在两个地方：Organization Settings 文档（场景与限制）和部门/成员 API 的错误码里。把它们并成一张表，比事后撞墙便宜得多。

4.1 结构与成员限额

4.2 成员登录授权限额

成员登录（让管理账号的子账号"跳进"成员账号去操作）是 TCO 里最实用的功能之一，但它的限额比很多人想的紧：

最后两条值得展开。"只能挂 1 条自定义策略" 意味着你没法把"只读 + 特定服务只写 + 打标签限制"拆成三条自定义策略挂在同一条登录权限上，只能先在 CAM 里把它们合成一条，再挂进来。而 15 分钟等待 是个纯粹的时间成本：自动化脚本创建完成员立刻去验证登录，会得到"账号密码都对但进不去"的假故障，官方明确要求等 15 分钟。

4.3 API 频控

组织类 API 的频控几乎全是 20 次/秒，只有两个例外：DescribeOrganization 是 40 次/秒，以及两个异步任务查询接口 GetTaskStatus / GetProvisioningTaskStatus 是 220 次/秒（明显是为轮询设计的）。批量操作（比如给 200 个成员逐个建登录授权）时，20 QPS 意味着至少要打 10 秒，脚本里必须带退避重试，别用 for 循环裸打。

五、直销客户 vs 分销子客：同一套控制台，两套能力

这是全文最容易被忽略、但影响最大的一张表。TCO 的控制台长得一模一样，可同一操作在"直销客户"和"分销商子客户"两种身份下的可用性和后果完全不同——官方 Organization Settings 文档把它们并排写在一起，很多人只看了自己那一列，然后在另一个账号上复现失败。

这张表里藏着三个非常具体的坑：

坑一：分销子客拿不到"继承折扣"和"合并账单"。 很多分销渠道的客户以为"加入组织就能拿到上级的折扣"，实际上官方写得很清楚，这两项在分销子客列是 Not Supported。如果你的成本模型建立在"加入组织后单价会降"这个假设上，这个假设在分销场景直接不成立。

坑二：直销客户的成员不能自付。 直销场景下成员账号的消费统一由管理账号支付，self-pay 是 Not Supported。想把某个子公司的账单彻底切出去，只能让它不加入组织，或者走财务上的内部结算——不是控制台上点一下就能解决的事。

坑三：新建成员的付款模式是锁死的起点。 分销子客"新建的成员必须先选代付，等账号绑卡开通后才能切自付"。这意味着一个新成员从诞生到能自付，中间有一段必须由管理员垫付的窗口，自动化流程里要把这个状态机写进去，否则会在"以为已经自付"的时候发现账单还在管理员头上。

六、从零到第一个组织：前置条件、控制台路径与 API

6.1 三个前置条件，缺一不可

官方 Creating an Organization 文档把门槛写得很直接，但它写在"Note"里，很容易被跳过：

1. 必须完成企业实名认证（enterprise identity verification）。个人实名认证的账号不能创建组织，只能先升级。
2. 当前账号未加入、也未创建过其他组织。创建成功后，只要组织不删除，这个账号就不能再加入别的组织。
3. 组织内账号类型必须一致。官方明确"Only direct customers and distributor sub-customers of Tencent Cloud are allowed to use the group account, and the account types within the group organization must be consistent"——直销和分销子客不能混在同一个组织里。

第三条在集团场景下经常翻车：总部是直销客户，某个收购来的子公司是通过分销商买的，这两类账号想放进一个组织，做不到。

6.2 控制台路径

创建组织只有一条路：控制台 → TCO → 左侧 Basic information（console.tencentcloud.com/organization/setting）→ 点 Create。创建完成后，日常操作分布在四个页面，记住这四个 URL 能省掉大量"功能在哪"的找路时间：

6.3 用 API 建部门、拉成员

组织类 API 的域名是 organization.intl.tencentcloudapi.com，版本固定 2021-03-31，Region 参数可选（这类全局接口不需要地域）。用 CLI 探一下当前账号的组织状态，是最快的自检方式：

tccli organization DescribeOrganization \
  --endpoint organization.intl.tencentcloudapi.com \
  --version 2021-03-31

返回里重点看五个字段：

拿到 RootNodeId 之后建部门。AddOrganizationNode 的两个必填参数是 ParentNodeId 和 Name，Name 支持 40 个字符以内的字母、数字和 +@&._[]-，另外还能挂最多 10 个标签——标签在这里不是装饰，后面第十节讲的 ListNonCompliantResource 就是按成员标签做合规检测的：

POST / HTTP/1.1
Host: organization.intl.tencentcloudapi.com
Content-Type: application/json
X-TC-Action: AddOrganizationNode
X-TC-Version: 2021-03-31

{
    "Name": "prod-ap-singapore",
    "ParentNodeId": 101,
    "Remark": "生产环境-新加坡",
    "Tags": [{"Key": "env", "Value": "prod"}]
}

返回只有一个 NodeId 和 RequestId。Python SDK 的路径与官方 SDK 仓库一致（tencentcloud/organization/v20210331），封装成批量建树的脚本大致是这样：

from tencentcloud.common import credential
from tencentcloud.common.profile.client_profile import ClientProfile
from tencentcloud.common.profile.http_profile import HttpProfile
from tencentcloud.organization.v20210331 import organization_client, models
import time

cred = credential.Credential(SECRET_ID, SECRET_KEY)
hp = HttpProfile(endpoint="organization.intl.tencentcloudapi.com")
cp = ClientProfile(httpProfile=hp)
client = organization_client.OrganizationClient(cred, "", cp)  # 全局接口，region 传空串

def add_node(parent_id, name, tags=None):
    req = models.AddOrganizationNodeRequest()
    req.ParentNodeId = parent_id
    req.Name = name
    if tags:
        req.Tags = [models.Tag(Key=k, Value=v) for k, v in tags.items()]
    resp = client.AddOrganizationNode(req)
    time.sleep(0.06)          # 20 QPS 上限，留余量
    return resp.NodeId

6.4 邀请成员：10 个权限 ID 与六个真实报错

InviteOrganizationMember 是整篇文章里参数最重的一个接口，因为它一次就把"钱怎么算、人能干什么"全定下来了。必填五项：MemberUin（被邀请账号 UIN）、Name（≤25 字符）、PolicyType（目前只支持 Financial）、PermissionIds.N（财务权限列表）、NodeId（挂到哪个部门）。

PermissionIds 的 10 个取值是官方枚举，值得完整记住，因为控制台上的勾选项就是它们的可视化：

一个最小可用的邀请请求长这样（代付 + 看账 + 看余额）：

{
    "MemberUin": 111111111111,
    "Name": "subsidiary-sg",
    "PolicyType": "Financial",
    "PermissionIds": [1, 2, 7],
    "NodeId": 1001,
    "PayUin": "100000000001",
    "IsAllowQuit": "Denied",
    "Remark": "新加坡子公司-代付"
}

邀请失败是常态，官方错误码表里有一批错误看起来像"系统问题"，实际上全是前置条件没满足。把最常见的六个列出来，对照排查比读文档快：

最后一行值得单独强调：经销商（reseller）账号之间的代付是被明确拒绝的，报错文案是 "Payment-on-behalf is not supported for this member or payer as it is a reseller."。如果你是通过分销渠道买的账号，又想让上级账号代付下级，这条路走不通。

七、SCP：默认全放行，未命中即拒绝

服务控制策略（Service Control Policy，SCP）是 TCO 里技术含量最高、也最容易配错的一环。它的官方定义只有一句话，但这句话里每个分句都在反直觉：

A service control policy in TCO is an access control policy based on a hierarchical structure (department and member). It can uniformly manage the access permission boundaries of resources at each level within an organization... It only defines the permission boundaries and does not actually grant permissions. You still need to set permissions in CAM for a member account to access certain resources.

拆成三句人话：SCP 只砍权限，不给权限；它是按部门/成员层级生效的；它和 CAM 是两次独立的判定，先 SCP 后 CAM。

7.1 默认状态：关着；一开就是全放行

SCP 功能默认关闭，要手动开启。开启这个动作会带来四个连带变化，官方写在 "Background" 里：

FullQcloudAccess 的含义是"允许对所有腾讯云资源执行任何操作"。所以开启 SCP 功能的瞬间，你并没有变安全，只是从"没有边界"变成了"边界画在最外面"——真正的收紧要等你创建自定义策略并绑上去。很多人开了开关就以为管控生效了，这是第一个大坑。

系统策略只能看、不能改、不能删；自定义策略可以增删改，但必须绑定到部门或成员才生效，不绑定等于没建。

7.2 判定顺序：从被访问账号往上爬，任一层不通过就结束

这是全文最需要背下来的一段逻辑。官方把判定过程写成五条，翻译成流程是：

1. 请求进来，先看被访问资源所在的那个账号绑了哪些 SCP；
2. 从该账号开始，逐层向上（部门 → 上级部门 → … → root）检查每一层绑定的策略；
3. 某一层明确 Deny → 结果 Explicit Deny，立刻终止，根本不看 CAM；
4. 某一层既没有 Allow 也没有 Deny（未命中） → 结果同样是 Explicit Deny，立刻终止，不看 CAM；
5. 每一层都命中 Allow，一路到 root 都通过 → SCP 这关过了，然后才去查账号内的 CAM 权限。

第 4 条是所有人第一次读都会读错的地方："未命中"不等于"不限制"，等于"拒绝"。这意味着 SCP 的正确写法不是"列出禁止的"，而是"允许的必须显式列出，其余一律拒绝"。如果你只写一条 Deny 某动作的策略绑上去，其他所有动作都会因为"未命中"而全部被拒——线上会瞬间全挂。

还有两个例外必须记住：

• SCP 对服务关联角色（service-linked roles）不生效。也就是说云产品自己用的角色不会被 SCP 拦住，这既是安全上的盲区，也是"为什么某个自动化还在跑"的答案。
• 绑定在上级节点的策略会被下级继承。父部门绑 A、子部门绑 B，则子部门的成员同时受 A 和 B 约束——两个策略是交集关系，任何一边拒绝就拒绝。

7.3 一份能直接用的自定义 SCP

策略语法与 CAM 一致（effect / action / resource / condition），资源用六段式 ARN 描述。下面这份是"禁止高危动作 + 限制来源 IP"的组合，思路是用 Deny 做减法、用 * 兜底 Allow，这样不会因为漏列动作而全挂：

{
  "version": "2.0",
  "statement": [
    {
      "effect": "deny",
      "action": [
        "name/cam:DeleteUser",
        "name/cam:DeletePolicy",
        "name/organization:DeleteOrganization",
        "name/organization:DeleteOrganizationMembers",
        "name/cls:DeleteLogset",
        "name/cos:DeleteBucket"
      ],
      "resource": ["*"]
    },
    {
      "effect": "deny",
      "action": ["name/cvm:*", "name/vpc:*"],
      "resource": ["*"],
      "condition": {
        "ip_not_equal": {
          "qcs:ip": ["203.0.113.0/24", "198.51.100.10"]
        }
      }
    },
    {
      "effect": "allow",
      "action": ["*"],
      "resource": ["*"]
    }
  ]
}

三条语句的分工要说清楚，否则容易写成"以为限制了其实没限制"：

• 第一条：硬删动作一律拒绝，不设条件。删用户、删策略、删组织、删成员、删日志集、删存储桶——这六个动作在多账号体系里一旦误操作，恢复成本极高。
• 第二条：CVM/VPC 的全部动作只在指定 IP 段内允许，其他来源一律拒绝。这是"控制台只能从办公网/跳板机操作"的技术实现，比"约定大家不要在咖啡厅改网络"可靠得多。
• 第三条：Allow * 兜底。因为"未命中即拒绝"，必须有这条兜底 allow，否则第一条和第二条之外的所有动作都会被拒。

⚠️ 顺序在这里不影响结果（云厂商策略引擎是 Deny 优先，不是第一条命中即返回），所以不要指望"把 allow 写在前面"能覆盖 deny。

7.4 上线四步，一步都不能省

SCP 配错的下场是全员失去权限，包括你自己（如果管理员账号也在被绑的节点下）。官方在判定说明里放了一句加粗的提醒："Perform a local test first to ensure that the policy works as expected before binding it to all target nodes." 落地成流程：

1. 建策略但不绑。用 JSON 模式或可视化模式（可视化支持 effect / service / action / resource / condition 五段，且带语法校验）创建，先放着。
2. 绑一个边缘部门（比如测试环境部门，或者一个专为此建的"沙箱成员"）。观察 24 小时，确认没有误拦。
3. 用 DescribeEffectivePolicy 复核生效结果。这个接口就是为排查"为什么这条权限被拒"准备的：传入目标节点，返回最终生效的策略组合。配合 ListPoliciesForTarget（某目标绑了哪些策略）和 ListTargetsForPolicy（某策略绑到了哪些目标），能定位到具体是哪一层的哪条策略在拦。
4. 确认无误后再扩面，逐层向上绑。绑到 root 之前，务必确认兜底 allow 存在。

另外还有一个只在文档角落出现的坑：通过"成员登录授权"创建的组织管理策略，不能在 CAM 控制台里修改或删除，必须回到 organization/member-auth/manage 页面操作。在 CAM 里找不到、改不动、删不掉，不是权限问题，是产品设计。

7.5 SCP 与 CAM 的分工，一张表说清

一句话记住：SCP 是"公司层面的红线"，CAM 是"岗位说明书"。红线不需要解释理由，说明书需要。

八、财务托管：代付、账单、折扣的边界在哪

财务托管是 TCO 最"看得见"的价值，也是误解最多的地方。它的核心不是"把钱合到一起"，而是把 N 个账号的财务视图合成一个，同时保留每个账号独立的消费归属。

8.1 两种付款模式，起点是锁死的

这里有个很实际的推论：直销客户的多账号体系，本质上是一个"财务集中"的体系——所有成员的钱都从管理账号出，成员账号看不到自己的余额（官方明确 Viewing balance 在直销列是 Not Supported）。如果你的组织里有一半是"要自己付钱、自己开票"的子公司，直销模式下做不到，只能让它们不进组织。

8.2 集团财务总览：好用，但有五个盲区

"Group Financial Overview"（集团财务总览）是管理账号看全局消费的入口，官方文档里把限制写在最前面，五条全是硬约束：

页面本身的用法不复杂：选时间 → 选成员 → 选产品，得到成本趋势图与账单明细；明细可以按 By member（看 Top 5 成员的消费占比）或 By product（看 Top 5 产品的消费占比）两个视角切换，点每一行的"操作"还能下钻到该成员的产品分布或该产品的成员分布。这两个视角恰好对应两种开会场景：月度经营会看 By member（谁花超了），采购谈判看 By product（哪个产品是大头）。

要完整账单明细，官方建议的路径是回 Billing Center（console.tencentcloud.com/expense/bill/view），因为总览页只给"趋势 + 明细摘要"。

8.3 一套能落地的月度对账 SOP

把上面的限制变成流程，顺序很重要——错一步就要等下个月：

1. 每月 2–3 日看集团财务总览（1 号数据还没同步完），锁定异常成员（Top 5 之外突然冒头的）。
2. 月中并入的成员单独记一笔，因为它的当月数据不可见，只能去它的 Billing Center 单独拉。
3. 对账差异先查付款模式：代付成员的账单在管理账号，自付成员（分销场景）在自己账号，混着算必然对不上。
4. 折扣继承单独核对：直销客户支持成员继承管理员折扣，分销子客不支持——同一个集团里两种身份混用时，单价会不一致。
5. 发票按主体开：代成员开票在分销子客列不支持，直销客户支持，财务要按这个能力边界安排开票主体。

九、Identity Center：一次 SSO，管住所有账号

到了"人"这一层，问题会从"账号怎么拆"变成"N 个账号 × M 个人 = N×M 份用户配置"。CAM 解决不了这个，因为 CAM 的作用域就是单个账号——官方在 Identity Management 文档里把话说得很直白：CAM 的用户管理、SSO、权限配置"only effective within one Tencent Cloud account"，多账号场景下你得在每个账号里各配一遍。

Identity Center（文档里也叫 CIC / 身份管理）就是为这件事存在的。

9.1 它到底做了什么

四件事，官方列得很清楚：

9.2 与 CAM 的关系：不是替代，是"二次 SSO"

官方对架构的描述值得逐字读："access to accounts by Identity Management users is essentially a secondary SSO process, where the Identity Management user assumes a CAM role within each account."

也就是说链路是：员工 →（SAML）→ Identity Center →（扮演 CAM 角色）→ 目标账号。Identity Center 有自己的用户体系（独立于 CAM），但权限策略复用 CAM 的策略。落到每个账号里，用户最终是以 CAM 角色或 CAM 用户的身份拿到权限——这两种同步方式可以只选一种，也可以同时开（官方：同时配置时两条路径都可用）。

什么时候还得保留 CAM？官方给了三个场景：已有 CAM 用户/角色、需要用访问密钥做程序化访问、以及单个账号内的精细权限。"程序化访问"这条最关键：Identity Center 面向的是人，API 调用的 AccessKey 仍然属于 CAM 体系。所以正确的心智模型是"人走 Identity Center，机器走 CAM"，而不是"上了 Identity Center 就可以关掉 CAM"。

9.3 落地顺序：先开空间，再接 IdP，最后下发权限

官方 API 把这件事拆得很清楚，按这个顺序做不会乱：

tccli organization OpenIdentityCenter --ZoneName "acme-corp" \
  --endpoint organization.intl.tencentcloudapi.com

tccli organization DescribeIdentityCenter --endpoint organization.intl.tencentcloudapi.com

tccli organization SetExternalSAMLIdentityProvider ...
tccli organization AddExternalSAMLIdPCertificate ...

tccli organization CreateSCIMCredential ...
tccli organization UpdateSCIMSynchronizationStatus ...
tccli organization GetSCIMSynchronizationStatus ...

tccli organization CreateRoleConfiguration ...
tccli organization ProvisionRoleConfiguration ...
tccli organization ListRoleConfigurationProvisionings ...

tccli organization CreateRoleAssignment ...
tccli organization GetTaskStatus ...

对上六步的说明：

1. 开通空间。ZoneName 全局唯一，2–64 位小写字母/数字/连字符，不能以连字符开头或结尾，也不能出现连续两个连字符。返回 ZoneId，形如 z-xxxxxxxxxxxx（z- 前缀 + 12 位随机小写字母/数字）。
2. 查服务信息，确认已开通并拿 SP 元数据。
3. 配 SAML 身份提供方，把企业 IdP 的元数据与签名证书传上来。
4. 打开 SCIM 同步，创建 SCIM 凭据给企业 IdP 用。
5. 建权限配置（RoleConfiguration）并部署（Provision）到成员账号。
6. 给用户/用户组授权（RoleAssignment）到目标账号。

这套流程里有三个容易卡住的点：

• SCIM 同步开了不等于同步成功。GetSCIMSynchronizationStatus 必须查一次，否则会出现"IdP 里有 50 个人、腾讯云里只有 3 个"的静默失败。
• 权限配置要先部署（Provision）再授权（RoleAssignment）。没部署就授权，等于给一个不存在的角色授权。
• 异步任务要轮询确认。ProvisionRoleConfiguration 是异步的，ListTasks / GetTaskStatus 是配套的查询接口（频控 220 QPS，明显是为轮询优化的）。

9.4 成员登录：给运维和外包的那把钥匙

如果不想上 Identity Center，TCO 还有一个更轻的方案：成员登录——管理账号的子账号，被授权后可以直接"跳进"成员账号操作，不用知道对方的密码。

它的操作路径是：organization/member-auth/add → Add sub-user authorization → 选成员 + 选登录权限 → 命名策略（全局唯一）→ 选要授权的子用户或用户组。三个约束值得记住：

第三条尤其危险：你以为只是把某个子账号从成员 A 上摘下来，实际上所有绑定这条策略的成员都被摘了。生产环境里改这个之前，先用 DescribeOrganizationMemberPolicies 看清楚这条策略覆盖了哪些成员。

十、审计与资源共享：TCO 里最容易漏掉的两个"边界"

10.1 审计：一个跟踪集，收走所有成员的日志

多账号体系里，"谁能看到日志"本身就是一个治理问题——如果每个成员账号各管各的 CloudAudit，那管理账号在出事后要看 N 个地方，而且成员的管理员可以自己关掉日志。

TCO 的解法是：管理账号在 CloudAudit 里创建跟踪集（tracking set），把所有成员的操作日志统一投递到指定的 COS 或 CLS。官方描述是"ship all member logs to COS or CLS for easy member operation audit"。

落地时要注意三点：

1. 投递目标要单独规划生命周期。日志是持续增长的，投到 COS 就该配生命周期规则（转低频/转归档/过期删除），投到 CLS 就该配存储周期。否则审计做完了，存储费成了新问题——这和 CLS 长期归档是同一类成本陷阱。
2. 日志范围要覆盖"管理动作"而不只是"资源动作"。SCP 的绑定/解绑、成员权限的变更、登录授权的增删，这些动作本身就是最该被审计的对象。
3. 保留期按合规倒推。等保要求日志留存不少于 6 个月，金融类客户常见 1 年。定保留期的时候把"存储成本"和"合规底线"一起算，别先建后改——历史日志不会因为你缩短保留期而立刻消失。

10.2 资源共享：目前只有 Savings Plan，而且要走白名单

这一节的结论很短但很重要：TCO 的"成员资源共享"目前只支持 Savings Plan（SP），且需要联系官方开白名单。官方原文："Currently, only the Savings Plan (SP) supports resource sharing through an allowlist. If you need to use this feature, please contact us."

为什么这件事重要？因为 Savings Plan 是承诺制折扣——你承诺一定的每小时花费，换取更低的单价。如果一个集团有 10 个账号，每个账号各自买 SP，就会出现"每个账号都按自己的用量曲线承诺、每个都留余量、每个都有浪费"的局面。而通过 TCO 共享，一份 SP 承诺可以覆盖多个成员账号的用量，这是多账号体系下唯一能真正摊薄承诺浪费的机制。

但它的限制同样硬，四条全在文档里：

共享单元的操作对象是一组 API：AddShareUnit / AddShareUnitMembers / AddShareUnitResources / DescribeShareUnitResources / AcceptJoinShareUnitInvitation（成员侧接受邀请）/ DescribeResourceToShareMember（成员侧查"共享给我的资源"）。注意最后两个是成员侧的接口——共享不是管理员单方面推过去的，成员要接受邀请。

不能共享的清单同样重要，因为很多人的假设是反的：

这张表的实际价值在于预算：如果你的多账号方案假设"带宽包可以共享"，那这个方案的带宽成本要乘上账号数重算一遍。

十一、成本结构：为什么开了 TCO 之后账单没有变

这是客户最常问、也最容易产生误解的问题。答案很简单：TCO 不改变任何单价，它改变的是"谁能看到、谁来付、谁不能做什么"。开完 TCO 账单没降，是正常的。

真正会动账单的动作只有三类，而且都不在 TCO 里：

反过来说，TCO 能帮你看见的浪费有三类，这才是它的成本价值：

1. 成员级消费异常：集团财务总览按成员看 Top 5，能立刻发现"某个测试账号的消费比生产还高"这种经典问题。
2. 产品级集中度：按产品看 Top 5，能发现"某个产品的费用在 10 个账号里各买了一份，其实只需要一份"。
3. 权限导致的浪费：SCP 可以禁止成员购买某类资源（官方举的例子就是"禁止成员申请域名或删除日志"），这是事前的成本控制，比事后账单分析有效得多。

把这三件事和账号数放在一起，就得到一个粗略的判断标准：

十二、上线顺序与九个坑

12.1 推荐的落地顺序

顺序错了会返工，尤其是 SCP 和财务权限——它们都是"先配后改成本高"的东西：

1. 先定账号模型（拆几个、按什么维度拆、谁是管理账号），再动控制台。
2. 建组织（企业实名前提下），只建 root 下的一层部门骨架，别急着铺满。
3. 邀请/新建成员，财务权限只给 1, 2（看账 + 看余额），代付先不打开。
4. 配成员登录授权，让运维能进去干活，但仍不给财务权限。
5. 确认账单能正常出（这一步别跳，很多组织是在这里发现付款模式选错的）。
6. 再开财务托管（代付、合并账单、折扣继承），一项一项开，每开一项对一次账。
7. 最后开 SCP，先绑沙箱部门跑 24 小时，用 DescribeEffectivePolicy 复核后再扩。
8. 接 Identity Center（如果人数超过 20 或账号超过 5 个，这一步的收益就很明显了）。
9. 配 CloudAudit 跟踪集，把日志投出去，配好生命周期。

12.2 九个坑

坑 1：以为 SCP 开了就安全了。 开启只是绑上了 FullQcloudAccess，等于把边界画在无限远处。真正的收紧要等自定义策略绑上去。

坑 2：写了只含 Deny 的 SCP。 因为没有兜底 allow，其他所有动作都因"未命中"被拒，线上立刻全挂。每条 SCP 都必须有兜底 allow。

坑 3：指望 SCP 管住服务关联角色。 官方明确 SCP 对服务关联角色不生效，这条自动化通道永远绕开你的红线。

坑 4：把组织管理策略拿到 CAM 里改。 改不了、删不掉，必须在 organization/member-auth/manage 页面操作。

坑 5：新建成员立刻验证登录。 要等 15 分钟，否则会误判成权限配错。

坑 6：以为"加入组织就能继承折扣"。 分销子客列明确 Not Supported。折扣、合并账单、代开票这三项在分销场景全部不可用。

坑 7：用"新建成员"的方式搭几十个环境。 可创建成员数受实名主体数量限制（官方限额 5）。要批量就用邀请模式。

坑 8：月中并入的成员当月账单是隐形的。 集团财务总览对"当月 1 日后加入"的成员不显示当月数据（管理员账号除外），月中并购一定要单独对账。

坑 9：以为成员可以随时退出组织。 官方限额表里两种客户类型都是 Not Supported。虽然 API 侧保留了 QuitOrganization 和 IsAllowQuit（Allow/Denied）参数，但不要把"能退出"写进你的架构假设——加入组织是一个需要提前想清楚的决定。

结语：TCO 该怎么落地

把全文压成一套可执行的动作：

1. 先证明你需要多账号。账单要按主体拆、权限要结构性隔离、合规要边界——满足任意一条再上，否则停留在 CAM。
2. 把三张限额表抄进方案文档。5 层部门、20 个子部门、5 个可创建成员、20 条登录权限、每账号只能进一个组织、成员不能退出——这些是设计约束，不是"到时候再说"。
3. 确认自己是直销还是分销，然后按第五节的表重新核一遍财务能力。折扣继承、合并账单、代开票这三项在分销列是空的。
4. 成员先只给 PermissionIds 1, 2，代付最后再开。付款模式一旦选错，改起来要动账单归属。
5. SCP 最后开，且必须带兜底 allow。先绑沙箱、用 DescribeEffectivePolicy 复核、再扩面。记住"未命中即拒绝"，这一条能让一半的事故不发生。
6. 人数超过 20 或账号超过 5 个，就上 Identity Center。人走 SSO，机器走 CAM，别指望一套身份管两种主体。
7. 上线当天就配 CloudAudit 跟踪集。审计这件事，事后补永远补不齐——日志不在你手里的那段时间，等于没有发生过。

组织架构这类产品的价值，从来不是"多了一个控制台"，而是把"谁有权限、谁在花钱、出事了查谁"这三件事从"靠人守规矩"变成"靠结构保证"。TCO 免费，但它要求的是一次真正想清楚的账号设计——限额表里的每一个数字，都是在提醒你这件事没有回头路。

---

相关阅读（同站深度文章）：

• 腾讯云国际版控制台导览：从注册到第一个资源的最短路径
• 腾讯云国际版账号安全实战：MFA 两步验证、子账号与访问密钥管理
• 腾讯云国际版成本优化与架构选型：把账单砍下来的一整套动作
• 腾讯云国际版 KMS 密钥管理：信封加密、密钥轮换与权限隔离
• 腾讯云国际版云防火墙 CFW：三个边界、五个形态与免费流量体检
• 腾讯云国际版 VPC 对等连接与云联网：跨 VPC 互通完整指南
• 腾讯云国际版 NAT 网关与 EIP：私网出网架构与计费
• 腾讯云国际版日志服务 CLS：采集、检索与长期归档

免责声明：本文的产品能力、限额、API 参数与错误码取自腾讯云国际站官方文档（Tencent Cloud Organization 产品文档，产品 ID 1031，含 Purchase Guide / Concepts / Console Overview / Organization Settings / Service Control Policy / Member Finance / Resource Management / Identity Management 等章节，2026 年 10 月复核）。官方限额与功能可用性可能随版本调整，最终以控制台实际表现与官方文档最新版本为准；涉及商务开通项（SP 共享白名单、内部资金划拨、信控设置）请以客户经理确认为准。

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