Claude Platform on AWS：每个运营商路由策略都必须纳入考量的第三条部署路径

上周 Claude Code 2.1.198 引入了 anthropicAws gateway provider，这让一个长期被当作脚注的部署选项浮出水面：Claude Platform on AWS。它并不是贴了不同标签的 Amazon Bedrock，而是架构上截然不同的路径——那些尚未将其纳入 provider 路由策略的工程团队，实际上是在用沉默代替决策。

Claude Platform on AWS 到底是什么

表面描述听起来很简单：基于 Anthropic 托管推理、通过 AWS Marketplace 计费的 Claude。但它与 Amazon Bedrock 的架构差异远比这更深。

在 Amazon Bedrock 上，AWS 运营整个推理栈。Anthropic 人员无法访问基础设施。AWS 是数据处理方、合规边界所有者与容量管理方。当你需要 FedRAMP High、IL4、IL5、符合 HIPAA 的合规性，或需要严格的 AWS 运营数据驻留时，这才是正确选择。

在 Claude Platform on AWS 上，Anthropic 运营推理栈。AWS 提供认证（SigV4 或 API key）、基于 IAM 的访问控制，以及通过 Marketplace 的计费集成。Anthropic 是数据处理方。推理数据处于 Anthropic 的运营管控之下——但采购、身份与审计界面通过 AWS 运行。

对运营商而言的实际影响：Claude Platform on AWS 提供与第一方 Claude API 相同的 API 接口，以及相同频率的新功能和 beta header 支持。

影响路由决策的 API 接口差距

这是大多数对比文章没有充分说明的部分。以下是这一差异在实践中的具体含义：

Beta header 可用。 anthropic-beta header 在 Claude Platform on AWS 上直接透传。而在 Amazon Bedrock（当前版本）上，不支持 anthropic-beta。任何使用 mcp-tunnels-2026-06-22、managed-agents-2026-04-01、fallback-credit-2026-06-01、server-side-fallback-2026-06-01 或其他近期 Anthropic beta 功能的团队，目前都无法通过 Amazon Bedrock 访问这些功能。而通过 Claude Platform on AWS 则可以访问。

Agent Skills 可用。 Claude Managed Agents 的 Agent Skills——托管技能执行环境——运行于 Claude Platform on AWS 之上。它不在 Amazon Bedrock 上运行（后者需要用代码执行作为替代路径），也不在遗留 Bedrock 集成上运行。

功能可用性延迟被消除。 Bedrock 的发布节奏跟随 Anthropic 的计划，但并非同日。Claude Platform on AWS 通常在功能发布当天与第一方 API 保持同步。

这三个差异决定了哪些团队可以在特定工作负载中使用 Claude Platform on AWS——并直接影响任何运行多 provider 配置的团队的路由策略。

对 AI 工程团队的影响

最直接的影响：如果你的团队已经在 AWS 采购上实现了标准化，并且在 Bedrock 上遇到了 beta 功能访问限制，Claude Platform on AWS 就是不需要迁离 AWS 计费或重新集成新身份系统的解决路径。

两种改变路由决策的运营商场景：

场景一：通过 AWS 使用 Claude Managed Agents 或 Anthropic beta 功能的团队。 如果你的组织已经订阅了 AWS Marketplace 的 AI 服务，并希望运行带有 per-session config override、事件增量或部署 webhook 的 Claude Managed Agents（上述功能均于 6 月 30 日发布），这些功能需要 Claude API 接口。Claude Platform on AWS 通过 AWS 计费提供该接口，无需单独签署 Anthropic 直连合同。

场景二：构建多平台故障转移策略的团队。 Claude Platform on AWS 运行于独立于第一方 Claude API 和 Amazon Bedrock 的容量池之上。Anthropic 明确支持在多个平台上运行工作负载并在它们之间进行故障转移。这意味着团队可以配置故障转移链：主节点走 Anthropic 直连 API → 溢出走 Claude Platform on AWS → 溢出走 Claude in Amazon Bedrock（适用于支持的模型）。每一段使用不同的容量池，这是关键的运营要点：一条路径上的容量事件不一定会影响其他路径。

Router/Operator 视角分析

三路径 Claude 路由需要明确策略。 当前大多数路由配置将"Anthropic"视为单一 provider。Claude Platform on AWS 引入了第三个独立的 base URL（aws-external-anthropic.{region}.api.aws）、独立的 SDK 客户端类（Python beta 中为 AnthropicAWS）以及独立的容量池。每一个都是 gateway provider 注册表中的独立上游。不进行显式配置意味着 fallback 链不完整。

各路径的关键配置决策：

数据驻留是请求级别的，而非账户级别的。 在 Claude Platform on AWS 上，推理默认可能路由到 Anthropic 的主云。inference_geo 参数允许团队将特定请求固定到指定地理位置——us、eu 或其他受支持的值。这是请求级别的信号，而非区域级别的配置。有数据驻留要求的团队需要在每个请求中设置此参数，而不能仅依赖 AWS 区域选择。

AWS PrivateLink 路径可用。 对于需要私有 VPC 连接到 Claude 而不经过公网的团队，Claude Platform on AWS 支持 AWS PrivateLink。这与 Amazon Bedrock 可用的模式相同，但针对 Anthropic 运营的 endpoint。对于必须最小化公网出口的企业部署，这一点至关重要。

TheRouter 用户应关注或尝试的内容

Claude Code 2.1.198 引入的 anthropicAws provider 使用的正是同一架构路径。将 anthropicAws 配置为 gateway failover 来测试 Claude Code 的团队，已经在使用这个容量池了。如果该配置在 Claude Code 中运行稳定，同样的底层 endpoint 也可用于更广泛的 API 工作负载。

对于评估 TheRouter provider 路由策略的团队，三路径模型将上游配置从两选项扩展为三选项。每条路径需要独立的认证配置（Bedrock 路径使用 SigV4；Claude Platform on AWS 支持 API key 或 SigV4；Anthropic 直连使用 API key），影响 gateway 层的凭证轮换与访问控制管理。

独立容量池属性是路由团队最重要的运营细节。一个池的负载延迟不一定影响其他池——跨池而非仅跨 provider 的 fallback 链，是这一架构所支持的路由策略。