Eon用AgentCore MCP网关统一多云调查工具，新工程师接入时间从两天降至两分钟
AWS博客刊出的Eon客座文章称，该公司以单一网关替代按工具配置的凭证和本地MCP进程，让 100 多名开发者和一个自主SRE代理通过企业SSO访问跨AWS、GCP、Azure的数百个工具；文章还披露了Cedar策略配额压力和客户端OAuth兼容改造。
AI解读：Eon将内部调查工具接入集中到一个Amazon Bedrock AgentCore MCP Gateway，开发者用Claude Code、Cursor或Codex连接同一MCP地址，经企业SSO登录后可看到其角色被允许的工具列表。
据这篇由AWS与Eon工程师合写的客座文章，改造前每名开发者要为本机约 10 个MCP进程和各个系统分别配置凭证，首次接入约需两天；改造后为一次SSO登录、约两分钟。
权限边界由网关上的Cedar策略在ENFORCE模式下逐次tools/call校验：人类组获得读权限，写操作仅授予特定代理身份且限于评论PR等低影响动作，生产工具为只读、按需审批并审计。
跨AWS账户的工具由AgentCore Runtime托管，网关通过IAM跨账户角色信任访问，文章称这替代了按账户配置VPC对等连接和PrivateLink端点。
文章列出的规模数字为 100 多名开发者、数十个目标、数百个工具、约 1 万次会话，该架构已在Eon内部工程团队生产运行数月；这些数字均来自Eon自述，未见第三方核验。
Eon在AWS博客发表客座文章，介绍其用Amazon Bedrock AgentCore搭建的多云调查架构：以单一MCP网关替代按工具配置的凭证和本地MCP进程，让开发者与自主SRE代理通过同一入口访问分布在AWS、GCP、Azure上的运维工具。文章由AWS的Dor Shaboy与Eon高级DevOps工程师Roei Zavida合写。
文章给出的核心数字是接入时间：新工程师此前需约两天配置凭证和本地MCP服务器，现在连接一个网关地址并经企业SSO认证，约两分钟即可看到角色允许的工具。该架构已在Eon内部工程团队生产运行数月，覆盖 100 多名开发者、约 1 万次会话。
改造前的接入负担
Eon的内部工程团队需要跨多个云和数十个运维系统排查生产事故。文章举例：一个Kubernetes Pod崩溃，要在同一次会话里查容器日志、Grafana指标、部署对应的GitHub PR和云厂商健康状态。
文章列出的问题包括：每接一个新工具就多一套要配置、保护和轮换的凭证；每名开发者在本机运行多个MCP服务器，难以统一和保持最新；缺少统一位置决定某个人或某个代理能调用哪些工具；跨AWS账户托管MCP服务器需要按账户配置VPC对等连接或PrivateLink。
Eon的自主SRE代理运行在Amazon Bedrock上的Claude，需要与人类相同的工具访问能力，但权限应不同。
- 改造前每名开发者本机约 10 个MCP进程，每个系统一套凭证
- 新工程师首次排查事故前约需两天做配置
- 跨账户访问按账户配置VPC对等连接或PrivateLink
选中托管网关而非自建代理
文章称Eon只评估了两个方案。其一是自建集中反向代理并加自定义认证层，能合并凭证，但只支持远程MCP，还需自行实现工具协议转换、会话管理和授权逻辑，维护负担大。
其二是Amazon Bedrock AgentCore Gateway。文章称它内置身份联合、基于Cedar的授权策略，以及把本地MCP服务器转换为远程HTTP端点的Runtime托管能力，因而被选中。这是Eon在文中的选择理由，AWS是该平台的提供方。
一个网关下的读写分离
架构分五层：客户端（Claude Code、Cursor、Codex以及以独立身份连接的SRE代理）、身份层、单一网关、Cedar策略、以及分布在多个AWS账户的Runtime目标。人类经企业SSO由Amazon Cognito签发JWT，Amazon API Gateway作为OAuth入口；代理则以Cognito的client_credentials授权直接对网关认证。
Cedar策略在ENFORCE模式下逐次评估tools/call请求。文章称读操作只对特定组开放，写操作限于评论PR或工单这类低影响协作动作，生产工具为只读，访问按Eon的安全与合规流程即时审批并审计。策略以代码形式通过GitHub PR管理，保留评审记录和审计轨迹。
Zavida在文中说，此前内部代理无法触及开发者使用的调查工具，现在它用同一网关、自己的身份和更窄的工具集接入。
- 人类凭JWT、代理凭client_credentials，同一网关按principal区分权限
- 示例策略允许代理sre-bot调用github_add_pr_comment，禁止人类组调用写工具
- 组按岗位角色映射，工程师默认可用开发与测试环境
跨账户连接与规模暴露的两个问题
Runtime按环境或服务边界分布在多个AWS账户，网关通过IAM跨账户角色代入访问，账户B的Runtime信任账户A的网关执行角色。文章称这去掉了跨账户的VPC对等连接、路由表管理、按账户的PrivateLink端点费用和安全组协调，新增账户从数天配置变为一条IAM信任策略。
扩展到 100 多名开发者、约 1 万次会话后，文章披露两个具体问题。一是Cedar策略体积：网关预索引的每个工具schema都计入策略大小，工具清单庞大时策略逼近配额，Eon对大工具量目标改用DYNAMIC列表模式，请求时才向MCP服务器转发tools/list，代价是该目标无法使用语义工具搜索；需要按用户OAuth的目标仍用DEFAULT模式，形成混合配置。
二是OAuth兼容：Claude Code、Cursor、Codex期望用OAuth state参数防CSRF，而AgentCore采用session-URI绑定，Eon自建Amazon API Gateway中间层做协议转换。此外，Eon还做了一个Runtime包装层，在Runtime侧过滤工具清单，减少tools/list噪音并避免误调用无关操作。
- 跨账户新增配置：从数天缩短为一条IAM信任策略，文章称部署可在数分钟内完成
- DYNAMIC模式的代价：该目标不支持语义工具搜索
- 工具过滤包装层让相关目标继续留在DEFAULT模式，保留语义搜索
结果数字的范围
文章给出前后对比：每名开发者凭证套数从每系统一套变为 0（一次SSO登录），本机MCP进程从 10 个变为 0，接入时间从两天变为两分钟，跨账户网络配置从按账户VPC对等连接变为 0，工具授权从逐工具配置变为一条Cedar策略同时覆盖人类和代理。平台上现有 100 多名开发者，从一个URL可访问数十个目标上的数百个工具。
这些数字是Eon对其内部工程团队使用情况的描述，文章未提供第三方评测或独立的效率测量。文中提到存储成本最多降低 50% 属于Eon对自身产品的内部测量，与本次网关改造不是同一事项。文章末尾称Eon正在探索把相同模式用于其产品内的AI能力，未给出时间表或效果数据。
- 已运行范围：Eon内部工程团队，生产环境数月
- 可访问工具：数十个目标、数百个工具，跨三个云
- 未披露：网关本身的故障率、延迟数据或安全事件记录