8.0
热点
AI SCORE
技术实践2026-10-20 23:57
Eon 用统一 MCP 网关简化多云排障
AWS ML Blog#MCP#多云#智能体
Editor brief · 编辑速览
Eon 通过 Amazon Bedrock AgentCore 网关统一接入 AWS、GCP 和 Azure 的生产调查工具，替代分散凭证和本地 MCP 进程。该方案服务超过百名开发者及自主智能体，据介绍将新工程师接入时间从两天缩短至两分钟。
本文由 Eon 的 Roei Zavida 共同撰写，是一篇客座文章。
构建 AI 产品的独立软件供应商（ISV），需要让 Agent 和人类用户连接到跨云的数十种运维工具，而这些工具各有不同的认证模型、网络边界和访问策略。当这些工具同时分布在 AWS、GCP 和 Azure 上时，集成的复杂度也会成倍增加。
本文介绍 Eon 如何使用 Amazon Bedrock AgentCore。这个平台支持使用任意框架或模型，大规模构建、连接和优化 Agent。Eon 用一个统一认证的网关，替代了各工具独立的凭证和本地 Model Context Protocol（MCP）进程，让开发者和自主 Agent 能够统一访问三个云平台上的排障工具。新工程师现在只需大约两分钟，就能访问所有排障工具；此前，配置凭证和本地 MCP 服务器需要两天。
Eon 为 AI 时代提供 Autonomous Data Foundation（自主数据基础）。该平台能够发现并分类 AWS、Azure 和 GCP 上的云资源，提供持续、去重的备份。根据 Eon 的内部测量，这能将存储成本最多降低 50%。它还可以检测勒索软件和失控 Agent 造成的破坏，并为 AI Agent 提供实时、有据可依的上下文。所有这些能力只需要一个只读的 AWS Identity and Access Management（IAM）角色，数据以 Apache Parquet 和 Apache Iceberg 格式存储。Eon 由前 AWS 工程师创立，其软件即服务（SaaS）基础设施运行在 AWS 上。
Eon 的内部工程团队需要跨多个云平台和数十个运维系统排查生产事故。一个 Kubernetes pod 崩溃后，工程师需要在同一个会话中检查容器日志、Grafana 指标、此次部署对应的 GitHub pull request（PR），以及云服务商的健康状态。
Eon 需要解决几个关键问题：
工程团队人数不断增长，AI 工具和 MCP 的数量也迅速增加，维护凭证和本地 MCP 服务器的成本越来越高。这推动 Eon 转向集中式方案。
在基于 AgentCore 构建之前，Eon 评估了以下替代方案：
每个 Agent 运行环境都有自己的代理配置，其中包含所有目标。这个方案通过一个反向代理聚合所有工具，并配上自定义认证层。它能解决凭证整合问题，但只支持远程 MCP，而且工具协议转换、会话管理和授权逻辑都需要从头构建并持续维护，实现和维护负担很重。
Amazon Bedrock AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力。它提供托管网关，内置身份联合、基于 Cedar 的授权策略，并通过 Runtime 托管将本地 MCP 服务器转换为远程 HTTP 端点。无需自建基础设施，就能满足所有要求。
Eon 选择了方案 2，因为身份隔离、跨账户连接和策略执行都由托管能力提供，无需自己编写和维护相关代码。当时参与比较的只有这两个方案。
Eon 部署了完整的 Amazon Bedrock AgentCore 技术栈：AgentCore Gateway、Policy in Amazon Bedrock AgentCore、AgentCore Runtime 和 AgentCore Identity，它们都是 Amazon Bedrock AgentCore 的组成能力。下图展示了客户端请求如何经过认证层，进入统一网关。网关随后将获得授权的工具调用，路由到托管在多个 AWS 账户的 AgentCore Runtime 上的目标。
图 1：Eon 基于 Amazon Bedrock AgentCore 的集中式网关架构
该架构分为五层：
开发者打开集成开发环境（IDE），配置一个 MCP URL，通过企业 SSO 完成认证，网关就会将数百种工具聚合到一个 tools/list 响应中。无需本地配置，也无需为每种工具准备单独的 token。
核心安全决策是：在网关层通过 Cedar 策略，强制执行读写权限边界。
网关同时接受 JWT token（人类用户通过企业 SSO 和 Cognito 获取）和 client_credentials token（供 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 的安全与合规控制：仅允许读取，通过审批流程即时授予，并保留审计记录。新团队成员的用户组也按同样的方式划定权限，依据的是角色，而非他们恰好负责哪个服务。由于每个 Agent 操作都会经过 ENFORCE 模式下的 Cedar 检查，且被限制在遵循最小权限原则的工具集合内，自主 Agent 始终在明确、安全的边界内运行。它只能调用其身份被显式授权使用的特定工具。
“以前，我们的内部 Agent 无法访问开发者使用的那些排障工具。现在，它通过自己的身份访问同一个 Gateway，使用范围更严格的工具集。”
——Roei Zavida，Eon 高级 DevOps 工程师
Eon 将 Runtime 部署在多个 AWS 账户中，按照环境或服务边界组织。AgentCore Gateway 通过 IAM 跨账户角色代入访问各个 Runtime。账户 B 中的 Runtime 通过标准 IAM 信任策略，信任账户 A 中的 AgentCore Gateway 执行角色。
这消除了以下工作和成本：
根据各工具的认证和托管模型，Eon 主要使用两种接入模式。下表汇总了每种模式的适用场景，并给出了示例。
大多数目标使用 Runtime + IAM。只有在需要精简远程 MCP 的工具目录，或注入网关无法直接提供的凭证时，Eon 才会为远程 MCP 增加包装层。
下面的流程展示了一位开发者如何排查生产事故：
tools/list，向 IDE 返回包含数百种工具的统一清单。开发者可以在一个列表中看到所有可用的排障工具。tools/call 请求。部署覆盖 100 多位开发者、累计约 10,000 次会话后，一些生产环境中的挑战浮现出来：
网关预先索引的每个工具 schema，都会增加 Cedar 策略的大小。数十个目标暴露了庞大的工具清单，使 Eon 的策略大小逐渐接近配额上限。解决办法是：对工具数量较多的目标使用 DYNAMIC 列表模式。在 DYNAMIC 模式下，网关会在请求发生时，将 tools/list 调用转发给 MCP 服务器，而非预先索引 schema，因此不会给策略增加任何字节。
代价是，DYNAMIC 目标无法使用语义工具搜索。Eon 采用混合配置：需要按用户进行 OAuth 授权的目标使用 DEFAULT 模式，这类目标的工具数量较少，且授权同意流程需要预先索引的 schema；工具目录较大的目标则使用 DYNAMIC 模式。
Claude Code、Cursor 和 Codex 期望使用 OAuth 的 state 参数来防范跨站请求伪造（CSRF）。AgentCore 则采用 session-URI 绑定。Eon 构建了一个 Amazon API Gateway 适配层，在两种协议之间进行转换，让标准 MCP 客户端无需修改就能完成 OAuth 流程。
某些 MCP 服务器会暴露数百种工具，但每位开发者只需要其中与自己服务相关的一部分。Eon 构建了一个 Runtime 包装层，在 Runtime 层筛选工具清单，减少 tools/list 响应中的干扰信息，并防止误调用无关操作。这种方式还可以让这些目标继续使用 DEFAULT 模式，保留 DYNAMIC 模式会失去的语义搜索和内嵌功能。
这套单网关架构已经在 Eon 内部工程团队的生产环境中运行了数月。最明显的成效体现在开发者入职配置上：获得完整工具集访问权限所需的时间，从大约两天的凭证和本地 MCP 服务器配置，缩短到大约两分钟。新工程师只需连接一个网关 URL，通过企业 SSO 完成认证，就能立即看到其角色获准使用的工具。
节省的时间大部分来自内部 Agent：它能通过网关获得更多上下文，从而提高排障准确性。工程师也省去了此前配置 AI 工具的时间，因为现在只需要连接网关 URL。
Eon 正在探索如何将同样的模式用于自身产品中的 AI 能力。
“AgentCore 给了我们一个统一认证的 MCP Gateway，替代了每种工具各自的 token 和本地 MCP 进程。现在，开发者和我们的内部 Agent 通过一个 URL，就能访问 Kubernetes、Grafana、GitHub 和我们的云账户。”
——Roei Zavida，Eon 高级 DevOps 工程师
本文介绍了 Eon 如何使用一个 Amazon Bedrock AgentCore MCP Gateway，替代各工具独立的凭证和本地 MCP 进程。最终，它实现了基于 Cedar 的身份隔离、无需 VPC 对等连接的跨账户连接，并为 100 多位开发者及自主 Agent 提供跨三个云平台的统一工具访问。对于需要让 Agent 和开发者连接多个云平台工具的 ISV，单网关架构、Cedar 最小权限执行，以及 DEFAULT 与 DYNAMIC 混合策略模式，都是可以复用的方案。
如需进一步了解如何基于 Amazon Bedrock AgentCore 构建，请参阅以下资源：