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

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

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

本文介绍 Eon 如何借助 Amazon Bedrock AgentCore（一个可使用任意框架或模型大规模构建、连接和优化智能体的平台）来应对这一挑战。Eon 使用它将按工具配置的凭证和本地模型上下文协议（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 检查，并限定在最小权限工具集内，自主代理在安全、有界的范围内运行。它只能调用其身份被明确允许调用的特定工具。

“以前，我们的内部代理无法访问开发者使用的相同调查工具。之后，它使用相同的网关，拥有自己的身份和更严格的工具集。”

— Roei Zavida，Eon 高级 DevOps 工程师

跨账户连接

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

这消除了：

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

目标附加模式：

根据每个工具的身份验证和托管模型，Eon 使用两种主要的附加模式。下表总结了何时使用每种模式并给出了示例。

模式	何时使用	示例
Runtime + IAM	工具需要通过 IAM 凭证进行云跳转	Grafana 查询、Kubernetes API 调用
Runtime 包装远程 MCP	工具表面需要过滤或凭证转换	Linear

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

调查会话流程

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

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

大规模实践中的经验教训

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

管理 Cedar 策略大小

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

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

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

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

过滤工具界面

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

结果

指标	使用 AgentCore 之前	使用 AgentCore 之后
每位开发者的凭证集	每个系统/MCP 服务器一个（GitHub、Grafana、云账户等）	0（一次 SSO 登录）
每台机器上的本地 MCP 进程	10	0
开发者上手时间	2 天	2 分钟
跨账户网络配置	每个账户的 VPC 对等连接	0（仅 IAM）
工具授权	按工具配置	面向人类和智能体的单一 Cedar 策略
平台上的开发者	—	100+
从一个 URL 可访问的工具	—	数百个（跨数十个目标）
已处理的会话	—	~10,000

单网关架构已在 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 上构建，请查看以下资源：

关于作者

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。