Amazon Bedrock 私有定价优惠现可扩展至多个 AWS 账户

Amazon 概述了两种方法，可让 Amazon Bedrock 私有定价优惠覆盖数十乃至数百个 AWS 账户。此前，已协商的条款可能因管理员需手动激活所需许可证授权而一直未被使用。

这一变化的重点并非获得折扣，而是让已接受的协议真正投入运行。符合条件的优惠被接受后，AWS Marketplace 会创建许可证，但组织级授权起初仍处于禁用状态。只有这些授权被激活后，协商定价才会适用于相关使用量。

AWS 现提供轻量级脚本，用于经审核后的一次性激活；同时提供 AWS Cloud Development Kit 工作流，用于持续处理。后者将 Marketplace 协议事件与自动化授权创建、卖家验证、激活、重试及日志记录连接起来。

这种差异构成了核心矛盾。企业希望集中采购，但不希望每份模型协议都变成无人值守的全组织权限变更。脚本优先考虑操作人员审核，而事件驱动设计则通过明确的控制机制优先实现可重复性。

Amazon Bedrock 私有定价优惠仍需激活

接受私有优惠并不意味着多账户定价工作流已经完成。

AWS Marketplace Private Pricing Offers，通常简称 MPPO，可让买家为第三方产品协商定制商业条款。对于符合条件的 Amazon Bedrock 模型，AWS Marketplace 会通过 AWS License Manager 中的许可证来体现由此产生的访问权限。

AWS 于 2026 年 10 月 13 日发布了新的托管授权工作流。它面向那些在独立的开发、生产、业务部门或区域账户中运行 Bedrock 工作负载的组织。

组织可通过中央账户接受符合条件的优惠，随后将相关许可证分发给整个组织、选定的组织单元或指定账户。

AWS 将这一能力称为托管授权。授权代表在适用协议下使用已获许可产品的权利。授权项则将该权利从原始许可证持有者分发至其他 AWS 账户。

当 AWS Organizations 接受授权项时，流程并不会结束。启用所有组织功能后，组织级授权项会被自动接受，但在激活前仍保持禁用状态。

这一中间状态之所以重要，是因为它将管理分发与实际使用协商条款区分开来。它也会形成一种从采购角度看似已完成的故障模式。

买家可能已接受协议、收到许可证，并配置了预期的账户范围。然而，相关 Bedrock 使用量仍可能未走入协商定价路径，因为已分发的授权项从未进入活跃状态。

AWS 表示，授权项达到 ACTIVE 或 WORKFLOW_COMPLETED 后，相应费率才会生效。因此，这些状态成为运营检查点，而不只是内部许可证元数据。

随着组织不断增加账户和模型，这一问题会更难追踪。平台团队手动审核一项授权并不困难，但反复续约和新增模型协议会让这一环节更容易被遗漏。

托管授权将协议集中在一处。AWS 文档指出，原始订阅账户会为已获授权账户的使用量付费，从而实现对已获许可 Bedrock 使用情况的集中可见性。

同一文档还指出一个重要的配置差异：使用合并计费但未启用全部 AWS Organizations 功能的组织，必须在每个接收账户中手动接受授权项。

这一限制改变了预期体验。仅有集中计费，并不能提供与完整组织集成相同的自动接受行为。

无论模型在哪个受支持的 Bedrock 区域被调用，AWS 都会在 us-east-1 管理这些许可证资源。通常在其他区域运营的团队，必须将北弗吉尼亚视为该工作流的控制区域。

这正是为什么 Amazon Bedrock 私有定价优惠在采购完成后仍会带来运营问题。仍需有人将已接受的商业协议转化为处于活跃状态且范围正确的授权。

一次性脚本可清理现有积压事项

轻量级方案更重视可见的操作人员批准，而非永久自动化。

AWS 将其独立 Python 脚本定位为适合处理等待分发的已接收许可证的最短路径。它不需要部署 CDK，也不需要持久化的事件处理堆栈。

该脚本首先列出管理账户收到的许可证。其默认行为是生成试运行计划，而不会创建或激活授权项。

这一默认设置是一项有意义的安全控制。管理员可在允许脚本变更全组织访问权限前，检查发行方、许可证和拟议账户范围。

操作人员必须使用 --apply 和管理账户 ID 重新运行该工具，才能执行计划。要求确认账户可降低在错误 AWS 环境中应用已审核计划的风险。

随后，脚本会为选定的已接收许可证创建并激活面向全组织的授权项。它被设计为一次性修正工具，而非持续运行的控制平面。

该方法适合积压事项较少、私有协议不频繁的组织。当平台团队希望在部署额外基础设施前了解许可证状态时，它同样适用。

