Servidor MCP sin servidor para acceso de agentes de IA a un lago de datos en Amazon ECS Fargate

Las organizaciones que crean aplicaciones basadas en inteligencia artificial (IA) enfrentan un desafío recurrente: dar a los agentes de modelos de lenguaje extensos (LLM) acceso a los lagos de datos empresariales sin duplicar la lógica de integración en cada agente y aplicación. La mayoría de los equipos comienzan conectando los agentes directamente a bases de datos y APIs, sin una pasarela compartida como un servidor del Model Context Protocol (MCP) en el medio. Cada nuevo conjunto de datos exige código personalizado, y cada agente implementa su propio control de acceso. A medida que crece el número de conjuntos de datos o de agentes, la aplicación de permisos diverge, y incorporar una nueva fuente de datos se convierte en un esfuerzo de ingeniería de varios días.

Nuestro equipo da soporte a la red del North America Sort Center (NASC) de Amazon, donde los equipos de planificación dependen de datos operativos para gestionar la capacidad, la mano de obra y el flujo de paquetes. Para dar a esos equipos acceso conversacional a esos datos, construimos un servidor Model Context Protocol (MCP) sin servidor en Amazon Elastic Container Service (Amazon ECS) con AWS Fargate para resolver este problema para los equipos de planificación del NASC. El servidor actúa como una pasarela centralizada y agnóstica al agente entre los agentes de IA y nuestro lago de datos empresarial. Exponer un nuevo conjunto de datos requiere solo un archivo de metadatos JSON que el servidor descubre automáticamente en la siguiente sincronización del pipeline.

En esta publicación, describimos la arquitectura, mostramos cómo un enfoque basado en metadatos elimina la necesidad de código de integración por conjunto de datos, y explicamos cómo la infraestructura sin servidor admite múltiples agentes y aplicaciones en un entorno multiinquilino.

Planteamiento del problema y objetivos de diseño

Dos desafíos interrelacionados moldearon cómo diseñamos este sistema: patrones fragmentados de acceso a los datos y un modelo de incorporación insostenible.

Desafío de integración a escala

Nuestro lago de datos contiene miles de conjuntos de datos que abarcan métricas operativas, análisis empresariales y datos específicos del dominio. Varios equipos querían asistentes de IA que pudieran consultar estos datos de forma conversacional, pero cada uno construyó su propia integración desde cero. Cada agente incorporaba su propia lógica de generación de SQL, conocimiento de esquemas y manejo de conexiones, por lo que un cambio de esquema significaba parchear cada agente individualmente. El control de acceso estaba fragmentado, sin un único punto de auditoría para las decisiones de acceso a los datos. Incorporar un nuevo conjunto de datos requería código de herramienta personalizado, validación de consultas y una nueva implementación, típicamente un esfuerzo de varios días por tabla.

Objetivos de diseño

Establecimos cuatro requisitos:

• Acceso al lago de datos basado en configuración. Añadir un conjunto de datos requiere solo un archivo de metadatos, no código.
• Interfaces de herramientas agnósticas al agente. Cualquier cliente compatible con MCP puede invocar las mismas herramientas.
• Aplicación centralizada de permisos. El control de acceso se aplica en la capa del servidor MCP.
• Infraestructura elástica. El sistema escala con los patrones de cargas de trabajo de IA ráfagas.

Descripción general de la solución

La arquitectura separa las responsabilidades en cuatro capas (cliente, servidor MCP, herramientas y actualización de la base de conocimientos), cada una escalable e implementable de forma independiente. Un catálogo de metadatos sustenta la capa de herramientas, almacenando descripciones de esquemas, semántica a nivel de columnas y relaciones entre tablas a las que el agente de IA hace referencia al generar SQL. Como el agente obtiene el conocimiento del esquema del catálogo en el momento de la consulta, no hay necesidad de codificar estructuras de tablas ni de volver a implementar cuando los esquemas cambian. La capa de actualización de la base de conocimientos mantiene ese catálogo al día, indexando los metadatos de nuevos conjuntos de datos a medida que llegan. Las siguientes secciones describen cada capa en detalle.

Recorrido por la arquitectura

