Eon 如何借助 Amazon Bedrock AgentCore 上的 MCP 网关构建多云调查

AWS ML Blog 2026-10-21T09:36:41.749990

本文是与 Eon 的 Roei Zavida 合写的客座文章。

开发 AI 产品的独立软件供应商（ISV）需要把智能体（agent）和人都接上几十种运维工具。这些工具分散在不同云上，各自的认证方式、网络边界和访问策略都不一样。如果这些工具还要同时横跨 AWS、GCP 和 Azure，需要对接的地方就会成倍增加。本文介绍 Eon 如何借助 Amazon Bedrock AgentCore 解决这个问题——这是一个可以用任意框架、任意模型大规模构建、连接和优化智能体的平台。Eon 用它把过去按工具逐个配置凭证、在本地跑 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 服务器，既难统一标准，也难保持版本更新。

身份隔离：工程师访问各个系统时依赖基于角色的权限，但没有一个统一的地方来决定每个人或每个 agent 能调用哪些工具。

跨账户访问，不必折腾网络：把 MCP 服务器分散托管在多个 AWS 账户中，需要为每个账户配置 VPC 对等连接或 AWS PrivateLink，运维成本和搭建时间成倍增加。

开发者上手：新工程师要花大约 2 天配置凭证和本地 MCP 服务器，才能开始调查第一个故障。

Agent 访问：Eon 的自主 SRE agent（在 Amazon Bedrock 上运行 Claude）需要和人一样的工具访问权限，但权限范围不同。

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

考虑过的方案

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

方案一：集中式代理 + 自定义认证

每个 harness 都有自己的代理配置，包含所有目标。用一个反向代理聚合所有工具，再配一层自定义认证。这种做法解决了凭证集中的问题，但只支持远程 MCP，而且工具协议转换、会话管理、授权逻辑都得从零开发和维护，实现和维护负担很重。

方案二：Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力，属于托管网关，内置身份联合、基于 Cedar 的授权策略，以及能把本地 MCP 服务器转成远程 HTTP 端点的 Runtime 托管。它无需自建基础设施就能满足所有需求。

Eon 选择了方案二，因为它把身份隔离、跨账户连接和策略执行作为托管能力提供，而不是需要自己开发和维护的代码。

当时摆在桌面上的只有这两个选项。

方案概览

Eon 部署了完整的 Amazon Bedrock AgentCore 能力组合，包括 AgentCore Gateway、Amazon Bedrock AgentCore 中的 Policy、AgentCore Runtime 和 AgentCore Identity。下图展示了客户端请求如何经过认证层进入单一网关，再由网关把经过授权的工具调用路由到分布在多个 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 或工单上留言评论；生产类工具一律只读。网关在把请求转发给目标之前，会用 Cedar 对每一个 tools/call 请求进行评估。

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

开发者打开集成开发环境（IDE），配置一个 MCP 地址，通过企业单点登录（SSO）完成认证，网关就会把数百个工具聚合成一个 tools/list 响应返回。不用在本地做任何配置，也不用为每个工具单独申请令牌。

身份与访问分离

核心安全决策是在网关层用 Cedar 策略（Cedar policy）划定读写边界。

单一网关，策略强制隔离

网关同时接受两类令牌：JWT 令牌（人类用户，经由企业 SSO 和 Cognito）和 client_credentials 令牌（agent）。Cedar 策略决定每个主体能做什么。批准组内的人类用户拥有读权限；写操作需要 Cedar 明确授权，而且只授予特定的 agent 身份。

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 的安全与合规要求：只读、通过审批流程临时授予（just-in-time），并全程审计。新成员加入后，其所在组也按同样方式划定权限——按角色划分，而不是看他碰巧负责哪个服务。由于每个 agent 动作都会在 ENFORCE 模式下对照 Cedar 检查，并且被限定在最小权限的工具集内，这个自主 agent 只能在安全、有边界的范围内运行。它只能调用身份明确获准调用的那些工具。

“以前，我们的内部 agent 够不到开发者用的那些调查工具。现在，它用同一个 Gateway，带着自己的身份和更收紧的工具集。”——Roei Zavida，Eon 高级 DevOps 工程师

跨账户连接

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

这样做省掉的东西：

跨多个 AWS 账户的 VPC peering 配置和路由表管理
每个账户的 PrivateLink 终端节点费用
账户之间的安全组协调
每接入一个新账户要花几天的搭建工作（现在换成一条 IAM 信任策略，几分钟就能部署）

目标挂载模式： 根据每个工具的身份认证和托管方式，Eon 主要使用两种挂载模式。下表说明各自适用场景并给出示例。

模式	适用场景	示例
Runtime + IAM	工具需要通过 IAM 凭证做一次云端跳转	Grafana 查询、Kubernetes API 调用
Runtime 包装远程 MCP	工具接口需要过滤或做凭证转换	Linear