不过，该脚本没有卖家允许列表。它可以检查管理账户收到的所有许可证，因此 AWS 提醒用户仔细审核每一项。

没有允许列表意味着信任成为决定性边界。操作人员必须确认每个相关发行方和账户范围都与组织原本打算接受的私有优惠相符。

这一权衡使工具保持简洁，但也意味着该脚本不适合作为无人值守的任务，反复处理账户中出现的任何内容。

最安全的使用方式始于试运行。管理员应将列出的每个发行方与采购记录及相应 Marketplace 协议进行比对。

审核还应验证授权目标。共享至整个组织，与共享至一个组织单元或多个指定工作负载账户，在实质上截然不同。

一家医疗保健公司可能会将临床生产工作负载与研究账户隔离。一家金融机构则可能将获许可的模型限制在经批准的开发和生产单元中。

脚本默认面向全组织的行为，在具有严格隔离要求的环境中需要特别注意。即便激活在技术上成功，也可能超出预期的业务范围。

激活后，AWS 建议用户在 License Manager 中验证授权项状态。随后，他们应在 AWS Cost Explorer 中的数据可用后验证实际计费路径。

第二项检查是必要的，因为许可证激活与计费可见性遵循不同的时间线。AWS 警告称，计费信息可能会滞后数小时或数天。

因此，活跃授权项可确认许可工作流已完成，但不能立即证明之后的每笔费用都反映了预期的私有条款。

AWS 在公开示例代码中提供了折扣检查工具。团队必须根据自身协议调整其发行方和账户输入。

当手动工作已经积累时，该脚本为企业提供了实用的恢复路径。它将不确定的控制台检索转化为可重复执行的审核与激活流程。

它并未消除责任归属。平台或 FinOps 团队仍必须决定哪些许可证值得信任、应在哪些范围内适用，以及如何验证计费情况。

事件驱动自动化将协议转化为活跃授权项

CDK 路径将每份符合条件的 Marketplace 协议转化为受控的许可证工作流。

AWS 的第二种设计采用 CDK、EventBridge、Lambda、DynamoDB、License Manager 和 CloudWatch。它面向经常新增模型、续签协议或调整账户结构的组织。

工作流始于 AWS Marketplace 协议事件。EventBridge 规则会监听 us-east-1 中默认事件总线上的事件。

该规则匹配来源 aws.agreement-marketplace 和详细类型 Purchase Agreement Created - Acceptor。该事件表示接受方已创建采购协议。

匹配事件到达后，EventBridge 会调用 Lambda 函数。该函数会在继续执行前，根据 DynamoDB 中存储的允许列表检查卖家。

如果卖家已获批准，该函数会发现相关许可证，随后为配置的组织、组织单元或账户创建分发授权项。

该函数通过带有活跃状态的 CreateGrantVersion 请求激活。AWS 文档将授权版本更新定义为更改授权项名称、状态或允许操作的接口。

License Manager 并不总能让新创建的授权项立即可供激活。因此，当服务仍需时间完成其工作流时，该示例包含重试行为。

这套重试逻辑解决了事件与已完成授权之间的重要差异。Marketplace 事件会启动处理，但并不保证每个下游许可证对象都会立即可用。

该函数会在 CloudWatch Logs 中记录激活、延后和跳过决策。这些记录为故障排查和治理审核提供审计线索。

这不仅仅是大规模运行时的便利。确定性的处理程序可将相同的卖家验证和授权目标规则应用于每一份符合条件的协议。

手动激活依赖管理员找到正确的许可证、选择正确的范围，并在授权项准备就绪时再次返回。随着交易量增加，这一过程的可靠性会下降。

事件驱动设计可减少这种差异，同时使自动化的假设在代码和配置中清晰可见。

AWS 要求从 us-east-1 中的 Organizations 管理账户运行部署。组织必须启用所有功能，并且优惠必须涉及由 License Manager 支持的 Bedrock 模型。

SaaS 产品仍不在该示例的适用范围内。不应将此工作流视为适用于所有 AWS Marketplace 交付模式的通用私有优惠处理器。

部署前，团队必须为 License Manager 和 Marketplace 启用受信任访问及服务关联角色。受信任访问允许这些服务执行定义明确的组织级任务。

AWS 的设置说明为两项服务分别规定了集成步骤，也说明了如何验证生成的角色和组织链接。

该示例包含一个引导工具，可检查这些前置条件。经明确的账户确认后，其应用模式可启用集成并创建所需的服务关联角色。

配置随后定义组织 ID、获批卖家、通知以及可选的授权目标。若不设置自定义目标，自动化将把授权分发至整个组织。

团队也可以指定组织单元或单个账户。这样便能让模型访问权限与环境边界、业务归属或内部审批决策保持一致。