El siguiente diagrama muestra el flujo de solicitudes desde la consulta del usuario hasta la capa de datos a través de las cuatro capas. Un usuario envía una consulta desde una aplicación cliente (chat web, Slack, un complemento de IDE o un agente externo). La solicitud se resuelve a través de Amazon Route 53 para DNS y llega a un Application Load Balancer en una subred pública, configurado con HTTPS y AWS WAF. El balanceador de carga enruta a Amazon Cognito, que autentica al usuario y enriquece la solicitud. El tráfico autenticado luego entra en la subred privada, donde la capa de cliente se ejecuta en Amazon ECS Fargate. Esta capa gestiona el estado de sesión en Amazon DynamoDB y reenvía las solicitudes a través de un Application Load Balancer interno a la capa del servidor MCP, también en Amazon ECS Fargate. En la capa del servidor MCP, un agente de IA basado en Amazon Bedrock orquesta herramientas construidas con FastMCP (un framework de Python para construir servidores MCP). Amazon Bedrock Guardrails se aplica a cada interacción con el modelo. A la derecha, la capa de datos contiene los backends de las herramientas. Amazon Athena y Amazon Redshift ejecutan consultas SQL contra el lago de datos, y Amazon Bedrock Knowledge Bases, la capacidad totalmente gestionada de Retrieval Augmented Generation (RAG), maneja la búsqueda semántica. La ingesta de datos en Amazon Simple Storage Service (Amazon S3) y en las bases de conocimientos se gestiona mediante AWS Lambda. Cada capa se describe en detalle en las secciones siguientes.

Figura 1: Flujo de solicitudes a través del servidor MCP sin servidor, desde las aplicaciones cliente hasta la capa de datos

Capa de cliente MCP: Autenticación y gestión de sesiones

Una solicitud fluye desde la aplicación cliente a través de Amazon Route 53 para la resolución de DNS hasta un Application Load Balancer configurado con HTTPS y AWS WAF. El balanceador de carga reenvía el tráfico al servicio de cliente de Amazon ECS Fargate, que se integra con Amazon Cognito para la autenticación mediante JSON Web Token (JWT) y con Amazon DynamoDB para el almacenamiento de sesiones.

Una configuración de mapeo de contexto impulsa este enriquecimiento, acotando cada consulta solo a las tablas relevantes. En nuestras pruebas, este acotamiento mantiene la latencia de interacción de extremo a extremo en el rango de 15–20 segundos. El siguiente ejemplo muestra una configuración de mapeo de contexto:

{
  "package_data": {
    "description": "Package tracking and delivery information",
    "tables": ["analytics_db.regional_order_summary", "operations_gold.load_summary"],
    "sources": {"wiki": [], "quip": []}
  },
  "labor_planning": {
    "description": "Workforce management and capacity planning",
    "tables": ["workforce.capacity_details"],
    "sources": {"wiki": [], "quip": []}
  }
}

Cuando un contexto especifica tablas, el servidor MCP reduce su búsqueda en el catálogo de metadatos a esas tablas, lo que disminuye el ruido y mejora la precisión de la generación de SQL. Agregar un nuevo dominio de negocio solo requiere añadir una entrada a este mapeo.

Capa de servidor MCP: Ejecución sin estado con estado de conversación

El servidor MCP se ejecuta en su propio clúster de ECS Fargate, aislado de la capa de clientes. Las solicitudes llegan a él a través de Amazon Route 53 y un Application Load Balancer interno en una subred privada. El servidor se encarga de toda la orquestación, incluido el análisis de consultas, la selección de herramientas, la ejecución y la generación de respuestas. A través del endpoint del protocolo MCP (/mcp) una interfaz JSON-RPC basada en FastMCP, los clientes externos compatibles con MCP, como Amazon Q Developer o extensiones de IDE, pueden descubrir e invocar herramientas directamente.

Las tareas de Fargate son sin estado y el estado de la conversación se persiste en DynamoDB, por lo que las tareas pueden reemplazarse o escalarse sin pérdida de datos. Cuando llega una solicitud, el agente recupera el historial de la sesión, analiza la intención del usuario mediante Amazon Bedrock, descubre e invoca las herramientas apropiadas y transmite los resultados de vuelta al usuario.

Capa de herramientas y acceso al lago de datos basado en metadatos

Cada herramienta se registra con FastMCP y es detectable en tiempo de ejecución:

Las herramientas de consulta de Athena son la interfaz principal del data lake. El agente primero consulta el catálogo de metadatos para comprender los esquemas disponibles, genera una consulta SQL optimizada a través de Amazon Bedrock, valida y autocorrige el SQL para compatibilidad con Athena y luego lo ejecuta. Los resultados regresan al agente orquestador para su síntesis en lenguaje natural.

Controles de IA responsable

Amazon Bedrock Guardrails se aplica a todas las interacciones con los LLM y está diseñado para filtrar contenido dañino, aplicar comprobaciones de fundamentación y ayudar a bloquear intentos de inyección de instrucciones. Estas barreras de protección funcionan como controles de producción en la capa del servidor MCP, por lo que todos los agentes conectados se benefician de las mismas políticas de seguridad de contenido independientemente de cómo se conecten. Las herramientas de consulta de Athena aplican SELECT-solo, rechazando operaciones de escritura a nivel de la herramienta antes de que lleguen al data lake.

Capa de actualización de la base de conocimiento: Incorporación de conjuntos de datos con un solo archivo JSON

