Eon 如何在 Amazon Bedrock AgentCore 上用 MCP Gateway 构建多云调查能力

本文是与 Eon 的 Roei Zavida 共同撰写的客座文章。

构建 AI 驱动产品的独立软件供应商（ISV）需要将智能体和人员连接到跨云端的数十种运维工具，而每种工具都有不同的身份验证模型、网络边界和访问策略。当这些工具同时横跨 AWS、GCP 和 Azure 时，集成面会成倍增加。

本文介绍 Eon 如何借助 Amazon Bedrock AgentCore（一个可使用任意框架或模型大规模构建、连接和优化智能体的平台）来替代按工具配置的凭证和本地 Model Context Protocol（MCP）进程，改用单一经过身份验证的网关。这一方案让开发者和自主智能体能够统一访问跨三个云端的调查工具。新工程师现在大约两分钟就能用上全部调查工具，而此前配置凭证和本地 MCP 服务器需要两天时间。

关于 Eon

Eon 为 AI 时代提供自主数据基础（Autonomous Data Foundation）。该平台可发现并分类 AWS、Azure 和 GCP 上的云资源。它提供持续的去重备份，根据 Eon 的内部测量，可将存储成本降低最多 50%。它还能检测勒索软件和失控智能体造成的损害，并为 AI 智能体提供实时、有依据的上下文。所有这些都通过单一的只读 AWS Identity and Access Management（IAM）角色运行，数据以 Apache Parquet 和 Apache Iceberg 格式存储。Eon 由前 AWS 工程师创立，其软件即服务（SaaS）基础设施运行在 AWS 上。

挑战

Eon 的内部工程团队需要调查跨多个云端和数十个运维系统的生产事故。一个崩溃的 Kubernetes Pod 需要在同一次会话中检查容器日志、Grafana 指标、该部署的 GitHub 拉取请求（PR）以及云服务商的健康状态。

Eon 需要解决几项关键需求：

• 凭证整合 —— 每新增一个工具，就多出一项需要配置、保护和轮换的集成，随着工具集扩大，保持一致变得越来越困难。
• 消除本地 MCP 进程 —— 每位开发者都在本地运行多个 MCP 服务器，难以标准化和保持最新。
• 身份隔离 —— 工程师通过基于角色的权限访问各个系统，但没有一个统一的地方来决定每个人或每个智能体可以调用哪些工具。
• 无需网络开销的跨账户访问 —— 在多个 AWS 账户中托管 MCP 服务器需要为每个账户配置虚拟私有云（VPC）对等连接或 AWS PrivateLink，成倍增加了运营成本和设置时间。
• 开发者入职 —— 新工程师在调查第一次事故之前，大约要花 2 天时间配置凭证和本地 MCP 服务器。
• 智能体访问 —— Eon 的自主站点可靠性工程（SRE）智能体（在 Amazon Bedrock 上运行 Claude）需要与人员相同的工具访问权限，但权限不同。

工程人员数量不断增长，加上 AI 工具和 MCP 快速扩张，使得维护凭证和本地 MCP 服务器的成本越来越高。这促使 Eon 转向集中式解决方案。

考虑过的方案

在基于 AgentCore 构建之前，Eon 评估了几种替代方案：

方案 1：带自定义身份验证的集中式代理

每个 harness 都有自己的代理配置，包含所有目标。一个单一的反向代理聚合所有工具，并带有自定义认证层。这解决了凭证整合问题，但只支持远程 MCP，并且需要从零开始构建和维护工具协议转换、会话管理和授权逻辑。实现和维护负担很重。

选项 2：Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，是一个托管网关，内置身份联合、基于 Cedar 的授权策略和 Runtime 托管，可将本地 MCP 服务器转换为远程 HTTP 端点。这无需自定义基础设施即可满足所有需求。

Eon 选择了选项 2，因为它以托管能力的形式提供了身份分离、跨账户连接和策略执行，而不是需要他们自行构建和维护的代码。当时只有这两个选项。

解决方案概述

Eon 部署了完整的 Amazon Bedrock AgentCore 技术栈：AgentCore Gateway、Amazon Bedrock AgentCore 中的 Policy、AgentCore Runtime 和 AgentCore Identity，这些都是 Amazon Bedrock AgentCore 的能力。下图展示了客户端请求如何通过认证层流向单一网关。网关将已授权的工具调用路由到跨多个 AWS 账户托管在 AgentCore Runtime 上的目标。

图 1：Eon 在 Amazon Bedrock AgentCore 上的集中式网关架构

该架构分为五层：

客户端

使用 Claude Code、Cursor 或 OpenAI Codex 的开发者连接到单一的 MCP URL。在 Amazon Bedrock 上运行 Claude 的自主 SRE 代理以不同的身份连接到同一网关。

身份平面

