Cómo Eon construyó una investigación multi-nube con un MCP Gateway en Amazon Bedrock AgentCore

Esta es una publicación invitada escrita en colaboración con Roei Zavida de Eon.

Los proveedores independientes de software (ISV) que crean productos impulsados por IA necesitan conectar agentes y humanos a docenas de herramientas operativas en varias nubes, cada una con diferentes modelos de autenticación, límites de red y políticas de acceso. Cuando esas herramientas abarcan AWS, GCP y Azure simultáneamente, la superficie de integración se multiplica.

Esta publicación describe cómo Eon utilizó Amazon Bedrock AgentCore, una plataforma para construir, conectar y optimizar agentes a escala, con cualquier framework o modelo. Eon la usó para reemplazar las credenciales por herramienta y los procesos locales del Model Context Protocol (MCP) con una única puerta de enlace autenticada. El resultado brinda a los desarrolladores y agentes autónomos acceso unificado a las herramientas de investigación en tres nubes. Los nuevos ingenieros ahora acceden a todas sus herramientas de investigación en unos dos minutos, en lugar de los dos días que antes tomaba configurar credenciales y servidores MCP locales.

Acerca de Eon

Eon proporciona la Autonomous Data Foundation para la era de la IA. La plataforma descubre y clasifica recursos en la nube en AWS, Azure y GCP. Ofrece respaldo continuo desduplicado que reduce los costos de almacenamiento hasta en un 50 por ciento según las mediciones internas de Eon. También detecta ransomware y daños de agentes maliciosos, y brinda contexto en vivo y fundamentado para agentes de IA. Todo esto funciona desde un único rol de AWS Identity and Access Management (IAM) de solo lectura, almacenando los datos en formatos Apache Parquet y Apache Iceberg. Fundada por exingenieros de AWS, Eon ejecuta su infraestructura de software como servicio (SaaS) en AWS.

El desafío

El equipo de ingeniería interno de Eon investiga incidentes de producción en múltiples nubes y docenas de sistemas operativos. Un pod de Kubernetes caído requiere revisar los registros de contenedores, las métricas de Grafana, el pull request (PR) de GitHub del despliegue y el estado de salud del proveedor de nube dentro de la misma sesión.

Eon necesitaba abordar varios requisitos clave:

• Consolidación de credenciales — Cada nueva herramienta agregaba otra integración que configurar, proteger y rotar, lo que se volvía más difícil de mantener consistente a medida que crecía el conjunto de herramientas.
• Eliminar procesos MCP locales — Cada desarrollador ejecutaba varios servidores MCP localmente, lo que era difícil de estandarizar y mantener actualizado.
• Separación de identidades — Los ingenieros accedían a cada sistema con permisos basados en roles, pero no había un lugar único para decidir qué herramientas podía llamar cada persona o agente.
• Acceso entre cuentas sin sobrecarga de red — Alojar servidores MCP en múltiples cuentas de AWS requería virtual private cloud (VPC) peering o AWS PrivateLink por cuenta, multiplicando el costo operativo y el tiempo de configuración.
• Incorporación de desarrolladores — Los nuevos ingenieros dedicaban aproximadamente 2 días a configurar credenciales y servidores MCP locales antes de investigar su primer incidente.
• Acceso de agentes — El agente autónomo de ingeniería de confiabilidad del sitio (SRE) de Eon (que ejecuta Claude en Amazon Bedrock) necesitaba el mismo acceso a herramientas que los humanos, pero con permisos diferentes.

El crecimiento del personal de ingeniería combinado con un conjunto en rápida expansión de herramientas de IA y MCP hizo que mantener credenciales y servidores MCP locales fuera cada vez más costoso. Esto impulsó a Eon hacia una solución centralizada.

Enfoques considerados

Antes de construir sobre AgentCore, Eon evaluó alternativas:

Opción 1: Proxy centralizado con autenticación personalizada

Cada harness tenía su propia configuración de proxy con todos los destinos. Un único proxy inverso que agregaba todas las herramientas, con una capa de autenticación personalizada. Esto resolvía la consolidación de credenciales, pero solo admitía MCP remoto y requería construir y mantener desde cero la traducción del protocolo de herramientas, la gestión de sesiones y la lógica de autorización. La carga de implementación y mantenimiento era significativa.

