Anthropic Bedrock Mantle：AWS 上的 Claude Messages API 路由

如果你正在搜索 AnthropicBedrockMantle、bedrock messages api 或 claude code bedrock mantle，核心结论很直接：Amazon Bedrock 现在可以通过 Mantle 端点接收 Claude Messages API 形态的请求，但它并不是完整的 Anthropic API 克隆。这个端点选择会直接影响路由策略。

6 月 10 日，Anthropic 发布了 Claude in Amazon Bedrock 的更新文档。核心变化是一个全新的 bedrock-mantle 端点，通过标准 Anthropic Messages API 在 /anthropic/v1/messages 上以 SSE 流式方式提供 Claude 模型推理服务 —— 请求格式和 SDK 与 Anthropic 直接 API 完全一致。该端点取代了原有 InvokeModel / Converse 路径成为官方推荐集成方式（旧路径仍可用）。

Fable 5 从首日起即在该端点上线；AWS 随后更新说明称，Anthropic 因美国出口管制合规要求，请 AWS 撤销 Fable 5 与 Mythos 5 的访问权限，Opus 4.8 等其他模型不受影响。实际效果是：在 AWS 上运行 Claude 工作负载的团队现在面临三个截然不同的端点选择，每个选择的安全边界、延迟特征和功能覆盖各不相同。

具体变化

全新 bedrock-mantle 端点的关键特性：

• API 形态：Anthropic Messages API（/anthropic/v1/messages），SSE 流式传输，不再使用 AWS 事件流编码。
• 模型 ID：带 anthropic. 前缀 —— 例如 anthropic.claude-fable-5、anthropic.claude-opus-4-8。
• 认证：三种路径 —— Bedrock Service Role（推荐）、IAM Assumed Roles、Bearer Token。均通过 AWS SigV4 签名。
• 零运营者访问权限：Anthropic 工作人员无法访问 AWS 上运行的推理基础设施。这对合规要求严格的工作负载是实质性的安全差异化。
• 上线模型：Claude Fable 5、Opus 4.8、Opus 4.7、Haiku 4.5（发布时开放访问）；Mythos Preview（邀请制，仅限 us-east-1）。AWS 后续公告更新称，Fable 5 与 Mythos 5 因 Anthropic 的出口管制合规请求而不可用，Opus 4.8 等其他模型不受影响。
• 区域：Fable 5、Opus 4.8、Opus 4.7、Haiku 4.5 支持全球端点。区域端点收取 10% 定价溢价以满足数据驻留需求。
• 默认配额：200 万输入 Token/分钟；无需 Anthropic 审批即可申请至 400 万（AWS 侧 RPM 限制另计）。
• SDK 支持：AnthropicBedrockMantle 客户端覆盖 Python、TypeScript、C#、Go、Java、PHP、Ruby。端点格式：https://bedrock-mantle.{region}.api.aws/anthropic/v1/messages。

新端点与 Anthropic 一等 API 之间的功能差距相当显著。bedrock-mantle 不支持：服务端工具（code execution、web search、web fetch）、Agent 基础设施（Agent Skills、MCP connector）、Message Batches API、Files API、URL 源输入，以及服务端 fallback —— 回退机制需要在客户端自行编排。

这一点很关键，因为它在路由策略中引入了真正的 tradeoff 矩阵，而不是简单的端点切换。

对 AI 工程团队的影响

上一次团队需要思考 Claude-on-AWS 端点架构的时候，选择很简单：用旧版 Bedrock 的 InvokeModel。那条路径功能可用但与 Anthropic SDK 不兼容 —— 需要 AWS SDK 封装、ARN 版本化模型标识和事件流编码。

现在有三条路径，决策并不简单：

上表就是核心决策框架。每条路径对应"哪种团队、在什么场景下应使用哪个端点"的不同答案。

直接 Anthropic API 是需要完整功能覆盖团队的默认选择 —— 服务端工具、Claude Managed Agents、MCP connector 或 Message Batches 批量推理。代价是独立的计费关系且无 AWS 原生认证边界。

Claude Platform on AWS 适合希望以 AWS Marketplace 计费获得 Anthropic 运行推理服务的团队，功能更新通常与一等 API 同步。这是原生 API 和 AWS 托管基础设施之间的中间地带。

Bedrock Messages API 最适合合规工作负载、深度嵌入 AWS 架构的团队，以及要求零运营者访问权限（Anthropic 工作人员不接触推理基础设施）加 IAM 治理的场景。功能差距是客观存在的，但对纯推理工作负载 —— 发 prompt、收 completions —— Messages API 形态配合 SigV4 认证是干净的组合。

Router/Operator 视角

对多 Provider 路由团队来说，这不是"选一个就行"的决策。它改变了三个运营层：

Fallback 策略。 bedrock-mantle 不支持服务端 fallback，意味着对延迟敏感或可用性要求高的流量，客户端 fallback 编排是强制要求。如果 Fable 5 请求在 Bedrock 上失败，网关必须捕获、重试并回退到另一个 Claude 端点或其他模型 —— Bedrock 不会替你做这件事。这正是一个带有每模型 fallback 链的路由层发挥价值的地方。

成本与配额路由。 Bedrock 默认 200 万 TPM 配额宽裕但有上限。高吞吐推理团队应将溢出流量路由到直接 Anthropic API，或使用 Bedrock 全球端点（自动跨区域分发负载）。区域溢价 10% 意味着成本感知的路由器应区分延迟优化的全球路由和合规要求的区域路由。

功能感知调度。 如果工作负载使用了服务端工具、MCP connector 或 Agent Skills，bedrock-mantle 无法处理。一个路由层检查请求功能并据此调度 —— 纯推理走 Bedrock，工具增强工作流走直接 API —— 可避免以不透明 400 错误形式出现的运行时失败。

认证路径选择也有治理影响。Bearer Token 是最不推荐的（短期、无长驻密钥）。IAM Assumed Roles 提供 12 小时联邦会话。Bedrock Service Role 对持久化基础设施最安全。团队应将认证策略编码进路由策略，而非留作应用层关注点。

TheRouter 用户应关注的要点

如果你正在路由 Claude 流量且当前使用单一端点，现在是评估多端点策略的时机。几个具体步骤：

1. 审计 Claude 工作负载。 将纯推理流量（prompt 进、completion 出）与工具增强流量（MCP、code execution、Agent 工作流）分开。只有前者符合 bedrock-mantle 的使用条件。

2. 检查 fallback 链。 如果你当前从 Anthropic API 回退到 Bedrock 或反之，验证回退目标是否支持工作负载使用的功能。回退到 bedrock-mantle 处理需要服务端工具的请求会产生硬错误。

3. 审视认证策略。 如果你仍在 Bedrock 上使用 Bearer Token，升级到 IAM Assumed Roles 或 Service Role。Bearer Token 路径被官方明确标注为最不推荐，会增加运营脆弱性。

4. 跟踪功能覆盖差距。 Anthropic 文档现在有清晰的 bedrock-mantle「支持/不支持」表格。持续关注 —— 随着 Anthropic 缩小差距，更多工作负载将可以走 AWS 托管路径，这会改变路由决策的计算。

5. 在成本模型中测试区域溢价。 10% 区域定价溢价是新增的。如果你做全球路由，无溢价的全球端点可能是正确默认值；仅对合规要求的流量启用区域路由。

原始文档已上线：Claude in Amazon Bedrock 及 AWS 博客公告。