Desarrollar un Copilot SRE autónomo para AWS con MCP, Bedrock Nova y aprobación humana.
Crear un agente SRE para la investigación de incidentes: un servidor MCP que exponga herramientas de CloudWatch y DynamoDB, un bucle de conversación Bedrock, portabilidad del modelo y una verificación humana en cada solución.
Fuentes: Building an Autonomous AWS SRE Copilot: Giving LLMs “Hands and Eyes” in the Cloud with MCP
Durante aproximadamente un año, la industria se ha centrado en ChatOps: integrar modelos de lenguaje grande en Slack o Telegram como capas adicionales alrededor de los pipelines CI/CD. Sin embargo, los chatbots son solo la parte visible. El verdadero valor empresarial proviene del paso de chatbots reactivos a agentes autónomos. Un copiloto autónomo para ingeniería de fiabilidad de sitios (SRE) desarrollado con Amazon Bedrock (Nova), el Model Context Protocol (MCP) y AWS muestra cómo podría ser esto. No solo activa los pipelines; también analiza por sí mismo los incidentes en producción en tiempo real, obtiene métricas y registros, identifica las causas raíz y aplica soluciones, todo dentro de un entorno seguro con la participación de un humano.
La opción gestionada: AWS DevOps Agent
Antes de crear algo personalizado, un arquitecto debería preguntarse si AWS ya ofrece esta funcionalidad. De hecho, la ofrece, aunque de forma limitada. AWS lanzó el DevOps Agent en re:Invent 2025, en versión de prueba a partir de diciembre de 2025 y con disponibilidad general a partir de marzo de 2026. Se trata de un sistema multiagente avanzado diseñado para la respuesta autónoma a incidentes en AWS.
Supera con creces herramientas anteriores como DevOps Guru:
- Respuesta autónoma a incidentes. Una alarma activada en CloudWatch inicia una investigación que correlaciona datos telemétricos, registros, trazas, cambios en el código y el historial de despliegues para identificar la causa raíz y elaborar planes de mitigación.
- Prevención proactiva. Analiza patrones históricos de incidentes y sugiere mejoras en la capacidad de observabilidad, la infraestructura y los flujos de trabajo.
En teoría, cubre todo lo que un equipo SRE podría necesitar.
¿Por qué crear uno personalizado?
El problema es el acceso. El DevOps Agent viene incluido con los planes de soporte de AWS en los niveles Business+ y Enterprise, y no está disponible para el público en general bajo demanda. Una organización con soporte de nivel Developer, una startup, un equipo independiente o un consultor que trabaja en la cuenta de un cliente sin soporte Enterprise simplemente no puede utilizarlo.
El servicio gestionado es adecuado para equipos que ya cuentan con Soporte Enterprise y trabajan según los patrones estándar de AWS, ya que AWS se encarga de la mayor parte del trabajo y las integraciones son amplias. Sin embargo, para un arquitecto de IA, la pregunta más interesante es si dicho patrón se comprende lo suficientemente bien como para poder desarrollarlo de forma independiente y ampliarlo donde termina el producto gestionado. Eso es lo que muestra este proyecto.
El problema principal: herramientas a gran escala
Herramientas como Amazon Nova comprenden los sistemas distribuidos, las arquitecturas de AWS y la depuración compleja. Sin embargo, por defecto siguen siendo como “cerebros en un frasco”: no pueden ver las métricas de CloudWatch ni acceder a las tablas de DynamoDB.
Utilizar una LLM sin herramientas adecuadas solía significar recurrir a código personalizado frágil:
- Definir un esquema JSON para la herramienta.
- Escribir una función en Python que la ejecute.
- Incluir de forma fija las credenciales de AWS en el entorno de ejecución del agente.
Eso vincula estrechamente al agente a la infraestructura, lo que genera problemas de seguridad y cuellos de botella en el mantenimiento.
Llega MCP
El Model Context Protocol, introducido por Anthropic y que rápidamente se está convirtiendo en un estándar de la industria, resuelve esto de manera eficaz. Se trata de un protocolo estandarizado, algo similar a USB-C para la IA, que conecta los modelos con fuentes de datos y herramientas externas. En lugar de codificar directamente las herramientas de AWS en el agente, se crea un servidor MCP separado. Este reside dentro del entorno de AWS con los roles IAM necesarios y expone herramientas semánticas de tipo estricto a través del protocolo estándar. El agente, que puede ejecutarse en cualquier lugar, se conecta como cliente MCP. No necesita credenciales de AWS, ya que simplemente solicita al servidor que ejecute las herramientas por él.
Liberdad para elegir el modelo
Dado que a MCP no le importa qué modelo haya al otro lado, el orquestador de agentes SRE puede utilizar cualquiera que sea adecuado:
Amazon Nova ─┐
Claude 3.5 ─┼──→ SRE Agent Orchestrator ──→ MCP Server ──→ AWS Cloud
OpenAI GPT-4o─┘ (agent.py) (server.py)
Evaluar un modelo de otro proveedor implica modificar una línea de código. El servidor MCP y todas las herramientas seguras de AWS que expone permanecen exactamente igual.
Arquitectura del copiloto SRE
1. La infraestructura objetivo
Para que el agente tenga algo que reparar, se despliega un microservicio serverless estándar con Terraform: API Gateway delante de una función Lambda que escribe en una tabla DynamoDB. El defecto intencionado consiste en una tabla con capacidad reducida, provista únicamente con 1 unidad de capacidad de lectura y 1 unidad de capacidad de escritura. Bajo cualquier carga real, esta API genera errores ProvisionedThroughputExceededException.
2. El servidor MCP
Un servidor Python FastMCP actúa como intermediario, exponiendo cuatro capacidades de SRE:
describe_architecturelocaliza todos los recursos de AWS (ARNs) que llevan una etiqueta de aplicación.
query_cloudwatch_metrics obtiene datos de series temporales como ThrottledRequests.query_cloudwatch_logs ejecuta consultas de CloudWatch Logs Insights para localizar rastros de ejecución.remediate_dynamodb_capacity es una herramienta mutante que aumenta la capacidad de la tabla.El límite de confianza es el punto donde interviene el humano. Las herramientas de solo lectura son completamente autónomas, por lo que el modelo puede utilizarlas tanto como desee para investigar. Sin embargo, la herramienta de remediación impone un estricto control humano: antes de llamar a la API de AWS, se detiene y solicita al operador en la terminal una aprobación mediante [y/N], mostrando al mismo tiempo la justificación del modelo. Contar con un punto de control auditable en cada acción que modifica el estado, definido según las reglas propias de la organización, es algo que DevOps Guru y Amazon Q no ofrecen.
3. El agente autónomo
El agente es un pequeño script en Python que se comunica con la API Amazon Bedrock Converse a través de boto3, habiéndose elegido la familia de modelos Amazon Nova por sus capacidades y bajo costo. Ejecuta un bucle while autónomo:
- Recibe una instrucción como “Los usuarios informan que la API de pagos está tiempos de espera excesivos. Arreglélo.”
- Pregunta al servidor MCP qué herramientas están disponibles.
- Convierte los esquemas de las herramientas MCP directamente al formato Bedrock Converse.
- Comienza a razonar: busca los recursos de la API de pagos, verifica sus métricas y luego lee los registros.
- Llama a las herramientas a través de MCP, envía los resultados de vuelta a Bedrock y continúa hasta encontrar una solución y activar la herramienta de corrección.
El bucle en acción
Al dirigirse a la tabla de DynamoDB con límites de acceso y pedirle que averigüe por qué la API de demostración devuelve respuestas 429 y 500, el agente sigue estos pasos:
- Llama a
describe_architecturepara encontrar los ARN de la tabla Lambda y DynamoDB. - Llama a
query_cloudwatch_metricsen la tabla, examinaProvisionedThroughputExceededRequestsy detecta un aumento enorme. - Para estar seguro, llama a
query_cloudwatch_logsen la función Lambda, analiza los registros JSON y confirma unaProvisionedThroughputExceededException. - Concluye que la capacidad es insuficiente y llama a
remediate_dynamodb_capacity, solicitando 50 RCU y 50 WCU.
Aquí el servidor MCP intercepta la llamada y le pide al usuario humano que actúe:
=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y
Ese mismo agente también funciona como una aplicación de chat de Streamlit, mostrando la solución propuesta y el paso de aprobación. Una vez que una persona lo aprueba, se actualiza la capacidad y el incidente se resuelve.
Qué ofrece esta arquitectura
Al separar el “cerebro” (Amazon Nova a través de Bedrock) de las “manos” (APIs de AWS) mediante MCP se obtiene una flexibilidad que las herramientas gestionadas por AWS no pueden igualar:
- Portabilidad de los LLM. Cambiar Nova por Claude o GPT-4o solo requiere un cambio de configuración.
- Seguridad. Las credenciales en bruto nunca llegan al entorno de ejecución del LLM.
- Seguridad adicional. Las acciones modificadas pasan por un paso de aprobación humano personalizable.
- Extensibilidad. Incluir una nueva herramienta, ya sea PagerDuty, una consulta a la API de Datadog o una verificación de ticket en ServiceNow, se logra con una sola función
@mcp.tool().
Parece que las operaciones en la nube se alejarán de los servicios gestionados monolíticos que limitan a los equipos, hacia agentes componibles, agnósticos al modelo y auditables que los equipos pueden crear, gestionar y seguir mejorando. Se trata de un modelo listo para su implementación en producción, no solo de una demostración.
Para referencia, la especificación MCP se publica en modelcontextprotocol.io, y AWS Labs mantiene servidores MCP de código abierto como referencia.
Lecturas relacionadas
- Mapeando el ecosistema de IA de Laravel: Prism, LarAgent, Neuron AI y Boost — De simples llamadas a LLM a agentes completos en Laravel: qué hacen Prism, LarAgent, Neuron AI, el SDK de IA y Boost, con un ejemplo de RAG para preguntas sobre políticas de recursos humanos.
- Un agente financiero de QuickBooks que funciona con un LLM local usando Ollama y LangChain — Un agente ReAct en Qwen 3.5 9B y una RTX 4070 lee datos en tiempo real de QuickBooks sin ningún costo relacionado con la nube. Consulte el código, los resultados y las limitaciones conocidas.