O blog da AWS
Inter&Co automatiza operações com o Kiro: da gestão de 200+ servidores à resolução de crises em minutos
Por Gustavo Fernandes Batista, Database Administrator no Inter&Co; Murillo da Costa Tavares, Senior Technical Account Manager na AWS e Willer Púlis, Senior Solutions Architect na AWS.
Introdução
No Inter, a gestão de centenas de servidores e recursos AWS acontece através de Infrastructure as Code (Terraform), com todo o código versionado no GitLab. As equipes de administradores de bancos de dados (DBAs) e infraestrutura (SREs) enfrentavam desafios recorrentes: alterações em massa em múltiplos repositórios, análise de políticas do AWS Identity and Access Management (IAM) complexas, consultas sob demanda, não estruturadas, feitas pelos usuários em metadados de recursos AWS e, principalmente, a pressão de resolver problemas de performance em produção com velocidade. Este post compartilha como automações inteligentes usando o Kiro CLI foram implementadas, as quais reduziram o tempo de operações que levariam dias ou horas para tarefas de minutos, mantendo governança e rastreabilidade através de Merge Requests (processo onde uma alteração de código é revisada e aprovada por outro membro do time antes de ser aplicada).
Sobre o Inter
A Inter&Co, empresa que controla o Banco Inter no Brasil e a subsidiária Inter&Co Payments, desenvolveu o Super App financeiro global que atende 40 milhões de clientes nas Américas. O ecossistema do Inter oferece uma ampla gama de serviços, incluindo serviços bancários, investimentos, financiamento imobiliário, crédito, seguros e pagamentos internacionais. O Super App também conta com um marketplace dinâmico, conectando os consumidores a descontos em compras, recompensas em cashback e acesso exclusivo a eventos importantes em todo o mundo. Focada em inovação e experiências cativantes para os membros, a Inter&Co oferece soluções financeiras e de estilo de vida abrangentes para atender às necessidades em constante evolução dos consumidores modernos.
Os desafios: escala e velocidade em operações AWS
1. Alterações em massa via Terraform: O ambiente é composto por mais de 200 blueprints Terraform gerenciando diversos serviços AWS como Amazon EC2 e Amazon RDS. Neste contexto, tarefas aparentemente simples se tornavam projetos complexos, como habilitar tags específicas em dezenas de servidores, adicionar ou remover IPs em security groups de múltiplos ambientes, auditar configurações ausentes em toda a infraestrutura, ou criar dezenas de IAM roles seguindo um padrão específico. Fazer essas alterações manualmente significava clonar mais de 200 repositórios, editar arquivos Terraform individualmente, criar Merge Requests um por um, além de enfrentar um risco alto de inconsistências e erros humanos.
2. Análise de metadados AWS: Frequentemente eram recebidas solicitações que exigiam correlacionar dados de múltiplas contas e regiões AWS, como “Liste os servidores EC2 com SQL Server e seus responsáveis”, “Quais recursos estão em qual conta e região?” ou “Identifique aplicações por tags específicas”. Essas consultas envolviam navegar pela console AWS, exportar dados manualmente e consolidar informações em planilhas, um processo que consumia dias de trabalho.
3. Resolução de crises de performance: Em situações críticas de produção, cada minuto conta. Quando um banco de dados apresenta degradação de performance, precisamos analisar métricas de CloudWatch rapidamente, identificar queries problemáticas nos logs, correlacionar eventos e encontrar a causa raiz, além de propor soluções imediatas. O processo tradicional de análise manual de logs e métricas consumia tempo precioso durante incidents.
A solução: automação inteligente com Kiro
O Kiro CLI é uma ferramenta que permite interagir com agentes de inteligência artificial capazes de trabalhar com código, APIs, bancos de dados e serviços AWS. Usando o Kiro CLI, criamos três automações principais que transformaram nossas operações de TI. Para tarefas simples como correção de bugs, o Kiro acelera a iteração para que você foque no que realmente importa. Para features complexas, ele ajuda a entender a base de código, definir o problema e chegar a uma solução de qualidade. Você pode fornecer contexto sobre requisitos, arquitetura de sistema e stack tecnológica, e o Kiro usa essas informações para completar tarefas com maior eficiência. A ferramenta mantém você no controle das decisões de arquitetura, para que você valide a lógica das soluções propostas e debata trade-offs antes da implementação. O Kiro implementa soluções usando agentes de IA, mantendo você no comando em cada etapa do processo.
Automação 1: Merge Requests (MRs) em massa para Terraform
A otimização no processo de Merge Requests em massa para blueprints de terraform segue os seguintes passos:
- Acesso aos repositórios: configuram-se SSH keys para o Kiro acessar os repositórios GitLab.
- Contexto e instrução: o Kiro recebe o padrão desejado e a lista de repositórios alvo.
- Execução automatizada: o Kiro clona cada repositório, faz as alterações necessárias e cria MRs individuais.
- Revisão humana: todos os MRs ficam disponíveis para revisão e aprovação da equipe.
Caso de uso real: criação de 140 IAM roles
Para um projeto interno, era necessário criar 140 roles AWS IAM seguindo um template específico, tendo como única variável o nome de cada role.
Template:
resource "aws_iam_role" "exemplo_role" {
name = "projeto-interno-{NOME_SERVICO}"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ec2.amazonaws.com"
}
}]
})
tags = {
Project = "ProjetoInterno"
ManagedBy = "Terraform"
}
}
Instrução ao Kiro:
"Crie uma IAM role para cada serviço na lista, seguindo este template. Crie um MR separado para cada role nos respectivos repositórios."
Como resultado, o processo criou 140 Merge Requests em menos de 10 minutos, cada um pronto para revisão individual, automatizando um processo que levaria de 8 a 10 horas se feito manualmente.
A imagem a seguir mostra a lista de Merge Requests criados automaticamente pelo Kiro no GitLab:
Figura 1. Lista de Merge Requests criados automaticamente pelo Kiro no GitLab.
Outros casos de uso: adicionar IPs específicos em security groups de mais de 50 servidores, habilitar tags de compliance em todos os recursos de produção e auditar e corrigir configurações de backup ausentes.
Automação 2: MCP especialista em metadados AWS
Arquitetura da solução
Para facilitar o inventariamento dos recursos, implementou-se um cluster Amazon DocumentDB (DocDB), o qual é populado diariamente com metadados das contas AWS através de scripts automatizados. Este banco contém informações consolidadas sobre:
- Instâncias Amazon EC2 (tipo, região, conta, tags).
- Bancos de dados Amazon RDS e Amazon DocumentDB.
- Recursos Amazon Lambda, Amazon S3 e outros serviços.
- Tags de ownership, aplicação e ambiente.
Solicitação recebida
"Preciso de uma lista completa de todos os servidores EC2 rodando Microsoft SQL Server, incluindo: responsável, conta AWS, região, aplicação e tags de compliance."
Integração com Kiro via MCP
Criamos um servidor MCP (Model Context Protocol) customizado que conecta o Kiro a esse DocumentDB, que habilita consultas em linguagem natural, de forma a democratizar a informação e criar uma interface amigável para que pessoas pudessem consultar a base de dados sem necessariamente ter conhecimento de construção de queries no DocDB.
{
"mcpServers": {
"aws-metadata": {
"command": "node",
"args": ["mcp-server-documentdb.js"],
"env": {
"DOCUMENTDB_CONNECTION_STRING": "mongodb://user:pass@docdb-cluster.region.docdb.amazonaws.com:27017"
}
}
}
}
Caso de uso real: inventário de servidores SQL Server (MSSQL)
Prompt ao Kiro:
"Consulte o banco de metadados AWS e gere um relatório de todos os servidores EC2 com tag 'Database=MSSQL'. Inclua: nome da instância, conta, região, responsável (tag Owner), aplicação (tag Application), ambiente (tag Environment) e status de compliance. Exporte em CSV e crie também uma visualização HTML."
Saída gerada:
InstanceId,AccountName,Region,InstanceType,Owner,Application,Environment,ComplianceStatus
i-instance_id_xpto,TAGVALUE0,sa-east-1,r6i.4xlarge,TAGVALUE1,TAGVALUE2,TAGVALUE3,TAGVALUE4
i-instance_id_xpto,TAGVALUE0,sa-east-1,m5a.large,TAGVALUE1,TAGVALUE2,TAGVALUE3,TAGVALUE4
...
O Kiro também gerou um HTML interativo com filtros e visualizações para análise imediata dos dados. A imagem a seguir mostra um exemplo de relatório HTML interativo gerado pelo Kiro mostrando inventário de todas as EC2 com MSSQL:
Figura 2. Tabela em HTML interativa gerada pelo Kiro mostrando inventário EC2 MSSQL.
Impacto: Consultas que levariam de 2 a 3 dias foram concluídas em segundos, com dados sempre atualizados através de sincronização diária e capacidade de fazer consultas complexas instantaneamente.
Automação 3: análise de performance e resolução de crises
O desafio
Durante incidentes de produção com degradação de performance em bancos de dados, é preciso um diagnóstico rápido. Analisar manualmente Amazon CloudWatch Logs, métricas de CPU/memória e identificar queries problemáticas consome tempo crítico.
A solução
Integrou-se o Kiro diretamente com a conta AWS, permitindo análise automatizada de performance em tempo real.
Caso de uso real: spike de CPU em RDS
Situação: alerta de “Database Load” extremo na instância RDS Oracle de produção. Aplicação reportando lentidão.
Ação imediata: vínculo do Kiro à conta AWS afetada.
Prompt:
"Analise a performance da instância RDS 'databaseXPTO' nas últimas 24 horas. Identifique queries problemáticas, gargalos e recomende otimizações."
Análise automatizada do Kiro:
???? SITUAÇÃO CRÍTICA IDENTIFICADA
Database Load Extremo:
- Pico: 1.429 (22:00) - 357% acima da capacidade
- Carga sustentada: 1.100-1.400 por 14 horas consecutivas
- Capacidade da instância: 4 vCPUs (db.m5.xlarge)
???? TOP QUERIES PROBLEMÁTICAS:
1. Query #1 - SELECT com ATRIBUTO_X
DB Load: 374.68
Wait Events:
- read by other session: 286.63 (76.5%)
- db file sequential read: 78.74 (21%)
Problema: Hint forçando índice pode não ser ideal
Solução: Remover hint e deixar otimizador escolher
2. Query #2 - SELECT com ATRIBUTO_Y
DB Load: 171.97
Wait Events:
- read by other session: 155.74 (90.5%)
???? PROBLEMAS CRÍTICOS IDENTIFICADOS:
1. Contenção Massiva de Blocos (read by other session)
- 700-1020 sessões esperando
- Indica hot blocks na tabela TABLE_1
2. Falta de Bind Variables
- 7 variações da mesma query com SQL_IDs diferentes
- Hard parsing excessivo
3. Hints Forçando Índices
- /*+ index(a ATRIBUTO_X) */
- Pode estar forçando planos subótimos
✅ RECOMENDAÇÕES IMEDIATAS:
1. Implementar Bind Variables (redução de 30-40% CPU)
2. Remover Hints de Índice (redução de 15-25% I/O)
3. Implementar Batch Commits (redução de 20-30% I/O)
4. Particionar Tabela (redução de 30-40% I/O)
5. Upgrade de Instância: db.m5.xlarge → db.m5.2xlarge
As imagens a seguir mostram artes do relatório detalhado de análise de performance gerado pelo Kiro para a instância RDS Oracle:
Figura 3. Início do relatório em HTML feito pelo Kiro.
Figura 4. Plano de ação sugerido pelo Kiro.
Figura 5. Métricas técnicas avaliadas e queries de diagnóstico sugeridas pelo Kiro.
Resolução: identificação da causa raiz em 2 minutos, implementamos bind variables nas top 3 queries, o uso de CPU foi reduzido em 35% em 1 hora e o upgrade de instância foi agendado para a próxima janela de manutenção.
Benefícios adicionais: além disso, a análise forneceu recomendações de otimização proativas, análise de custos com identificação de recursos oversized e documentação automática do incidente para post-mortem.
Caso de uso adicional: validação de políticas IAM
Processo tradicional: durante a implementação de um novo serviço, tomavam-se erros de permissão ao tentar acessar recursos S3. O processo tradicional envolvia ler mensagens de erro, consultar documentação IAM, testar permissões manualmente e iterar até encontrar a política correta.
Com Kiro, o código Terraform da IAM role é fornecido e o erro recebido:
Error: AccessDenied: User is not authorized to perform: s3:GetObjectVersion
Prompt:
"Analise esta IAM policy e identifique o que está faltando para resolver este erro de acesso."
Resposta do Kiro:
# Política atual (incompleta)
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*"
}
# Política corrigida
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion", # <- FALTANDO
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*"
}
Problema resolvido em minutos ao invés de horas de debugging.
Resultados e impacto
Métricas de eficiência
| Tarefa | Tempo Manual | Tempo com Kiro | Economia |
|---|---|---|---|
| Criar 140 IAM roles | 8-10 horas | 10 minutos | 98% |
| Alterações em 200 servidores | 2-3 dias | 30 minutos | 95% |
| Consulta de metadados AWS | 2-3 dias | Segundos | 99% |
| Análise de crise de performance | 1-2 horas | 2-5 minutos | 95% |
| Debug de políticas IAM | 1-3 horas | 5-10 minutos | 95% |
Benefícios qualitativos
A governança foi mantida com as alterações passando por Merge Requests e revisão humana, garantindo rastreabilidade através do histórico completo no GitLab das mudanças. A automação eliminou erros de digitação e inconsistências, reduzindo significativamente a ocorrência de falhas. O tempo de resposta melhorou drasticamente, com crises sendo resolvidas em minutos ao invés de horas, enquanto a capacidade analítica foi expandida, tornando triviais consultas complexas que antes eram inviáveis. Além disso, análises e recomendações passaram a ser automaticamente documentadas, criando um registro valioso para futuras referências.
Considerações de segurança e governança
Controle de acesso
A segurança foi implementada através de SSH keys (chaves criptográficas usadas para autenticar o acesso de forma segura, sem necessidade de senhas) com permissões limitadas apenas aos repositórios necessários, credenciais AWS seguindo o princípio de menor privilégio e acesso ao DocumentDB restrito por security groups e autenticação.
Auditoria
A auditoria completa é garantida através de todos os MRs registrados no GitLab com autor e timestamp, Amazon CloudTrail capturando as ações AWS realizadas e logs de consultas ao DocumentDB para rastreabilidade.
Revisão humana
O controle de qualidade é mantido através de um processo rigoroso onde nenhuma alteração vai para produção sem aprovação, os MRs seguem o mesmo processo de code review da equipe e as análises de IA são sempre validadas por especialistas.
Lições aprendidas
As lições aprendidas incluem começar com casos de uso claros, identificando dores reais antes de automatizar, manter a governança sem pular processos de segurança mesmo com automação, documentar padrões para que templates claros resultem em automações mais eficazes, integrar com ferramentas existentes como GitLab, AWS e DocumentDB aproveitando o que já estava disponível, e treinar a equipe investindo tempo para ensinar o uso efetivo das automações.
Próximos passos
Expansão e roadmap da utilização do Kiro: Automações para incluir análise preditiva de custos AWS, automação de testes de disaster recovery, geração automática de documentação de arquitetura e análise de conformidade e descobertas de segurança.
Conclusão
A combinação de Infrastructure as Code, versionamento robusto e IA integrada converteu operações que eram gargalos em processos ágeis e confiáveis. O Kiro não substituiu a equipe, ele multiplicou a capacidade de entregar valor, isso liberou a equipe para focar em problemas estratégicos enquanto tarefas repetitivas são automatizadas com segurança e governança.
Para equipes que gerenciam infraestrutura AWS em escala no Inter&Co e em outras organizações, a automação inteligente não é mais opcional e sim essencial para manter velocidade sem sacrificar qualidade e segurança.
Nesse post foi possível entender o impacto operacional em larga escala que o Kiro consegue trazer para uma organização. Veja outro possível caso de uso do Kiro em: https://aws.amazon.com/blogs/machine-learning/build-aws-architecture-diagrams-using-amazon-q-cli-and-mcp/
Autores
![]() |
Gustavo Fernandes Batista é Database Administrator no Inter&Co, especializado em automação de infraestrutura AWS e operações de banco de dados em escala. Com vasta experiência no gerenciamento de centenas de servidores e recursos através de Infrastructure as Code, Gustavo foca na implementação de soluções inteligentes que aumentam a eficiência operacional mantendo padrões de segurança e governança. |
![]() |
Murillo da Costa Tavares é Senior Technical Account Manager na AWS. Fatecano e Paulistano, possui 15 anos de experiência em TI, dedicando sua carreira à operação e administração de sistemas de missão crítica no segmento enterprise. Faz parte da comunidade técnica de banco de dados na AWS. |
![]() |
Willer Púlis é Senior Solutions Architect na AWS, com 18 anos de experiência operando e arquitetando sistemas produtivos de alta criticidade e membro da comunidade técnica de banco de dados da AWS. Willer adora falar sobre arquitetura de sistemas, mas principalmente sobre bancos de dados, resiliência e sistemas distribuídos.
|