只有当授权达到已接受且处于活动状态，并且计费遵循预期协议时，流程才算结束。事件处理、许可、模型调用和成本验证仍是彼此独立的可观测性节点。

因此，Amazon Bedrock 私有定价报价将成为基础设施事件，而非采购工件。CDK 路径将其纳入与其他云控制措施相同的运营体系。

卖家允许列表才是真正的安全边界

只有当卖家身份和授权范围受到与模型权限同等严格的审查，自动化才是安全的。

CDK 工作流可以在无需人工在控制台审核的情况下，将许可分发至大型 AWS 组织。这种速度也提高了其筛选规则的重要性。

AWS 将卖家允许列表描述为一道安全边界。管理员在核实每个卖家账户 ID 后，会从配置文件中初始化该列表。

核实应以已接受的 Marketplace 协议或已收到的 License Manager 许可证为依据。仅凭卖家的展示名称不足以构成有效控制。

范围过宽或未经验证的条目，可能会为并非计划自动分发的许可证触发授权创建。由此生成的授权可能覆盖所有已配置的账户目标。

这并不一定意味着模型可以不受限制地访问企业数据。身份策略、服务控制、模型权限和应用架构仍决定实际使用方式。

不过，权益自动化会改变哪些账户有资格使用这些商业条款。它还可能将计费集中至拥有原始订阅的账户。

因此，卖家核实应与 IAM 审查、采购审批和成本分摊并列，而不应作为非正式的部署设置存在。

授权范围同样值得重视。面向整个组织的目标虽然简单，但可能超出获准使用某个特定模型或用例的账户集合。

选定的组织单元提供了折中方案。它们让企业能够依据既有账户层级分发权益。

指定账户能提供更精细的控制，但维护工作也更多。除非更新配置，否则新建的工作负载账户不会自动继承访问权限。

这些选项反映了集中化便利与最小权限分发之间更广泛的取舍。没有一种方式适用于所有组织。

集中式 AI 平台可能希望各应用团队都能一致地使用模型。受监管企业则可能要求针对每种环境和数据分类分别审批。

自动化还需要围绕配置变更建立治理。卖家 ID、组织 ID 和授权目标应接受代码审查和受控部署。

CloudWatch 日志能够证明该函数已处理或跳过某个事件，但无法替代说明卖家或账户范围为何获批的审批记录。

团队还需要针对失败或反复延迟的激活设置告警。平静的日志流可能让已协商协议一直处于未激活状态，而应用程序仍持续产生使用量。

AWS 指出，EventBridge 服务交付遵循事件驱动服务的行为模式，而解决方案内部的重试机制用于应对 License Manager 的就绪状态。运营团队仍应为遗漏、重复或延迟处理做好规划。

协调流程可以比较已接受的协议、已收到的许可证、已分发的授权以及活动授权状态。该比较能发现单个事件处理程序可能无法暴露的问题。

组织还应保留便于阅读的操作流程文档。可搜索的工程知识库可在事件发生期间，确保审批规则、发行方映射和恢复步骤随时可用。

即使自动化堆栈已经部署，轻量级脚本仍然有价值。它可用于检查历史许可证，或在事件未被处理时支持受控恢复。

同时使用两条路径并不意味着无需协调地同时运行它们。团队需要明确责任归属，以防止重复授权、目标冲突或激活历史不明确。

核心风险不在于 Lambda 函数本身，而在于假定已接受的协议就应自动在所有地方可用。

CDK 设计通过已验证的卖家、可配置目标、明确的前提条件、日志记录和验证来应对这一风险。这些控制措施必须在部署后持续维护。

集中采购让平台和 FinOps 团队面临压力

托管权益将瓶颈从单个账户的接受流程转移至集中式策略和成本治理。

此前逐账户处理的流程带来了明显摩擦。每位工作负载负责人都需要查找、接受并管理相关的 Marketplace 条款。

集中分发消除了大部分重复工作，同时也将责任转向组织的管理账户及其运营团队。

平台工程团队如今决定符合条件的许可证能否进入开发、测试和生产环境。采购团队负责底层协议，FinOps 则验证由此产生的费用。

安全团队必须审查自动化信任边界。在预期的定价路径可用之前，应用团队依赖所有这些团队的协作。

若责任归属不清，这种分工可能造成新的延迟。技术自动化只完成了运营模型中的一部分。

AWS 客户 Heidi Health 展示了集中式模式的重要性。该公司表示，其每周支持数百万次临床医生问诊，同时依赖第三方基础模型。

Heidi Health 平台工程负责人 Marcus Lau 表示，私有定价可帮助公司在不同账户和组织单元之间归属使用量和条款。他还强调，随着新模型被采用，应自动化授权流程。

