MCP Gateway en AWS frente a Azure: opciones y configuración comparadas

Tu agente funciona bien con tres herramientas. Luego el equipo añade una API de facturación, un sistema de tickets, un índice de búsqueda y algunos servicios internos, y cada cliente MCP acaba cargando sus propias URL, sus propias credenciales y su propia idea de lo que es una petición segura. Un MCP gateway resuelve eso poniendo un único punto de acceso controlado delante de cada herramienta. Lo difícil es decidir dónde vive. AWS ofrece un gateway gestionado diseñado para agentes, Azure amplía un producto de gestión de API que muchos equipos ya usan, y ambas nubes permiten alojar tu propio proxy si quieres control total.

Esta comparación pone las opciones reales frente a frente: qué hace cada una, cómo funciona la autenticación, cómo está estructurada la facturación y los pasos exactos para ponerla en marcha. Los nombres de producto, los planes y los límites cambian rápido, así que los detalles siguientes siguen la documentación del proveedor a octubre de 2026. Revisa esa documentación antes de comprometerte con nada.

Qué hace un MCP gateway

Un gateway es un proxy inverso que habla el Model Context Protocol. Los clientes envían mensajes JSON-RPC como tools/list y tools/call por Streamable HTTP, y el gateway decide quién puede llamar a qué, reenvía cada llamada al backend correcto y registra lo que ha pasado. Tus agentes de IA nunca necesitan saber si una herramienta vive en una función Lambda, en una API REST o en un contenedor de otra región.

Una sola puerta de entrada para las herramientas

Sin gateway, cada cliente MCP apunta directamente a cada servidor MCP. Diez agentes y ocho servidores significan ochenta conexiones que configurar, proteger y supervisar. Con un gateway, los diez clientes hablan con un único endpoint, y el gateway reparte las llamadas a los servidores que tiene detrás. Cambiar un backend pasa a ser un cambio en el gateway y no un despliegue en cada cliente.

Cuándo compensa un gateway

• Autenticación centralizada: valida los tokens una vez, en lugar de hacerlo dentro de cada servidor.
• Límites de uso y cuotas: evita que un agente en bucle sature tu API de facturación.
• Registro de auditoría: un único lugar donde ver qué agente llamó a qué herramienta y cuándo.
• Selección de herramientas: expón las 12 operaciones que necesitan los agentes en lugar de las 200 que tiene tu API.
• Backends mixtos: funciones Lambda, API REST y servidores MCP remotos detrás de un único tools/list.

💡 Consejo: Pregúntate quién llama a cada herramienta y con qué frecuencia. Si la respuesta sincera es "un solo desarrollador, en local", un gateway es prematuro. En cuanto aparezca un segundo equipo o un cliente externo, deja de ser opcional.

Las opciones de AWS

Lo básico de AgentCore Gateway

Amazon Bedrock AgentCore alcanzó la disponibilidad general en octubre de 2025, y AgentCore Gateway es su punto de entrada para el tráfico de agentes. Un gateway tiene uno o más destinos en tres categorías:

• Destinos MCP: el gateway actúa como servidor MCP y agrupa todos los destinos MCP en un único servidor virtual, de modo que los clientes ven un único tools/list consolidado.
• Destinos HTTP: el tráfico va directamente al backend, por ejemplo a otro agente, con enrutamiento por ruta y sin agregación ni traducción de protocolo.
• Destinos de inferencia: las peticiones de modelos de lenguaje (LLM) llegan a sus proveedores a través de un único endpoint, y el campo model de la petición elige el destino.

Todo gateway necesita un autorizador de entrada. Las opciones son OAuth con JWT, IAM con AWS Signature Version 4, un modo de "solo autenticación" que valida los tokens y deja la autorización en manos del destino, y ninguna autorización para desarrollo. En producción deberías usar una de las dos primeras.

Destinos que puedes conectar

Para los destinos MCP, AWS enumera varios tipos de origen:

• Funciones Lambda: el gateway invoca tu función y convierte la respuesta a formato MCP.
• API REST de API Gateway que ya tengas en marcha.
• Especificaciones OpenAPI: una API REST existente se convierte en un conjunto de herramientas MCP.
• Modelos Smithy: útiles para servicios de AWS y APIs personalizadas.
• Servidores MCP remotos: el gateway puede pasar prompts y recursos además de herramientas.