大多数目标使用 Runtime + IAM。

Eon 只在必要时才包装远程 MCP：要么为了缩减工具目录，要么为了注入网关本身无法提供的凭证。

调查会话流程

下面跟着一个开发人员排查生产事故的完整流程：

认证。 开发人员打开 Claude Code（或 Cursor、Codex），连上网关的 MCP 地址。IDE 发起 OAuth，走企业 SSO。Cognito 签发 JWT，里面带着开发人员的身份和所属用户组。

工具发现。 网关汇总几十个已连接目标返回的 tools/list，把数百个工具整理成一份统一清单交给 IDE。开发人员在一个列表里就能看到所有可用的调查工具。

工具调用。 开发人员问：“帮我看看 payments 服务过去一小时的错误率飙升情况。”IDE 里的 agent 选中 Grafana 查询工具，发出 tools/call 请求。

策略评估。 网关拿 Cedar 检查这个请求。开发人员所在的用户组有权限使用 Grafana 工具，请求通过。

运行时执行。 网关把请求转发给托管 Grafana MCP 服务器的 Runtime（跑在另一个 AWS 账号里）。Runtime 用 AgentCore Identity 保险库中存的服务凭证向 Grafana 认证，执行查询，返回结果。

跨工具关联。 agent 接着查 Kubernetes 部署状态和相关的 GitHub PR，这两类请求分别路由到不同的 Runtime。开发人员不用切换工具，也不用重新认证，就能看到关联好的结果。

规模化部署的经验

这套系统上线后服务 100 多名开发人员、累计约 1 万次会话，暴露出一些生产环境的问题：

控制 Cedar 策略的体积。 网关预先索引的每个工具 schema 都会让 Cedar 策略变大。当几十个目标各自暴露大量工具清单时，Eon 的策略体积一路逼近配额上限。解决办法是：对工具数量多的目标启用 DYNAMIC 列表模式。在 DYNAMIC 模式下，网关不再预先索引 schema，而是在请求时把 tools/list 调用转发给 MCP 服务器，策略体积增加为零。代价是 DYNAMIC 目标用不了语义化工具搜索。

Eon 采用混合配置：DEFAULT 模式面向需要按用户 OAuth 授权的目标（工具数量较少，同意流程需要预建索引的 schema），DYNAMIC 模式面向工具目录庞大的目标。

标准 MCP 客户端（Claude Code、Cursor、Codex）的 OAuth 会话绑定要求使用 OAuth state 参数来防范跨站请求伪造（CSRF）。AgentCore 采用的是会话 URI 绑定。Eon 在 Amazon API Gateway 上构建了一个适配层，在两种协议之间做转换，标准 MCP 客户端无需改动即可完成 OAuth 流程。

工具面过滤
有些 MCP 服务器会暴露数百个工具，而单个开发者做自己的服务只需要其中一小部分。Eon 在 Runtime 层加了一个包装器，对工具清单做过滤，从而减少 tools/list 响应中的噪音，也避免误调用无关操作。这样做还能让这些目标继续留在 DEFAULT 模式，保留语义搜索和内嵌特性——这些正是 DYNAMIC 模式所牺牲的。

效果

指标	使用 AgentCore 前	使用 AgentCore 后
每位开发者的凭据集	每个系统/MCP 服务器一个（GitHub、Grafana、云账号等）	0（一次 SSO 登录）
每台机器上的本地 MCP 进程	10	0
开发者上手时间	2 天	2 分钟
跨账号网络配置	每个账号配 VPC peering	0（仅靠 IAM）
工具授权	每个工具单独配置	人类和 agent 共用一条 Cedar 策略
平台上的开发者	—	100+
从单一 URL 可访问的工具	—	数百个（横跨几十个目标）
已处理会话数	—	约 10,000

这套单一网关架构已经在 Eon 内部工程团队的生产环境中运行了几个月。最明显的变化是开发者上手。配置完整工具集的访问权限，从原来大约两天折腾凭据和本地 MCP 服务器，缩短到两分钟左右。新工程师只需连上网关 URL，通过企业 SSO 认证，马上就能看到自己角色允许使用的工具。

省下来的时间大部分来自内部 agent：它通过网关获得了更多上下文，调查准确率随之提升。工程师也不用再花时间搭 AI 工具，连上网关 URL 就行。

Eon 正在探索如何用同样的模式为自家产品加入 AI 能力。“AgentCore 给了我们一个经过身份认证的 MCP Gateway，不用再为每个工具单独管理令牌和本地 MCP 进程。开发者和我们的内部代理现在通过一个 URL 就能访问 Kubernetes、Grafana、GitHub 以及我们的云账户。”——Eon 高级 DevOps 工程师 Roei Zavida

结论

本文介绍了 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 入门 Workshop

查看原文