Escopo do projeto
O projeto coloca o Kiro (IDE ou CLI) na rotina de quem opera, conectado à conta AWS da empresa por quatro servidores MCP: o AWS MCP Server (gerenciado pela AWS, disponível desde maio de 2026, para qualquer API AWS e documentação, em modo somente leitura), o Amazon EKS MCP Server (somente leitura por padrão), o Amazon CloudWatch MCP Server (métricas, alarmes e logs) e o AWS Billing and Cost Management MCP Server (custos, anomalias e previsão). Tudo com um perfil IAM dedicado só de leitura, com a credencial de administrador fora do notebook, e com as chamadas registradas no AWS CloudTrail.
O escopo inclui a criação do perfil e do acesso de leitura ao Kubernetes, a configuração do mcp.json do workspace, o steering do Kiro com as regras da empresa (responder em português, omitir IDs de conta, ARNs, IPs e e-mails, propor só leitura), as dez perguntas da semana da equipe, a medição, a política "a IA lê e recomenda; a mudança passa por pessoa, processo e registro" e o treinamento de meio dia. Modo de escrita, automação de mudanças e agentes autônomos na operação ficam para uma avaliação posterior (ver frontier agents).
Desafio e problemas de hoje
- Para responder "por que esse pod está caindo" a pessoa abre cinco consoles: EKS, CloudWatch, EC2, Cost Explorer e o monitoramento.
- Revisão de boas práticas (requests e limits, imagem latest, contêiner como root, serviço exposto) fica para depois e nunca acontece.
- Previsão de custo do mês só na fatura; anomalia descoberta tarde.
- Conhecimento concentrado numa pessoa; quando ela sai de férias, ninguém sabe onde olhar.
- Medo justificado de dar a uma IA acesso que possa mudar o ambiente.
- Plugins do Amazon Q Developer para IDE encerram em 30/04/2027; a AWS aponta o Kiro.
O ambiente de partida (perfil típico deste exemplo)
| Item | O que costuma existir |
|---|---|
| Conta AWS | De 1 a 5 contas; IAM Identity Center em algumas; CloudTrail ativo em parte |
| Kubernetes | Um cluster Amazon EKS com 5 a 40 serviços, ou ECS, ou só EC2 |
| Servidores | De 5 a 60 instâncias Amazon EC2; SSM Agent em parte; Inventory raramente ativo |
| Monitoramento | Amazon CloudWatch com alarmes básicos; Zabbix ou Grafana em paralelo |
| Custos | Cost Explorer aberto no fechamento; sem anomalia configurada; sem Budgets |
| Equipe | 1 a 3 pessoas de operação, muitas vezes também desenvolvedores |
| Ferramentas de IA | Uso pessoal, sem acesso à conta; ou nenhum |
| Restrições | Dados de clientes em logs de alguns namespaces; mudança só por janela; auditoria |
Perfil típico, com faixas, construído a partir de projetos desse tipo. O inventário real é o primeiro entregável da descoberta.
Requisitos
- R1A IA só lê: permissão de escrita fora do IAM e fora de qualquer flag de servidor.
- R2Perguntas em português sobre Kubernetes, servidores, monitoramento e custos, com evidência (métrica, evento, log, valor) na resposta.
- R3Toda chamada registrada no AWS CloudTrail e atribuível ao perfil da IA.
- R4IDs de conta, ARNs completos, IPs, e-mails e segredos fora das respostas e dos prompts; logs de namespaces com dado de cliente fora do alcance.
- R5Configuração por workspace, separada do uso pessoal; modelo fixo nos primeiros ciclos.
- R6Regra escrita: a IA recomenda, a mudança passa por pessoa, processo e registro.
O que desenhamos para cada requisito
| Requisito | Decisão de arquitetura | Serviço AWS |
|---|---|---|
| R1 | Papel IAM dedicado com a política gerenciada ReadOnlyAccess; no EKS, access entry com AmazonEKSViewPolicy (lê recursos e deixa Secrets de fora); AWS MCP Server acessado pelo mcp-proxy-for-aws com --read-only; EKS MCP Server no padrão somente leitura, sem --allow-write | AWS Identity and Access Management (IAM), Amazon EKS (access entries), AWS MCP Server, Amazon EKS MCP Server |
| R2 | Quatro servidores no mcp.json do workspace: AWS MCP Server (qualquer API, documentação, scripts em sandbox), EKS (recursos, eventos, logs, guia de troubleshooting), CloudWatch (métricas, alarmes, Logs Insights, recomendações de alarme), Billing and Cost Management (Cost Explorer, anomalias, previsão, Compute Optimizer) | Kiro (MCP), Amazon CloudWatch MCP Server, AWS Billing and Cost Management MCP Server |
| R3 | O AWS MCP Server registra as chamadas no CloudTrail; os servidores locais chamam as APIs AWS com a credencial do perfil, que o CloudTrail registra como qualquer chamada; conferência no histórico de eventos no primeiro dia | AWS CloudTrail |
| R4 | Steering do workspace (.kiro/steering/operacao.md): responder em português, omitir identificadores, propor só leitura; --allow-sensitive-data-access do EKS só em namespaces sem dado de cliente, decididos antes; dado sensível fora do prompt | Kiro (steering), Amazon EKS MCP Server |
| R5 | mcp.json em .kiro/settings/ do workspace de operação, com perfil AWS nomeado; nada no ~/.kiro pessoal; modelo fixado (em vez de "Auto") nas duas primeiras semanas | Kiro |
| R6 | Política de uma página assinada pela equipe; sugestões de mudança viram ticket ou PR com revisão; comando de escrita no Kiro fica bloqueado, e qualquer mudança passa por pessoa, processo e registro | Processo RFX |
Arquitetura
Componentes e fluxos deste diagrama
- Equipe de operação
- Kiro (IDE e CLI, steering do workspace)
- Servidores MCP locais (Amazon EKS MCP Server, Amazon CloudWatch MCP Server, AWS Billing and Cost Management MCP Server)
- AWS MCP Server (gerenciado pela AWS, somente leitura)
- AWS IAM (papel dedicado somente leitura)
- Amazon EKS (visualização de recursos, eventos e logs em namespaces autorizados)
- Amazon EC2 (instâncias e inventário do AWS Systems Manager)
- Amazon CloudWatch (métricas, alarmes, logs)
- AWS Cost Explorer (custos, anomalias, previsão)
- AWS CloudTrail (registro de cada chamada)
- Fluxos: perguntas em português; MCP para os servidores locais e para o AWS MCP Server; credencial de leitura; consultas somente leitura; registro.
Ganhos: o que medimos no projeto
| Indicador | Como medimos | O que muda |
|---|---|---|
| Tempo para responder as dez perguntas da semana | Cronometrado antes (consoles) e depois (Kiro), pela própria equipe | Cinco consoles viram uma pergunta |
| Achados de boas práticas por namespace e por servidor | Lista produzida na primeira revisão e acompanhada por sprint | Revisão que nunca acontecia passa a ter lista |
| Alarmes recomendados e implementados | Recomendações do servidor de CloudWatch aceitas pela equipe (via PR ou ticket) | Monitoramento cresce por evidência |
| Anomalias e variações de custo vistas antes da fatura | Perguntas semanais de custo registradas, com data da detecção | Surpresa de fatura vira item de reunião semanal |
| Chamadas de escrita tentadas e bloqueadas | AWS CloudTrail (erros de acesso negado do perfil) | Prova de que o controle é o IAM, e não o prompt |
| Pessoas da equipe capazes de responder as dez perguntas | Antes e depois, por pessoa | Conhecimento sai de uma cabeça só |
Indicadores que a RFX mede na PoC e em produção. Os valores são da sua empresa; resultados de clientes ficam sob confidencialidade.
Escopo e entregáveis por fase
| Fase | O que acontece | Entregáveis | Duração |
|---|---|---|---|
| Semana 1: acesso e configuração | Papel IAM somente leitura; access entry de leitura no EKS; escolha dos namespaces sem dado de cliente; mcp.json do workspace com os quatro servidores; steering; modelo fixo; conferência no CloudTrail; critério de sucesso escrito (ex.: "as dez perguntas da semana respondidas com evidência em menos tempo que pelos consoles, zero chamadas de escrita, em 2 semanas") | Perfil e acesso; workspace configurado; critério assinado | 1 semana |
| Semana 2: as dez perguntas e a política (PoC com critério de sucesso escrito) | Troubleshooting de pods; revisão de boas práticas de um namespace; capacidade dos nós se o tráfego dobrar; instância com mais CPU e o que roda nela; alarmes ativos; custo do mês, variação e previsão; medição; política de uma página; treinamento de meio dia | Relatório das dez perguntas; lista de achados; política; guia de uso; transferência à equipe | 1 semana |
| Depois (opcional, com OK) | Spec no Kiro para transformar um achado em entrega (ex.: alarme de CPU em Terraform, sem apply automático); avaliação do AWS DevOps Agent (disponibilidade geral) e do AWS FinOps Agent (em preview em 06/10/2026) (ver frontier agents) quando fizer sentido | Spec revisada; avaliação com critério | A combinar |
Durações típicas, em faixa. O plano do projeto fixa as datas reais.
Algo a mais: o relatório de segunda-feira
Um hook do Kiro gera toda segunda-feira o relatório das dez perguntas (pods, boas práticas, capacidade, alarmes, custo e previsão) e abre como rascunho de PR na pasta de operação, para a equipe revisar na reunião semanal. Para quem usa Grafana, há servidor MCP oficial da Grafana Labs com modo somente leitura; para Zabbix, os servidores MCP disponíveis em 06/10/2026 são mantidos por parceiros e pela comunidade, e a RFX avalia caso a caso.
Cuidados: LGPD, região e revisão humana
- O IAM é o controle real: o servidor MCP usa as credenciais do perfil, então a permissão da IA é a permissão do perfil. Credencial de administrador fora do notebook.
- Ler logs e eventos no Amazon EKS MCP Server exige uma opção explícita de acesso a dado sensível; use só em namespaces sem dado de cliente, decididos antes.
- Dado sensível fora do prompt; o steering omite IDs de conta, ARNs, IPs e e-mails nas respostas.
- Modo de escrita fica fora no início; se a IA sugerir um comando de mudança, a aprovação passa pelo processo.
- O Amazon EKS MCP Server gerenciado pela AWS está em preview em 06/10/2026; o exemplo usa o servidor open source local, que roda em modo somente leitura por padrão.
- O AWS API MCP Server antigo foi substituído pelo AWS MCP Server; rode só um deles. O AWS MCP Server gerenciado é hospedado em US East (N. Virgínia) e Europe (Frankfurt) em 06/10/2026: ele consulta APIs de qualquer região, inclusive São Paulo, mas perguntas, respostas e scripts passam por lá; registre isso no tratamento de dados.
- Leia os termos do plano do Kiro escolhido sobre uso de dados; há plano gratuito em 06/10/2026.
Perguntas frequentes deste exemplo
Por desenho, ela só lê: o perfil IAM é só de leitura, o acesso ao AWS MCP Server passa pelo mcp-proxy-for-aws com --read-only (filtro de ferramentas no cliente; o limite real é o IAM) e o servidor do EKS tem a opção de escrita desligada. Se ela sugerir um comando de mudança, a mudança vira ticket ou PR com revisão.
O Kubernetes é opcional. Com EC2, CloudWatch e custos já há valor; o servidor do EKS entra se houver cluster.
Ele complementa: é uma camada de perguntas por cima do que já existe. Para Grafana há servidor MCP oficial com modo somente leitura; para Zabbix, os servidores MCP disponíveis em 06/10/2026 são mantidos por parceiros e pela comunidade, e a RFX avalia caso a caso.
Revisão, análise, troubleshooting e previsão em Kubernetes, VMs, firewalls e monitoramento, sempre em leitura. Foi a demo do Bloco 2, no cluster da RFX.
Encerram em 30/04/2027; a AWS indica a migração para o Kiro.
Serviços AWS deste exemplo
- Kiro
- AWS MCP Server
- Amazon EKS MCP Server
- Amazon CloudWatch MCP Server
- AWS Billing and Cost Management MCP Server
- AWS Identity and Access Management (IAM)
- Amazon EKS
- Amazon EC2
- AWS Systems Manager
- Amazon CloudWatch
- AWS Cost Explorer
- AWS CloudTrail
Incentivos AWS
A RFX busca para o projeto os programas de incentivo, créditos e verbas de PoC da AWS e da distribuição aplicáveis, sempre sujeitos a aprovação da AWS e da distribuição.