AWS lança MCP personalizado para diagnóstico autônomo de nós EKS com DevOps Agent

O novo servidor MCP personalizado para EKS não é só mais uma integração, é a primeira vez que o DevOps Agent consegue atravessar a camada de abstração do Kubernetes e acessar dados de nível de sistema operacional em nós EC2 com granularidade, segurança e auditabilidade. Ele usa o AWS Systems Manager Automation como canal de execução, invocando runbooks como AWSSupport-TroubleshootEKSWorkerNode e estendendo-os com leitura estruturada de iptables, sysctl, journalctl -u kubelet, configurações de CNI (Cilium e Amazon VPC CNI) e até logs de kernel via dmesg. Isso resolve uma lacuna crítica: antes, o agente só enxergava métricas e eventos do plano de controle (como eventos de pod ou logs do API Server), mas não conseguia correlacionar falhas de rede ou DNS com regras de firewall no nó, exatamente o que aconteceu no caso de referência com a falha de DNS induzida.

A arquitetura evita SSH por design: tudo roda dentro do sandbox do Systems Manager, com IAM roles específicas, logs de execução no CloudWatch e rastreamento de alterações no AWS Config. O agente não executa código arbitrário, ele chama funções pré-aprovadas, com contexto de namespace, node label e tempo de vida do diagnóstico. Isso é diferente da abordagem genérica do MCP Server GA, que foca em APIs da AWS, não em diagnóstico de infraestrutura de baixo nível.

Em 24 de abril, o DevOps Agent usava o MCP Server do Salesforce para investigar incidentes de suporte ao cliente, um fluxo orientado a casos, não a infraestrutura. Em 15 de maio, ele já fazia SRE autônomo com telemetria de CloudWatch e Splunk, mas ainda dependia de métricas agregadas. Agora, com o MCP personalizado para EKS, o agente opera diretamente no nó: lê regras de iptables, compara estado de CNI entre nós saudáveis e afetados, e valida configurações de resolv.conf, tudo sem intervenção humana nem acesso SSH. É a primeira vez que ele atua como um 'SRE embarcado' no worker node, não apenas como um analista remoto.

Isso reduz o MTTR de falhas de rede e DNS em clusters EKS de horas para minutos, e elimina o risco de erros humanos em diagnósticos manuais. Equipes não precisam mais rodar kubectl debug, ec2-instance-connect ou scripts ad hoc para inspecionar nós. A automação é reproduzível, versionável (via Runbook no SSM) e auditable. Para quem opera clusters em escala, isso significa menos tempo gasto em 'firefighting' e mais capacidade de investir em melhorias proativas de confiabilidade, como testes de falha de CNI ou simulações de perda de pacotes com Chaos Engineering integrado ao mesmo pipeline.