Las llamadas salientes a destinos OpenAPI y MCP pasan por proveedores de credenciales, que pueden almacenar credenciales de API o ajustes de OAuth, firmar con SigV4 u omitir la autenticación en endpoints públicos. Los destinos Lambda y Smithy usan el rol de ejecución que les asignes. Hay dos extras que importan a gran escala: la búsqueda semántica de herramientas, que ayuda a un agente a encontrar la herramienta adecuada entre cientos, y la sincronización de capacidades para los destinos MCP.

Autoalojado en ECS o EKS

Algunos equipos prescinden de la opción gestionada y ejecutan un proxy MCP de código abierto en ECS o EKS detrás de un Application Load Balancer. Tú te encargas del escalado, las actualizaciones, la validación de tokens y los registros, pero también obtienes enrutamiento personalizado, una base de código que puedes reutilizar en cualquier nube y ninguna dependencia de la lista de funciones de un solo proveedor. Encaja con equipos de plataforma que tienen experiencia con Kubernetes y se convierte en una carga costosa para todos los demás.

Las opciones de Azure

API Management como MCP gateway

Azure API Management (APIM) ofrece dos formas integradas de publicar servidores MCP:

1. API REST como servidor MCP: cualquier API REST gestionada en APIM puede exponerse, y sus operaciones se convierten en herramientas MCP.
2. Servidor MCP existente: coloca APIM delante de un servidor creado con LangChain, LangServe, Azure Logic Apps o Azure Functions.

La gobernanza pasa por el motor de políticas. Las políticas se aplican actualmente a todas las operaciones expuestas como herramientas en un servidor MCP dado, y Microsoft enumera la limitación de velocidad y las cuotas, la validación de JWT con Microsoft Entra ID u otro proveedor de identidad, el filtrado por IP y la caché de respuestas. El tráfico aparece en Azure Monitor y Application Insights, y Azure API Center puede funcionar como registro privado para que los equipos encuentren los servidores que existen. Todo puede gestionarse también como código con Bicep, Terraform, la CLI de Azure o plantillas ARM.

La disponibilidad es amplia: los niveles clásicos Developer, Basic, Standard y Premium, los niveles v2 (Basic v2, Standard v2, Premium v2) y el gateway autoalojado para tu propia infraestructura. Hay dos límites que importan. APIM admite solo herramientas MCP, sin recursos ni prompts, y las funciones MCP no están disponibles en los workspaces.

El MCP Gateway de código abierto de Microsoft

Al margen de APIM, el repositorio microsoft/mcp-gateway en GitHub es un proxy inverso y una capa de gestión para servidores MCP sobre Kubernetes. Su plano de datos usa enrutamiento con estado y consciente de la sesión, de modo que las peticiones que comparten un ID de sesión llegan a la misma instancia del servidor, y su plano de control despliega, actualiza y elimina adaptadores de servidor. La autorización se basa en roles de Entra ID, y el repositorio incluye rutas de despliegue con PowerShell y Bicep hacia AKS con Azure Container Registry y Cosmos DB.

💡 Cambio de especificación: La revisión 2026-07-28 de la especificación MCP eliminó las sesiones del protocolo, por lo que desaparecen el handshake de initialize y la cabecera Mcp-Session-Id. La afinidad de sesión sigue importando para los servidores con revisiones anteriores o para los que guardan estado en memoria, pero los servidores nuevos ya no la necesitan.

Backends que puedes poner detrás

Los ejemplos propios de Microsoft de servidores existentes detrás de APIM son LangChain, LangServe, Logic Apps y Functions. Cualquier servidor compatible con MCP al que APIM pueda llegar por HTTP es un candidato, lo que convierte al gateway en un envoltorio práctico para un conjunto mixto de servidores antiguos y nuevos.

Comparación lado a lado

Identidad. Las dos opciones gestionadas validan JWT, y APIM acepta explícitamente tokens de Entra ID u otros proveedores de identidad. AgentCore añade SigV4 para los llamantes que ya tienen credenciales de AWS, lo que resulta útil para el tráfico entre servicios. Elijas lo que elijas, prueba cómo responde el gateway a una llamada sin autenticar. El modelo de autorización de MCP se basa en OAuth, y un 401 limpio que indique a los clientes el servidor de autorización correcto es lo que les permite iniciar sesión sin configuración escrita a mano.