Todo el sistema está construido en torno a la extensibilidad basada en configuración. Añadir un nuevo conjunto de datos requiere un archivo JSON de metadatos que describa la tabla y una entrada opcional de mapeo de contexto. El archivo captura el esquema de la tabla, el contexto de negocio y la semántica a nivel de columnas. Sirve como la única fuente de verdad que el agente de IA utiliza para entender y consultar el conjunto de datos:

{
  "database_service_name": "athena",
  "database_name": "analytics_db",
  "table_name": "regional_order_summary",
  "business_description_for_the_table": "Regional order history with shipping status and delivery performance. Contains completed orders with delivery data. Refreshes daily. In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.",
  "column_details": {
    "order_id [varchar]": {
      "description": "Unique order identifier assigned at checkout.",
      "sample_values": ["ORD-20250115-001234", "ORD-20250116-005678"]
    },
    "order_date [timestamp(3)]": {
      "description": "Date and time the order was placed. Use this column for time-range filtering.",
      "sample_values": ["2025-01-15 08:00:00.000", "2025-01-16 12:30:00.000"]
    },
    "warehouse_id [varchar]": {
      "description": "Fulfillment center that processed the order.",
      "sample_values": ["FC-EAST-07", "FC-WEST-03", "FC-SOUTH-12"]
    }
  },
  "load_type": "Incremental (refreshes last 7 days)",
  "refresh_frequency": "Daily at 6:00 AM UTC",
  "table_size": "~2.1B rows",
  "creation_time": "2024-03-15",
  "last_refresh_time": "2025-05-20T06:00:00Z"
}

El business_description_for_the_table campo contiene sugerencias de consulta específicas del motor, como «usar siempre date() para envolver literales de cadena», que reducen los fallos de validación de SQL. El column_details campo empareja cada column_name [type] con una descripción en lenguaje natural y valores de muestra, proporcionando al agente tanto conocimiento del esquema como semántica de negocio. El sample_values es importante para una generación precisa de la cláusula WHERE porque el agente aprende patrones de datos reales, por ejemplo que warehouse_id contiene códigos como FC-EAST-07 en lugar de nombres escritos en texto como “East region facility.”

El pipeline recoge los archivos de metadatos, genera incrustaciones vectoriales con Amazon Titan Text Embeddings y los indexa en Amazon Bedrock Knowledge Bases. Una vez indexados, la tabla es descubrible por todos los agentes conectados sin reindexación manual ni reinicios del servidor.

Para mejorar la precisión en aplicaciones específicas, un ingeniero puede opcionalmente asociar el conjunto de datos con un contexto de negocio. Esto reduce el alcance de la búsqueda, de modo que el agente prioriza las tablas correctas. El siguiente ejemplo muestra una entrada de mapeo de contexto:

{
  "delivery_metrics": {
    "description": "Delivery accuracy and defect attribution data",
    "tables": ["analytics_db.customer_orders_summary"],
    "sources": {"wiki": [], "quip": []}
  }
}

Si no se especifica ningún contexto, el agente busca en todas las tablas indexadas. El mapeo de contexto reduce la latencia y mejora la precisión del SQL al limitar el espacio de búsqueda. Este acotamiento es opcional y puede añadirse en cualquier momento sin modificar los propios archivos de metadatos.

Uniéndolo todo: una consulta en acción

Cuando un usuario pregunta: “¿Cuáles fueron nuestros 10 pedidos de mayor valor el mes pasado?”, el cliente enriquece la solicitud con contexto de negocio para reducir el alcance. El agente convierte la pregunta en una incrustación vectorial, busca en el catálogo de metadatos los esquemas coincidentes y selecciona la tabla más relevante mediante una llamada ligera a un LLM.

Usando el esquema seleccionado, las descripciones de columnas y las pistas de consulta específicas del motor, el agente genera una instrucción SQL como la siguiente:

SELECT order_id, customer_id, total_amount, order_date
FROM analytics_db.regional_order_summary
WHERE order_date >= date_add('month', -1, current_date)
ORDER BY total_amount DESC
LIMIT 10

El SQL se valida y se autocorrige para compatibilidad con el motor, y luego se ejecuta contra Amazon Athena. El agente formatea los resultados en una respuesta en lenguaje natural y la transmite de vuelta al usuario. En nuestras pruebas, este flujo de extremo a extremo se completa en 15–20 segundos.

La misma orquestación se extiende más allá del SQL puro. Debido a que la búsqueda de documentos está registrada como otra herramienta en el mismo servidor, el agente puede responder preguntas que abarcan fuentes estructuradas y no estructuradas en un solo turno, como “¿Cuál fue nuestra tasa de devoluciones en el Q4 y qué dice el análisis del equipo de producto sobre las causas raíz?”. Para esa solicitud, el agente ejecuta una consulta de Athena para la cifra de tasa de devoluciones y una búsqueda de documentos de Knowledge Bases para el análisis, y luego combina ambas en una sola respuesta.