企业单点登录（SSO）通过 Amazon Cognito 进行联合，由 Cognito 签发 JSON Web Token（JWT）并将其交给网关。Amazon API Gateway 位于前端，作为面向人类的 OAuth 入口点，代理 MCP 会话。代理使用 Cognito client_credentials 授权直接向网关进行认证。

一个网关，最小权限访问

单一的 AgentCore MCP Gateway 作为公司范围的前门。处于 ENFORCE 模式的 Cedar 策略控制哪些主体可以调用哪些工具。读操作仅对选定组开放，而非所有已认证用户。写操作仅限于低影响的协作操作，例如对 PR 或工单发表评论，生产工具为只读。

Amazon Bedrock AgentCore 中的 Policy

Cedar 策略将每个主体映射到允许的工具。写操作仅限于低影响的协作操作，例如对 PR 或工单发表评论，生产工具为只读。网关在转发到目标之前，会针对每个 tools/call 请求依据 Cedar 进行评估。

目标

数十个目标 MCP 服务器在一个网关上暴露数百个工具，由分布在多个 AWS 账户中的 AgentCore Runtime 提供服务。每个 Runtime 将基于本地 stdio 的 MCP 服务器转换为可通过网关访问的 Streamable HTTP 端点。

开发者打开其集成开发环境（IDE），配置一个 MCP URL，通过企业 SSO 进行认证，网关便将数百个工具聚合到单个 tools/list 响应中。无需本地设置，也无需按工具配置令牌。

身份与访问分离

核心安全决策是在网关层面通过 Cedar 策略强制执行读写边界。

单一网关，策略强制分离：

网关同时接受 JWT 令牌（人类用户通过企业 SSO 和 Cognito 认证）和 client_credentials 令牌（智能体）。Cedar 策略决定每个主体可以执行哪些操作。获批组中的人类用户获得读取权限。写操作需要显式的 Cedar 许可，且仅授予特定的智能体身份。

Cedar 强化了按工具粒度的控制：

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

Cedar 策略通过 GitHub PR 以代码形式管理，并附带评审意见，使团队对每一次权限变更都有版本控制和审计追踪。

在网关内部，Cedar 策略按 SSO 组限定工具访问范围，而组映射到岗位角色。工程师默认可以访问开发和测试环境。生产环境访问遵循 Eon 的安全与合规控制：只读、通过审批流程即时授予，并接受审计。新团队成员的分组也以同样方式按角色限定，而不是按他们恰好负责哪个服务。由于每个智能体操作都在 ENFORCE 模式下对照 Cedar 检查，并被限定在最小权限工具集内，自主智能体在安全、有界的范围内运行。它只能调用其身份被明确允许调用的特定工具。

“以前，我们的内部智能体无法访问开发者使用的那些调查工具。现在，它使用同一个 Gateway，拥有自己的身份和更严格的工具集。”

— Roei Zavida，Eon 高级 DevOps 工程师

跨账户连接

Eon 在多个 AWS 账户中运行 Runtime，按环境或服务边界组织。AgentCore Gateway 通过 IAM 跨账户角色代入访问每个 Runtime。账户 B 中的 Runtime 通过标准 IAM 信任策略信任账户 A 中的 AgentCore Gateway 执行角色。

这消除了：

• 跨多个 AWS 账户的 VPC 对等连接配置和路由表管理。
• 每个账户的 PrivateLink 端点成本。
• 账户之间的安全组协调。
• 每个新账户数天的设置时间（被一个 IAM 信任策略取代，可在几分钟内部署）。

目标挂载模式：

根据每个工具的认证和托管模式，Eon 使用两种主要挂载模式。下表总结了何时使用每种模式，并给出示例。

大多数目标使用 Runtime + IAM。Eon 仅在需要缩减目录或注入网关无法以其他方式提供的凭证时，才包装远程 MCP。

调查会话流程

以下流程追踪一名开发者调查生产事故的过程：

1. 认证。开发者打开 Claude Code（或 Cursor/Codex）并连接到网关 MCP URL。IDE 通过企业 SSO 发起 OAuth。Cognito 签发携带开发者身份和组成员关系的 JWT。
2. 工具发现。网关聚合来自数十个已连接目标的 `tools/list`，并向 IDE 返回包含数百个工具的统一清单。开发者在一个列表中看到所有可用的调查工具。
3. 工具调用。开发者提问：“显示过去一小时支付服务的错误率峰值。”IDE 的智能体选择 Grafana 查询工具并发送 `tools/call` 请求。
4. 策略评估。网关根据 Cedar 对请求进行评估。开发者的组成员身份授予了对 Grafana 工具的访问权限。请求通过。
5. 运行时执行。网关将请求转发给托管 Grafana MCP 服务器的运行时（运行在单独的 AWS 账户中）。运行时使用存储在 AgentCore Identity 保险库中的服务凭证向 Grafana 进行身份验证，执行查询并返回结果。
6. 跨工具关联。智能体随后检查 Kubernetes 部署状态和相关的 GitHub PR，这两者分别路由到不同的运行时。开发者无需切换工具或重新进行身份验证即可看到关联结果。