Facturación. AgentCore Gateway cobra por las llamadas que tus agentes hacen a través de él, contadas como operaciones MCP como ListTools, CallTool y Ping, además de las consultas de búsqueda y las herramientas indexadas para la búsqueda semántica. APIM se factura por nivel y unidades de escala, así que tu factura sigue a la capacidad y no a las llamadas. El gateway de Microsoft es de código abierto, pero pagas el clúster, el registro, la base de datos y las personas que los parchean. El tráfico irregular y de bajo volumen suele favorecer el precio por operación, y el tráfico constante y pesado suele favorecer la capacidad fija. Consulta la página de precios de cada proveedor para ver las cifras actuales.

💡 Consejo: Como ListTools y Ping cuentan como operaciones facturables en AgentCore, los clientes muy habladores que actualizan la lista de herramientas en cada turno disparan la factura. Guarda la lista en caché en el cliente durante unos minutos.

Configuración en AWS y Azure

Ambos caminos son rápidos para una primera herramienta si tu backend ya existe. Los pasos siguientes se mantienen en el nivel que garantiza la documentación, así que comprueba las etiquetas de la consola y las opciones de la CLI con la documentación actual.

Pasos de configuración de AgentCore Gateway

1. Elige el autorizador de entrada. Apunta un autorizador OAuth (JWT) a la URL de configuración OpenID de tu proveedor de identidad y a las audiencias permitidas, o elige IAM si tus llamantes son nativos de AWS.
2. Crea el gateway con ese autorizador.
3. Añade un destino. Asocia una función Lambda con su esquema de herramienta, sube una especificación OpenAPI o introduce la URL de un servidor MCP remoto.
4. Asigna credenciales salientes mediante un proveedor de credenciales cuando el backend necesite una credencial de API o un token de OAuth.
5. Copia el endpoint MCP del gateway en la configuración de tu cliente.
6. Llama a tools/list y confirma que aparece cada herramienta que esperas y ninguna otra.

Pasos de configuración de API Management

1. Confirma el nivel. Usa un nivel clásico o v2 que admita MCP, o el gateway autoalojado.
2. Crea el servidor MCP a partir de una API REST gestionada y elige qué operaciones se convierten en herramientas, o apunta APIM a un servidor MCP existente.
3. Añade políticas de entrada. Valida primero el token y después limita la frecuencia de llamadas, porque un limitador colocado antes de la autenticación deja que el tráfico anónimo consuma la cuota.
4. Configura la monitorización con Application Insights y añade una cabecera de ID de correlación.
5. Registra el servidor en API Center para que otros equipos puedan encontrarlo.

Una política de inicio tiene este aspecto:

<inbound>
  <base />
  <validate-jwt header-name="Authorization" failed-validation-httpcode="401"
                failed-validation-error-message="Unauthorized">
    <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
    <audiences>
      <audience>api://mcp-gateway</audience>
    </audiences>
  </validate-jwt>
  <rate-limit calls="60" renewal-period="60" />
</inbound>

Copiar prompt

Prueba ambos con una sola petición

La misma petición funciona con cualquiera de los dos gateways, lo que la convierte en una forma justa de compararlos:

curl -X POST "$GATEWAY_URL" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Copiar prompt

Los servidores con revisiones antiguas de la especificación pueden esperar primero una llamada initialize y después una cabecera Mcp-Session-Id, mientras que un servidor de la revisión 2026-07-28 no. Para algo más que una prueba rápida, apunta el MCP Inspector al gateway y ejecuta una llamada real a una herramienta, porque una petición puntual no mostrará cómo se comportan las respuestas en streaming.

Errores que rompen los despliegues