Opción 2: Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, es una puerta de enlace administrada con federación de identidades integrada, políticas de autorización basadas en Cedar y alojamiento Runtime que convierte servidores MCP locales en endpoints HTTP remotos. Esto abordó todos los requisitos sin infraestructura personalizada.

Eon eligió la Opción 2 porque proporcionaba separación de identidades, conectividad entre cuentas y aplicación de políticas como capacidades administradas en lugar de código que tendrían que construir y mantener. Estas eran las únicas dos opciones sobre la mesa.

Descripción general de la solución

Eon desplegó la pila completa de Amazon Bedrock AgentCore: AgentCore Gateway, Policy en Amazon Bedrock AgentCore, AgentCore Runtime y AgentCore Identity, todas ellas capacidades de Amazon Bedrock AgentCore. El siguiente diagrama muestra cómo las solicitudes de los clientes fluyen a través de la capa de autenticación hacia una única puerta de enlace. La puerta de enlace enruta las llamadas a herramientas autorizadas a objetivos alojados en AgentCore Runtimes distribuidos en varias cuentas de AWS.

Figura 1: arquitectura de puerta de enlace centralizada de Eon en Amazon Bedrock AgentCore

La arquitectura tiene cinco capas:

Clientes

Los desarrolladores que usan Claude Code, Cursor u OpenAI Codex se conectan a una única URL de MCP. Un agente SRE autónomo que ejecuta Claude en Amazon Bedrock se conecta a la misma puerta de enlace con una identidad distinta.

Plano de identidad

El inicio de sesión único (SSO) corporativo se federa a través de Amazon Cognito, que genera el JSON Web Token (JWT) y lo entrega a la puerta de enlace. Amazon API Gateway se sitúa delante como punto de entrada OAuth para humanos, haciendo de proxy de la sesión MCP. Los agentes se autentican con Cognito client_credentials grants directamente contra la puerta de enlace.

Una sola puerta de enlace, acceso con privilegios mínimos

Un único AgentCore MCP Gateway sirve como puerta de entrada a nivel de toda la empresa. Las políticas Cedar en modo ENFORCE controlan qué principals pueden invocar qué herramientas. Las operaciones de lectura están disponibles para grupos seleccionados, no para todos los usuarios autenticados. Las operaciones de escritura se limitan a acciones de colaboración de bajo impacto, como comentar en un PR o ticket, y las herramientas de producción son de solo lectura.

Política en Amazon Bedrock AgentCore

Las políticas Cedar mapean cada principal a las herramientas permitidas. Las operaciones de escritura se limitan a acciones de colaboración de bajo impacto, como comentar en un PR o ticket, y las herramientas de producción son de solo lectura. La puerta de enlace evalúa cada tools/call solicitud contra Cedar antes de reenviarla al destino.

Destinos

Docenas de servidores MCP de destino que exponen cientos de herramientas en la única puerta de enlace, servidos por AgentCore Runtimes distribuidos en múltiples cuentas de AWS. Cada Runtime convierte servidores MCP locales basados en stdio en endpoints Streamable HTTP accesibles a través de la puerta de enlace.

Un desarrollador abre su entorno de desarrollo integrado (IDE), configura una única URL de MCP, se autentica mediante el SSO corporativo, y la puerta de enlace agrega cientos de herramientas en una sola tools/list respuesta. Sin configuración local y sin tokens por herramienta.

Separación de identidad y acceso

La decisión de seguridad central fue aplicar los límites de lectura y escritura mediante políticas Cedar a nivel de la puerta de enlace.

Puerta de enlace única, separación aplicada por políticas:

La puerta de enlace acepta tanto tokens JWT (humanos a través del SSO corporativo y Cognito) como client_credentials tokens (agentes). Las políticas Cedar determinan qué puede hacer cada principal. Los humanos en grupos aprobados obtienen acceso de lectura. Las operaciones de escritura requieren permisos Cedar explícitos concedidos solo a identidades de agentes específicas.