Seguridad y acceso multiinquilino

Esa orquestación en un solo turno funciona solo porque cada llamada a herramientas pasa por la misma puerta de enlace controlada. La arquitectura usa seguridad en capas en lugar de un único punto de aplicación. El servidor MCP se ejecuta en subredes privadas detrás de un Application Load Balancer interno y no es accesible desde internet. Solo la capa de cliente, que se sitúa detrás de un Application Load Balancer orientado al público con AWS WAF, puede enrutar solicitudes hacia él. Amazon Cognito valida la identidad del usuario en la capa de cliente, y solo las solicitudes autenticadas y con token se reenvían aguas abajo. A nivel de herramientas, las herramientas de consulta de Athena imponen consultas SELECT-only, rechazando las operaciones de escritura antes de que lleguen al data lake. Todas las invocaciones de herramientas se registran en Amazon CloudWatch con JSON estructurado, lo que brinda a los equipos de seguridad un único punto de auditoría para el acceso a datos a través de cada agente y aplicación. Esta arquitectura está disponible en las Regiones de AWS donde están disponibles Amazon Bedrock y Amazon Bedrock Knowledge Bases.

Este diseño centralizado también es lo que hace que el servidor sea multiinquilino. Debido a que el endpoint estandarizado /mcp acepta cualquier cliente compatible con MCP sin importar qué LLM o framework de orquestación use, varios agentes comparten las mismas herramientas y los mismos controles de acceso. Agregar un nuevo agente requiere solo apuntarlo al endpoint del servidor, por lo que incorporar otro equipo extiende el sistema sin debilitar ni duplicar el modelo de seguridad.

Infraestructura serverless y escalamiento

Cada capa escala mediante un mecanismo adecuado a su patrón de carga de trabajo:

Amazon ECS Fargate proporciona cómputo serverless sin instancias EC2 que administrar. Los servicios aguas abajo (Athena, Bedrock) escalan automáticamente, por lo que el sistema maneja una sola consulta o cientos de consultas concurrentes sin cambios de configuración.

Casos de uso y extensiones

Esta arquitectura admite varios patrones más allá de la respuesta básica a preguntas. Los asistentes de conocimiento empresarial pueden combinar consultas del data lake con búsqueda de documentos para responder preguntas complejas que abarcan tanto datos estructurados como conocimiento no estructurado, como “¿Cuál es nuestra tasa de devoluciones en el Q4 y qué dice el análisis del equipo de producto sobre las causas raíz?”. Los copilotos de análisis internos permiten a los usuarios de negocio consultar el data lake de forma conversacional sin escribir SQL, apoyándose en las descripciones de metadatos y las pistas de consulta para guiar al agente hacia patrones de consulta precisos y eficientes.

El endpoint estandarizado /mcp también admite flujos de trabajo multiagente. Múltiples agentes especializados en análisis de datos, recuperación de documentos y alertamiento operativo pueden compartir el mismo servidor MCP, accediendo cada uno al conjunto completo de herramientas a través de un protocolo común. Incorporar los datos de un nuevo equipo sigue el mismo patrón basado en configuración. Agregan un archivo JSON de metadatos y, dentro de un ciclo de sincronización de pipeline, su conjunto de datos es descubrible por cada agente y aplicación conectados.

Conclusión

Un servidor MCP centralizado en Amazon ECS Fargate proporciona una puerta de enlace escalable y segura entre los agentes de IA y los lagos de datos empresariales. El enfoque basado en metadatos elimina la necesidad de código de integración por cada conjunto de datos, y el estándar Model Context Protocol significa que cualquier cliente compatible con MCP puede conectarse sin adaptadores personalizados.

La decisión arquitectónica clave es separar la capa de herramientas de la capa de agentes. Los agentes evolucionan rápidamente, pero los patrones de acceso a los datos deberían sobrevivir a cualquier implementación individual de agente. Tratar la extensibilidad como un problema de configuración en lugar de un problema de código acelera la incorporación.

Para obtener más información, consulte Amazon ECS on AWS Fargate, Amazon Bedrock, la Amazon Bedrock Knowledge Bases guía del usuario, Amazon Athena, y la Model Context Protocol specification.

Próximos pasos

Estamos extendiendo esta arquitectura en dos direcciones. Primera, control de acceso de grano más fino donde los propietarios de tablas pueden marcar columnas sensibles como restringidas por grupo de permisos, y el agente excluye automáticamente esas columnas del SQL generado sin cambios a nivel de prompt.

Segunda, cerrar el ciclo de retroalimentación de modo que cuando las consultas fallen o produzcan resultados de baja confianza, el sistema capture el patrón de fallo y muestre sugerencias específicas para mejorar las descripciones de columnas, añadiendo pistas de consulta.

Sobre los autores