多账号架构里，Amazon Bedrock 模型访问常常卡在一个现实问题上：每个工作负载账号都要处理订阅、权限和治理。托管权益的思路是把“订阅一次、组织内分发访问”变成中心化流程，让中央账号负责模型订阅和授权，工作负载账号不再需要直接拥有 AWS Marketplace 相关权限。
为什么这件事值得改
在大型组织里，Bedrock 的使用者通常不是一个账号：研发、数据平台、产品实验、生产服务可能都在不同 AWS 账号里。传统做法容易带来几个问题：
- 每个工作负载账号都要被授予 Marketplace 相关权限，权限面变大。
- 模型订阅状态分散，安全团队很难回答“哪些账号能用哪些模型”。
- 新账号接入慢，平台团队要重复配置订阅和访问控制。
- 成本、合规和模型准入策略难以集中审计。
托管权益把模型访问拆成两个动作：中央账号负责订阅和分发权益，工作负载账号只消费被授权的模型能力。这样更贴近平台工程的治理方式：入口集中，使用分散。
推荐的账号分工
可以把组织里的角色拆成三类：
- 中央治理账号：持有模型订阅和托管权益配置，通常由平台、安全或云中心团队管理。
- 工作负载账号：运行应用、Agent、批处理或 API 服务，只需要调用 Bedrock 模型。
- 组织管理边界：通过 AWS Organizations、SCP、IAM 和审计日志约束谁能订阅、谁能使用、谁能修改权益。
这种分工的关键不是“让所有人都进中央账号操作”，而是让订阅和分发动作在中央账号完成，业务账号通过最小权限访问被批准的模型。
可以这样实践：用 IAM 把工作负载账号限制在 Bedrock 调用权限
下面的示例假设中央账号已经完成模型订阅和权益分发。工作负载账号里的应用角色只需要 Bedrock 推理权限，不需要 AWS Marketplace 订阅权限。你可以把 REGION、账号 ID 和模型 ARN 改成自己的环境。
cat > bedrock-workload-policy.json <<'JSON'
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowApprovedBedrockInference",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-haiku-20240307-v1:0"
]
},
{
"Sid": "DenyMarketplaceSubscriptionChanges",
"Effect": "Deny",
"Action": [
"aws-marketplace:Subscribe",
"aws-marketplace:Unsubscribe",
"aws-marketplace:AcceptAgreement*"
],
"Resource": "*"
}
]
}
JSON
aws iam create-policy \
--policy-name BedrockApprovedInferenceOnly \
--policy-document file://bedrock-workload-policy.json
如果你使用角色运行应用，可以把策略挂到对应角色：
aws iam attach-role-policy \
--role-name my-bedrock-app-role \
--policy-arn arn:aws:iam::123456789012:policy/BedrockApprovedInferenceOnly
这段配置表达的是一个治理原则：工作负载账号可以调用已批准模型，但不能自己新增或修改 Marketplace 订阅。
应用侧调用仍然保持简单
一旦权益和 IAM 都到位，应用代码不应该关心“订阅在哪里发生”。它只需要正常调用 Bedrock Runtime。下面是一个可改造的 Python 示例，运行前请安装依赖并确保当前凭证来自工作负载账号中的应用角色。
pip install boto3
import json
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
response = client.invoke_model(
modelId="anthropic.claude-3-haiku-20240307-v1:0",
contentType="application/json",
accept="application/json",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 200,
"messages": [
{
"role": "user",
"content": "用三句话解释什么是托管权益，以及它为什么适合多账号治理。"
}
]
})
)
payload = json.loads(response["body"].read())
print(payload["content"][0]["text"])
如果这段代码返回权限错误，排查顺序建议是：中央账号是否已完成模型订阅，权益是否分发到目标账号，工作负载角色是否允许 bedrock:InvokeModel，模型所在 Region 是否一致。
落地时别忽略边界
托管权益能减少工作负载账号里的 Marketplace 权限需求，但它不是万能的权限模型。落地时建议检查这些点：
- 模型准入清单：明确哪些模型可用于实验、预生产和生产。
- Region 策略：Bedrock 模型和组织合规要求往往和 Region 绑定。
- 最小权限：工作负载账号只保留推理所需权限，订阅和权益管理留在中央账号。
- 审计路径：记录谁批准了模型、分发给了哪些账号、哪些角色实际调用。
- 失败预案：新账号接入时准备权限验证脚本，避免应用上线时才发现模型不可用。
一个实用的采用路径是：先选 1-2 个常用模型和一个非生产 OU 试点，验证订阅、权益分发、IAM、应用调用和审计链路；再把流程固化成平台团队的标准接入清单。这样既能降低多账号摩擦，也不会把模型治理变成每个团队各自维护的小手工。