Cedar refuerza la granularidad por herramienta:

// 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"
);

Las políticas Cedar se gestionan como código mediante PRs de GitHub con comentarios de revisión, lo que proporciona al equipo control de versiones y rastro de auditoría en cada cambio de permisos.

Dentro de la puerta de enlace, las políticas Cedar delimitan el acceso a las herramientas por grupo de SSO, y los grupos se mapean al rol laboral. Los ingenieros tienen acceso a los entornos de desarrollo y pruebas por defecto. El acceso a producción sigue los controles de seguridad y cumplimiento de Eon: es de solo lectura, se concede justo a tiempo mediante un proceso de aprobación y se audita. El grupo de un nuevo miembro del equipo se delimita de la misma manera, por rol en lugar de por el servicio que casualmente posea. Como cada acción del agente se verifica contra Cedar en modo ENFORCE y se delimita a un conjunto de herramientas con privilegios mínimos, el agente autónomo opera dentro de límites seguros y acotados. Solo puede invocar las herramientas específicas que su identidad tiene explícitamente permitidas.

“Antes, nuestro agente interno no podía alcanzar las mismas herramientas de investigación que usaban los desarrolladores. Después, usa la misma Gateway con su propia identidad y un conjunto de herramientas más reducido.”

— Roei Zavida, Senior DevOps Engineer, Eon

Conectividad entre cuentas

Eon ejecuta Runtimes en múltiples cuentas de AWS, organizadas por entorno o límite de servicio. AgentCore Gateway alcanza cada Runtime mediante la asunción de roles IAM entre cuentas. El Runtime en la cuenta B confía en el rol de ejecución de AgentCore Gateway en la cuenta A a través de una política de confianza IAM estándar.

Lo que esto eliminó:

• Configuración de VPC peering y gestión de tablas de rutas entre múltiples cuentas de AWS.
• Costos de endpoints PrivateLink por cuenta.
• Coordinación de security groups entre cuentas.
• Días de configuración por cada cuenta nueva (reemplazados por una política de confianza IAM, desplegable en minutos).

Patrones de conexión de destinos:

Dependiendo del modelo de autenticación y alojamiento de cada herramienta, Eon utiliza dos patrones de conexión principales. La siguiente tabla resume cuándo usar cada patrón y da un ejemplo.

La mayoría de los destinos usan Runtime + IAM. Eon solo envuelve un MCP remoto para reducir su catálogo o insertar una credencial que el gateway no puede proporcionar de otro modo.

Flujo de una sesión de investigación

El siguiente flujo sigue a un desarrollador investigando un incidente de producción:

1. Autenticación. El desarrollador abre Claude Code (o Cursor/Codex) y se conecta a la URL MCP del gateway. El IDE inicia OAuth a través del SSO corporativo. Cognito emite un JWT que transporta la identidad del desarrollador y sus membresías de grupo.
2. Descubrimiento de herramientas. El gateway agrega `tools/list` de decenas de destinos conectados y devuelve un manifiesto unificado de cientos de herramientas al IDE. El desarrollador ve todas las herramientas de investigación disponibles en una sola lista.
3. Invocación de herramientas. El desarrollador pregunta: “Muéstrame el pico de tasa de errores del servicio de pagos en la última hora”. El agente del IDE selecciona la herramienta de consulta de Grafana y envía una solicitud `tools/call`.
4. Evaluación de políticas. El gateway evalúa la solicitud contra Cedar. La membresía de grupo del desarrollador otorga acceso a la herramienta de Grafana. La solicitud pasa.
5. Ejecución en Runtime. El gateway reenvía la solicitud al Runtime que aloja el servidor MCP de Grafana (que se ejecuta en una cuenta de AWS separada). El Runtime se autentica en Grafana usando una credencial de servicio almacenada en la bóveda de AgentCore Identity, ejecuta la consulta y devuelve los resultados.
6. Correlación entre herramientas. El agente continúa revisando el estado del despliegue de Kubernetes y el PR relacionado de GitHub, cada uno enrutado a Runtimes diferentes. El desarrollador ve resultados correlacionados sin cambiar de herramientas ni volver a autenticarse.