这一表述代表客户视角，而非对节省成本的独立证明。但它确实说明了为何人工授权处理会变得不具吸引力的规模问题。

AI 团队越来越多地将工作负载划分到不同账户中，以管理安全、归属、环境和成本归因。每增加一道边界，模型访问失败的可能位置就会增加。

托管权益让商业协议保持集中，同时允许关联账户进行技术使用。AWS 的权益指南指出，接收方可通过授权继承适用的私有报价条款。

这种模式也不同于让每个账户独立订阅。原始订阅持有者仍是被授权使用量的计费中心。

这能带来更清晰的汇总可见性，但团队仍需进行内部成本分摊。账户标签、成本类别和工作负载归属对于分摊计费或展示计费仍不可或缺。

FinOps 团队应在激活前，将授权目标与预期使用中心进行比对。否则，权益可能在技术上有效，却难以与内部预算对账。

采购团队也需要续约流程。新的协议可能触发另一个需要验证的事件、许可证或授权工作流。

自动化减少了重复的控制台操作，但无法解决合同解读问题。条款、生效日期、产品覆盖范围和修订内容仍需要人工审查。

AWS Marketplace 区分报价接受、协议创建、权益激活和计费。未来生效的协议会让这些节点更加分明。

已接受的协议可能有更晚的开始日期。团队不应将购买事件视为模型可立即按新条款使用的证明。

当卖家增加模型、区域或产品变体时，同样应保持谨慎。现有私有协议未必自动覆盖后续新增内容。

集中化也会放大配置错误的影响。手动流程中错误的账户 ID 只会影响一个账户，而错误的组织目标可能影响许多账户。

这种不对称性解释了为何事件驱动解决方案包含卖家筛选和可配置目标。自动化在更大规模下运行，因此需要更强的选择控制。

因此，Amazon Bedrock 托管权益迫使企业将此前分散的流程正式化。该工作流连接了商业审批、技术权益、安全范围和计费证据。

最能从中受益的组织，将把这些连接视作一套运营系统。仅部署 CDK 堆栈并不会自动形成这种纪律。

三个信号将表明自动化是否有效

下一项考验是，企业能否在不重回人工控制台检查的情况下，对账协议事件、活动授权和适用费用。

第一个信号是授权完成时间。团队应衡量从符合条件的 Marketplace 协议事件到授权达到 ACTIVE 或 WORKFLOW_COMPLETED 状态之间的间隔。

持续较短的间隔将支持 AWS 关于事件驱动处理可消除可避免等待的说法。反复延迟或人工干预则会削弱这一论点。

该指标应纳入卖家检查失败和许可证尚不可发现的情况。排除这些情况会掩盖工作流最重要的运营缺口。

第二个信号是对账准确性。已接受的协议、已收到的许可证、预期目标和活动授权应在管理账户中保持一致。

定期控制应识别没有活动授权的协议，以及没有当前获批协议的授权。它还应标记超出获授权账户范围的目标。

强有力的对账将证明，即使经历人员变动、续约和组织重组后，自动化依然可信。持续的不匹配则会表明，仅靠事件处理并不足够。

第三个信号是计费验证。在 Cost Explorer 数据可用后，适用的 Bedrock 使用量应按照预期商业条款显示。

AWS 明确警告，这类可见性可能需要数小时或数天。因此，团队应定义合理的验证窗口，而非将即时未显示视为失败。

他们应比较某个已获授权账户中代表性适用使用量的实际费用。检查还应确认预期的发行方和原始订阅持有者。

如果计费持续遵循活动授权，该工作流将把采购意图与生产消耗连接起来。否则，企业将需要加强 Marketplace、License Manager 和成本数据之间的诊断能力。

这些信号还提供了实用的推广顺序。先以一次演练和一个已验证许可证开始，然后确认由此产生的授权状态。

接下来，为严格限定范围的卖家和账户集合启用事件驱动处理。在扩大目标范围前，对比日志、许可证状态和计费证据。

最后，记录运营人员如何处理遗漏事件、未知卖家、延迟激活和意外费用。这些情形决定了系统是否易于管理。

Amazon Bedrock 私有定价报价如今在多账户环境中拥有更清晰的路径。关键决策不只是脚本还是 CDK。

当工作范围明确、每一份收到的许可证都可信，并且操作人员能够审核每次激活时，选择脚本方案。当协议会反复出现且能够安全地将策略编码时，选择 CDK 工作流。

在自动化之前，先问一个具体问题：对于每一份协议，贵组织能否识别确切的卖方、目标账户、预期的授权状态和账单负责人？

如果答案是肯定的，事件驱动路径可以减少重复性工作。如果答案是否定的，请先从演练开始，并利用其输出建立这些控制措施。