大规模实践中的经验教训

在部署给 100 多名开发者、约 10,000 个会话后，暴露出了一些生产环境中的挑战：

管理 Cedar 策略大小

网关预先索引的每个工具 schema 都会增加 Cedar 策略的大小。由于数十个目标暴露了大量工具清单，Eon 的策略逐渐逼近大小配额。解决方案：对工具数量多的目标使用 DYNAMIC 列表模式。在 DYNAMIC 模式下，网关在请求时将 tools/list 调用转发给 MCP 服务器，而不是预先索引 schema，从而为策略增加零字节。

代价是 DYNAMIC 目标无法使用语义工具搜索。Eon 采用混合配置：对需要按用户 OAuth 的目标（工具数量较少，需要预索引 schema 以支持同意流程）使用 DEFAULT 模式，对大型目录目标使用 DYNAMIC 模式。

标准 MCP 客户端的 OAuth 会话绑定

Claude Code、Cursor 和 Codex 期望使用 OAuth state 参数来进行跨站请求伪造（CSRF）防护。AgentCore 使用会话 URI 绑定。Eon 构建了一个 Amazon API Gateway 中间层，在两种协议之间进行转换，使标准 MCP 客户端无需修改即可完成 OAuth 流程。

过滤工具界面

一些 MCP 服务器暴露了数百个工具。单个开发者只需要其中与其服务相关的一部分。Eon 构建了一个运行时包装器，在运行时层过滤工具清单，减少 tools/list 响应中的噪音，并防止意外调用无关操作。这种方法还使这些目标保持在 DEFAULT 模式，保留了 DYNAMIC 模式所牺牲的语义搜索和嵌入式功能。

结果

单网关架构已在 Eon 内部工程团队的生产环境中运行了数月。最明显的成果是开发者上手。设置对完整工具集的访问权限从大约两天配置凭证和本地 MCP 服务器缩短到约两分钟。新工程师连接一个网关 URL，通过企业 SSO 进行身份验证，即可立即看到其角色允许的工具。

内部代理节省了大部分时间，因为它通过网关获得了更多上下文，从而提高了调查准确性。工程师节省了以前花在 AI 工具设置上的时间，因为他们只需连接到网关 URL。

Eon 正在探索如何用相同的模式在其自有产品中支持 AI 能力。

“AgentCore 为我们提供了一个经过身份验证的 MCP Gateway，取代了按工具分配令牌和本地 MCP 进程的做法。开发人员和我们的内部代理现在可以通过一个 URL 访问 Kubernetes、Grafana、GitHub 以及我们的云账户。”

— Roei Zavida，Eon 高级 DevOps 工程师

结论

本文介绍了 Eon 如何用单个 Amazon Bedrock AgentCore MCP Gateway 取代按工具分配的凭证和本地 MCP 进程。其结果是基于 Cedar 的身份隔离、无需 VPC 对等连接的跨账户连接，以及为跨三个云的 100 多名开发人员和自主代理提供统一的工具访问。单网关架构、Cedar 最小权限强制执行，以及 DEFAULT 与 DYNAMIC 混合策略模式，是 ISV 将代理和开发人员连接到跨多云工具时可复用的模式。

要详细了解如何在 Amazon Bedrock AgentCore 上构建，请查看以下资源：

• Amazon Bedrock AgentCore Gateway 文档。
• Amazon Bedrock AgentCore Runtime 文档。
• Amazon Bedrock AgentCore 入门研讨会。

关于作者

Dor Shaboy

Dor 是 AWS 的解决方案架构师，在云架构和安全工程领域拥有十多年经验。Dor 与 ISV 密切合作，帮助他们扩展并采用 AWS 服务。过去一年，他一直与 Eon 合作，支持其基于 Amazon Bedrock AgentCore 构建的 AI 驱动调查平台。工作之余，Dor 喜欢徒步和网球。

Eashan Kaushik

Eashan 是 Amazon Web Services 的 AI/ML 专业解决方案架构师。他热衷于打造前沿的生成式 AI 解决方案，同时在工作中坚持以客户为中心。担任此职位之前，他获得了纽约大学 Tandon 工程学院的计算机科学硕士学位。工作之余，他喜欢运动、举重和跑马拉松。

Roei Zavida

Roei 是 Eon 的高级 DevOps 工程师，所在的团队负责运行 Eon 的云基础设施和内部开发人员工具，包括工程师用于调查生产环境的 AgentCore MCP Gateway。