Lecciones aprendidas a escala

El despliegue a 100+ desarrolladores y aproximadamente 10,000 sesiones reveló desafíos de producción:

Gestión del tamaño de las políticas de Cedar

Cada esquema de herramienta que el gateway preindexa contribuye al tamaño de la política de Cedar. Con decenas de destinos que exponen manifiestos de herramientas extensos, la política de Eon creció hacia la cuota de tamaño. La solución: modo de listado DYNAMIC para destinos con muchas herramientas. En modo DYNAMIC, el gateway reenvía las tools/list llamadas al servidor MCP en el momento de la solicitud en lugar de preindexar esquemas, agregando cero bytes a la política.

La contrapartida es que la búsqueda semántica de herramientas no está disponible para los destinos DYNAMIC. Eon ejecuta una configuración híbrida: modo DEFAULT para los destinos que requieren OAuth por usuario (menor cantidad de herramientas, necesitan esquemas preindexados para el flujo de consentimiento) y modo DYNAMIC para los destinos con catálogos grandes.

Vinculación de sesión OAuth para clientes MCP estándar

Claude Code, Cursor y Codex esperan el parámetro OAuth state para protección contra falsificación de solicitudes entre sitios (CSRF). AgentCore usa vinculación session-URI. Eon construyó un shim de Amazon API Gateway que traduce entre ambos protocolos para que los clientes MCP estándar puedan completar el flujo de OAuth sin modificaciones.

Filtrado de superficies de herramientas

Algunos servidores MCP exponen cientos de herramientas. Los desarrolladores individuales solo necesitan un subconjunto para su servicio. Eon construyó un wrapper de Runtime que filtra el manifiesto de herramientas en la capa de Runtime, reduciendo el ruido en las tools/list respuestas y evitando la invocación accidental de operaciones irrelevantes. Este enfoque también mantiene esos destinos en modo DEFAULT, preservando la búsqueda semántica y las funciones integradas que el modo DYNAMIC sacrifica.

Resultados

La arquitectura de gateway único ha estado en producción para el equipo de ingeniería interno de Eon durante varios meses. El resultado más claro es la incorporación de desarrolladores. La configuración del acceso al conjunto completo de herramientas pasó de aproximadamente dos días de configuración de credenciales y servidores MCP locales a unos dos minutos. Un ingeniero nuevo se conecta a una única URL de gateway, se autentica a través del SSO corporativo y ve de inmediato las herramientas que su rol le permite.

El agente interno representa la mayor parte del tiempo ahorrado, porque obtiene acceso a más contexto a través del gateway, mejorando la precisión de las investigaciones. Los ingenieros ahorran el tiempo que antes dedicaban a la configuración de herramientas de IA, porque solo necesitan conectarse a la URL del gateway.

Eon está explorando cómo los mismos patrones pueden soportar capacidades de IA en su propio producto.

“AgentCore nos dio un único MCP Gateway autenticado en lugar de tokens por herramienta y procesos MCP locales. Los desarrolladores y nuestro agente interno ahora acceden a Kubernetes, Grafana, GitHub y nuestras cuentas en la nube desde una única URL.”

— Roei Zavida, Ingeniero Senior de DevOps, Eon

Conclusión

Esta publicación describió cómo Eon reemplazó las credenciales por herramienta y los procesos MCP locales con un único Amazon Bedrock AgentCore MCP Gateway. El resultado es una separación de identidades basada en Cedar, conectividad entre cuentas sin VPC peering y acceso unificado a herramientas para más de 100 desarrolladores y agentes autónomos en tres nubes. La arquitectura de gateway único, la aplicación del privilegio mínimo con Cedar y el modo de política híbrido DEFAULT y DYNAMIC son patrones reutilizables para los ISV que conectan agentes y desarrolladores a herramientas en múltiples nubes.

Para obtener más información sobre cómo desarrollar con Amazon Bedrock AgentCore, revise estos recursos:

• Documentación de Amazon Bedrock AgentCore Gateway.
• Documentación de Amazon Bedrock AgentCore Runtime.
• Taller Getting Started with Amazon Bedrock AgentCore.

Sobre los autores