• Exponer cada operación como herramienta. Los modelos tienden a elegir peores herramientas de una lista de 200 que de una lista de 12. Selecciona en APIM y apóyate en la búsqueda semántica de herramientas de AgentCore.
• Limitar la frecuencia antes de autenticar. Los llamantes anónimos deberían rechazarse primero, no contarse.
• Reenviar el token del cliente a los backends. Deja que el gateway tenga sus propias credenciales salientes, para que un backend nunca acepte un token emitido para otra audiencia.
• Dar por hecho que existen sesiones. Diseña las herramientas para que no guarden estado. Si una herramienta necesita estado, devuelve un ID desde una llamada de creación y haz que el modelo lo pase de vuelta como un argumento más.
• Lógica de políticas pesada en la ruta MCP. Cualquier cosa que lea o almacene en búfer una respuesta en streaming puede retrasar los eventos. Prueba con un cliente real.
• Ignorar el límite de solo herramientas. Si tus servidores dependen de prompts o recursos, APIM no los transportará por ahora.

Sea cual sea tu elección, envía la telemetría del gateway a los paneles que tu equipo ya vigila antes de que entre en producción el primer agente. El volumen de llamadas a herramientas, las tasas de error y la latencia por herramienta te dicen qué usan de verdad los agentes y cuáles de tus 200 operaciones nunca llama nadie.

Cuál deberías elegir

Elige AgentCore si trabajas en AWS

Elígelo cuando tus herramientas sean funciones Lambda, API REST de API Gateway o especificaciones OpenAPI, cuando quieras un único endpoint gestionado que las agrupe y cuando IAM u OAuth ya gobiernen a tus llamantes. También encaja con equipos que quieren búsqueda semántica de herramientas sin tener que construirla, y con servidores que dependen de prompts y recursos.

Elige API Management si tu enfoque es Microsoft

Elígelo cuando tus API REST ya estén en APIM, tu identidad sea Entra ID y tu equipo de plataforma conozca el motor de políticas. Obtienes límites de uso, cuotas, caché y monitorización en los que ya confías. Elige el gateway de código abierto de Microsoft solo cuando quieras control a nivel de Kubernetes y puedas permitirte operarlo.

¿Trabajas en ambas nubes? AgentCore puede agregar servidores MCP remotos, y APIM puede publicar servidores a los que llega por HTTP, así que un gateway de una nube puede colocarse delante de herramientas de la otra. Funciona, pero añade latencia, cargos de salida de datos y un segundo sistema de identidad que conciliar. En la práctica, un gateway por nube con un proveedor de identidad compartido suele ser más sencillo que un único gateway que abarque ambas.

💡 Comprobación rápida: Cuenta tus fuentes de herramientas, luego tu proveedor de identidad y después la forma de tu tráfico. Sobre todo Lambda y OpenAPI apuntan a AgentCore. Sobre todo REST ya en APIM apunta a API Management. Un equipo de plataforma de Kubernetes con necesidades de control estrictas apunta a la opción autoalojada.

Crea tus propias imágenes en Picasso IA

Un MCP gateway es infraestructura, y la buena infraestructura es la parte que nadie ve. Lo mismo vale para los servicios a los que llaman tus agentes. PicassoIA, por ejemplo, expone una API para desarrolladores en api.picassoia.com/v1 con autenticación bearer, trabajos asíncronos que creas y luego consultas, y un límite de 5 predicciones simultáneas por cuenta que comparten la API y las conexiones MCP. Ese tipo de techo es justo lo que un gateway debería hacer cumplir por ti: poner en cola o limitar del lado tuyo en lugar de dejar que los agentes acumulen rechazos.

Los modelos de lenguaje también ayudan en el trabajo de configuración. Puedes redactar un borrador de Bicep, Terraform o una especificación OpenAPI para tu gateway con Claude Sonnet 5, revisar una política con GPT 5.6 Sol o resumir rápidamente un changelog largo de un proveedor con Gemini 3.5 Flash. Trata su resultado como un primer borrador y pásalo por la misma revisión que le harías al pull request de un compañero.

Y luego están las imágenes. Los textos de arquitectura, las wikis internas y las publicaciones de lanzamiento se leen mejor con una buena foto principal. Abre Picasso IA, elige un modelo de texto a imagen como Seedream 4.5, describe la escena que quieres en unas pocas frases y genera varias variantes. Cambia el objetivo, la luz o el escenario, y compara. Tu primera imagen no será la mejor, y la quinta suele serlo. Explora todos los modelos en picassoia.com/en/all-models y crea tus propias imágenes hoy mismo.