Como o FinOps do Inter&Co foi de semanas para dias em automações com Kiro

Por Letícia Thaís da Silva, IT Specialist no Inter&Co; Luís Prudêncio, FinOps Analyst no Inter&Co; Victor Maciel, FinOps Analyst no Inter&Co.

Introdução

O time de FinOps do Inter transforma oportunidades de otimização em automações de produção. Com o Kiro, esse ciclo caiu de semanas para dias.

A equipe é enxuta e gerencia a otimização de custos AWS em escala. Como qualquer time FinOps sabe, a distância entre identificar uma oportunidade de saving (economia) e transformá-la em automação recorrente costuma ser medida em semanas. Foi nesse contexto que o time adotou o Kiro como ambiente de desenvolvimento assistido por IA, buscando acelerar o ciclo entre a identificação de desperdício e a entrega de soluções automatizadas.

A adoção do Kiro se provou acertada: redução de 45% nos custos de Extended Support e 64% no custo de compute fora do horário comercial dos recursos afetados (dados acumulados de março a maio de 2026). Essas economias foram geradas por automações construídas com o Kiro em uma fração do tempo que levariam no processo tradicional. A primeira frente atua no controle proativo de versões End of Standard Support (fim de suporte padrão, ou Standard Support), e a segunda no gerenciamento inteligente de tags para desligamento automático. Além do uso diário do Kiro como assistente em investigações de custo sob demanda.

Neste blog post, detalhamos como cada automação funciona e qual o papel do Kiro no processo de criação. Mostramos também como o workflow requirements-first (fluxo de trabalho orientado por requisitos) mudou a forma como o time pensa e entrega soluções de otimização. Se você é profissional de FinOps, engenheiro de plataforma ou líder técnico avaliando como IA pode potencializar seu time, este relato traz dados reais e lições práticas.

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 mais de 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.

Os desafios: visibilidade, desperdício e trabalho manual

1. Falta de visibilidade sobre Extended Support. Recursos com versões End of Standard Support continuavam rodando sem que a notificação chegasse de forma acionável ao time responsável. Quando o time fez o primeiro inventário estruturado, o cenário era preocupante: 13 clusters Amazon OpenSearch Service e 5 clusters Amazon ElastiCache operavam com versões expiradas, alguns há mais de 400 dias além da data de fim de suporte padrão. Esse cenário foi o ponto de ruptura: o time tinha visibilidade das oportunidades, mas não conseguia agir sobre elas no ritmo necessário.

A AWS define uma data de End of Standard Support para cada versão de engine de seus serviços gerenciados. Após essa data, o recurso entra automaticamente em Extended Support (suporte estendido), continuando a operar normalmente, mas gerando cobranças adicionais sobre o preço padrão das instâncias. A AWS notifica os clientes via AWS Health Dashboard e e-mail antes e depois da transição. Os serviços com a opção de Extended Support atualmente são: Amazon RDS (incluindo Amazon Aurora), Amazon ElastiCache, Amazon OpenSearch Service, Amazon DocumentDB e Amazon EKS (sempre consulte a documentação oficial da AWS para manter essa lista atualizada). Quanto maior o parque de recursos e contas, mais difícil manter visibilidade manual sobre quais versões já entraram ou estão para entrar em Extended Support.

2. Desperdício com recursos ligados 24/7. Diversos ambientes possuíam a tag skip=true, que impedia o desligamento automático fora do horário comercial. Sem um processo para revisar e questionar essas exceções, o custo se acumulava sem visibilidade interna mês após mês.

3. Investigações manuais de custo. Cada análise de anomalia ou validação de economia exigia horas de trabalho repetitivo: consultar o AWS Cost Explorer, cruzar dados com o Jira, gerar relatórios. Tudo feito de forma ad-hoc (consultas sob demanda, não estruturadas), sem padronização.

No processo anterior, transformar uma oportunidade de economia em automação de produção levava cerca de 30 dias, dependendo de filas em times de engenharia. Investigações de custo eram feitas sob demanda, sem padronização: consultar o AWS Cost Explorer, cruzar dados com Jira, gerar relatórios manualmente. Tags como skip=true eram configuradas durante implantações emergenciais e nunca revisadas. Sem um processo que permitisse ao próprio time de FinOps codificar suas soluções, o modelo simplesmente não escalava.

O denominador comum dessas três dores era a ausência de um processo estruturado para criar automações. Times de FinOps têm como competência central a análise e otimização de custos. Transformar uma oportunidade de savings (economias) em código de produção normalmente depende de ciclos de desenvolvimento mais longos ou de filas em times de engenharia. O Kiro elimina essa barreira: com o workflow requirements-first, o time converte sua expertise financeira diretamente em automações robustas, com a estrutura e o rigor de um time de engenharia.

Com os desafios mapeados, o próximo passo era encontrar uma abordagem que permitisse ao time transformar ideias em código de forma rápida e estruturada. Foi aí que o Kiro entrou.

A solução: automação inteligente com Kiro

A Automação 1 (Extended Support) foi desenvolvida em 10 dias com o workflow requirements-first. No processo anterior, uma automação equivalente levava cerca de 30 dias com o time de engenharia.

O Kiro opera com um workflow chamado requirements-first. Toda automação começa pela definição formal de requisitos com critérios de aceitação. A partir deles, o Kiro gera um documento de design (diagramas de fluxo, modelos de dados, estratégia de testes) e cria as tasks (tarefas) de implementação priorizadas, com dependências mapeadas.

Esse ciclo “requisitos → design → tasks → código” garante que cada decisão técnica seja rastreável a uma necessidade de negócio. Isso elimina, na prática, o problema clássico de “começar a desenvolver sem saber exatamente o que precisa ser feito”.

Usando esse workflow, o time construiu duas automações recorrentes que transformaram suas operações, além de incorporar o Kiro como assistente diário em investigações de custo.

Automação 1: Monitoramento de Extended Support

A AWS cobra Extended Support para recursos que operam com versões que já atingiram o fim de vida (End of Standard Support). Na prática, isso significa que um cluster OpenSearch rodando Elasticsearch 7.1, cuja data de fim de suporte padrão foi novembro de 2025, passa a gerar custos adicionais automaticamente, sem que os times responsáveis tenham visibilidade.

Para resolver esse problema, o time construiu uma automação que avalia todos os recursos elegíveis, verifica a versão de cada um contra as datas oficiais de fim de suporte da AWS, classifica o status e gera um relatório consolidado com notificação automática aos times responsáveis. O fluxo funciona assim:

• Semanalmente, a automação percorre todas as contas, buscando recursos em Extended Support (ES) ou próximos a entrar.
• Recursos já em suporte estendido são listados como expirados, mostrando há quantos dias estão em ES.
• Recursos a menos de 60 dias para entrar em ES são monitorados para que os times consigam se programar para atualizar as versões.

O output da automação é um e-mail consolidado por serviço. Exemplo resumido:

Figura 1. Exemplo de relatório consolidado gerado pela automação de Extended Support, mostrando clusters OpenSearch com versões expiradas, dias em suporte estendido e versão recomendada para atualização.

Trecho de código da automação:

def collect_rds(session: boto3.Session, account_name: str, region: str) -> list[MonitoredResource]:
    """Coleta instâncias RDS standalone e clusters Aurora que possuem versões mapeadas
    no dicionário de fim de suporte. Ignora instâncias que pertencem a um cluster (evita duplicidade)."""
    try:
        client = session.client("rds", region_name=region)
        tagging = session.client("resourcegroupstaggingapi", region_name=region)
        resources: list[MonitoredResource] = []

        # Coleta instâncias RDS standalone (ignora membros de clusters Aurora)
        for page in client.get_paginator("describe_db_instances").paginate():
            for inst in page.get("DBInstances", []):
                if inst.get("DBClusterIdentifier"):
                    continue  # Pertence a um cluster, será coletado abaixo
                engine = inst.get("Engine", "").lower()
                version = inst.get("EngineVersion", "")
                major = _extract_major_version_rds(version)
                date_str = RDS_END_OF_SUPPORT.get(engine, {}).get(major)
                if not date_str:
                    continue  # Versão não monitorada
                arn = inst.get("DBInstanceArn", "")
                resources.append(MonitoredResource(
                    resource_id=arn or inst.get("DBInstanceIdentifier", "unknown"),
                    resource_name=inst.get("DBInstanceIdentifier", "unknown"),
                    service_name="RDS", version=f"{engine} {version}",
                    extended_support_date=date.fromisoformat(date_str),
                    region=region, account_name=account_name,
                    tags=_get_tags(tagging, arn),
                    recommended_version=RDS_RECOMMENDED_VERSION.get(engine, {}).get(major, "-"),
                ))

        # Coleta clusters Aurora
        for page in client.get_paginator("describe_db_clusters").paginate():
            for cl in page.get("DBClusters", []):
                engine = cl.get("Engine", "").lower()
                version = cl.get("EngineVersion", "")
                major = _extract_major_version_rds(version)
                date_str = RDS_END_OF_SUPPORT.get(engine, {}).get(major)
                if not date_str:
                    continue
                arn = cl.get("DBClusterArn", "")
                resources.append(MonitoredResource(
                    resource_id=arn or cl.get("DBClusterIdentifier", "unknown"),
                    resource_name=cl.get("DBClusterIdentifier", "unknown"),
                    service_name="RDS", version=f"{engine} {version}",
                    extended_support_date=date.fromisoformat(date_str),
                    region=region, account_name=account_name,
                    tags=_get_tags(tagging, arn),
                    recommended_version=RDS_RECOMMENDED_VERSION.get(engine, {}).get(major, "-"),
                ))

        return resources
    except ClientError as e:
        logger.warning(f"[RDS] Erro em {account_name}: {e}")
        return []

O Kiro foi fundamental na construção dessa automação. O time usou o workflow requirements-first para definir com clareza os critérios de classificação (EXPIRADO, ALERTA ou INFO), as regras de notificação e o formato do relatório. A partir dos requisitos, o Kiro gerou o design da solução e criou as tasks de implementação.

O impacto dessa automação nos três primeiros meses foi de aproximadamente 45% de redução nos custos de Extended Support. A tendência é que esse custo se aproxime de zero, uma vez que todos os responsáveis pela gestão dos ambientes passíveis de suporte estendido passaram a receber o e-mail de notificação e estão atuando de forma proativa na atualização de versões.

Automação 2: Governança de tags “skip”

No Inter, uma tag chamada skip controla o desligamento automático de recursos (EC2, RDS e DocumentDB) fora do horário comercial. Recursos com skip=true permanecem ligados 24/7, enquanto recursos com skip=false são desligados automaticamente. Ao longo do tempo, diversos ambientes acumulam skip=true como padrão – muitas vezes configurada durante um deploy (implantação) emergencial ou teste pontual – e ninguém revisa essas exceções.

A automação construída com o Kiro resolve esse problema de forma sistemática. Diariamente, ela percorre todos os recursos com skip=true, valida se cada um realmente precisa ficar ligado fora do horário comercial (com base em outra tag Skip_Until < data atual), e altera a tag para skip=false nos recursos elegíveis. A partir desse momento, o mecanismo de desligamento automático já existente na infraestrutura passa a atuar sobre esses recursos, gerando economia imediata.

Validação:

def has_valid_skip_until(tags):
    #Verifica se o recurso tem uma data Skip_Until ainda no futuro.
    for t in (tags or []):
        if t.get("Key", "").lower().replace(" ", "").replace("-", "").replace("_", "") in {k.replace(" ", "").replace("-", "").replace("_", "") for k in SKIP_UNTIL_KEYS}:
            val = (t.get("Value") or "").strip()
            for fmt in DATE_FORMATS:
                try:
                    skip_date = datetime.strptime(val, fmt).replace(tzinfo=timezone.utc)
                    if skip_date > datetime.now(timezone.utc):
                        return True  # Data ainda no futuro — manter skip=true
                    return False   # Data já passou — pode alterar para false
                except ValueError:
                    continue
    return False  # Sem tag Skip_Until — pode alterar

Após a execução, o time de FinOps recebe um relatório mostrando todos os recursos alterados e aqueles com Skip_Until no futuro, garantindo total auditoria. O relatório já inclui o cálculo da economia semanal gerada.

E-mail recebido pelo time:

Figura 2. Relatório de execução da automação de governança de tags, exibindo recursos com a tag Skip alterada de True para False e o custo semanal evitado por recurso.

Essa frente reduz em aproximadamente 64% o custo de compute dos recursos afetados – já que ao ficarem desligados das 20h às 8h nos dias úteis e durante os fins de semana, deixam de consumir a maior parte das horas fora do horário comercial. Além da economia financeira, o time agora tem visibilidade contínua sobre quais recursos realmente precisam da exceção skip=true, transformando uma decisão que antes era “configurar e esquecer” em um processo revisado e governado.

Kiro como assistente de investigações de custo

Além das automações estruturadas, o Kiro se tornou assistente diário para investigações de custo sob demanda.

Logo no primeiro dia de uso, o time de finops conseguiu identificar de forma muito rápida três oportunidades de otimizações, detalhadas abaixo:

Além disso, existem outras análises importantes recorrentes que o time realiza:

• Análise comparativa mensal de 22 solutions: de 4-6 horas para 10 minutos.
• Cálculo retroativo de saving de 4 clusters Amazon Aurora PostgreSQL já deletados: de 2-3 horas para 5 minutos.
• Investigação de anomalia de custos em Amazon CloudWatch com identificação dos log groups (grupos de log) ofensores: resolvida em menos de 2 minutos.

O resultado consolidado: uma redução de 97% no tempo de análise.

Uso de MCP

O desenvolvimento das automações e das análises é possível porque o time usa servidores MCP (Model Context Protocol) da AWS conectados ao Kiro, como:

• awslabs.billing-cost-management-mcp-server. Gestão completa de custos e billing, permitindo consultas ao Cost Explorer, budgets e anomalias diretamente pelo Kiro.
• awslabs.aws-pricing-mcp-server. Consulta de preços de serviços AWS para cálculo de savings e comparações on-demand vs. reservas.
• aws-knowledge-mcp-server. Acesso à documentação oficial da AWS e conhecimento regional, dando contexto técnico para decisões de otimização

Além do workflow requirements-first, a decisão de conectar servidores MCP ao Kiro foi fundamental. Isso elimina a troca de contexto entre IDE e console, dando ao time acesso a dados reais de custo e documentação oficial dentro do próprio fluxo de desenvolvimento. O ponto central não é substituir o analista, mas ampliar sua capacidade. O Kiro formula as queries, cruza os dados e gera relatórios priorizados por impacto financeiro. O analista valida os achados, toma decisões e direciona as ações.

Resultados

O impacto consolidado das automações é mensurável tanto em economia financeira quanto em produtividade. Os dados refletem o período de observação de março a maio de 2026 (3 meses), com resultados consistentes mês a mês.

As automações geraram economia recorrente em duas frentes independentes:

Próximos passos

Agora com o Kiro, o time de FinOps do Inter está com uma pipeline (esteira) contínua de desenvolvimento de automações. As próximas frentes são:

1. Encerramento automático de cards de otimização de custos: hoje, após identificar uma economia, o analista precisa consultar o AWS Cost Explorer manualmente, calcular o saving mensal e fechar o card no Jira com os resultados documentados. A automação vai executar esse ciclo de ponta a ponta: ler o card, consultar o custo real via API, calcular a economia e encerrar o card com evidências, eliminando trabalho repetitivo que o time faz dezenas de vezes por mês.

2. O time está construindo um sistema que analisa semanalmente a cobertura de Reserved Instances (Amazon Redshift, Amazon RDS, Amazon ElastiCache, Amazon DynamoDB e Amazon DocumentDB). A automação identifica recursos elegíveis para compra de RI (com base em idade, uso de CPU e família de instância), monitora reservas próximas do vencimento e envia recomendações e alertas via Slack, com o workflow requirements-first do Kiro estruturando cada etapa.

Conclusão

A principal lição dessa jornada é que automação em FinOps não precisa ser um projeto de meses. Com o Kiro estruturando o pensamento desde os requisitos até o código, o time conseguiu reduzir o ciclo de entrega de semanas para dias, convertendo sua expertise em FinOps diretamente em código de produção.

Para times que desejam replicar essa abordagem, os pré-requisitos são: acesso ao Kiro (disponível em kiro.dev, com suporte a autenticação via Identity Provider corporativo/SSO [Single Sign-On]), configuração dos servidores MCP da AWS para acesso a dados de custo e documentação, e acesso programático cross-account via IAM roles para que as automações percorram os recursos.

Se seu time de FinOps identifica oportunidades de saving mas leva semanas para implementar, o Kiro pode ser o acelerador que falta. Para aprofundar-se em práticas de otimização de custos AWS, consulte o AWS Well-Architected Framework, Pilar de Otimização de Custos. E para ver mais casos de uso de clientes AWS na América Latina, visite o Blog AWS Brasil.

Autores

	Letícia Thaís da Silva é IT Specialist no Inter&Co, com 15 anos de experiência em tecnologia. Integra o time de FinOps com foco em engenharia de custos, liderando iniciativas de otimização em ambientes AWS e disseminação da cultura FinOps junto a equipes multidisciplinares.
	Luís Prudêncio é Analista de FinOps no Inter&Co, com atuação em AWS, observability e infraestrutura cloud. Graduado em Redes de Computadores pela Faculdade Batista de Minas Gerais, possui 6 anos de experiência em infraestrutura de TI. Atualmente, aprofunda sua atuação em eficiência operacional, gestão de disponibilidade de ambientes e redução de custos na organização.
	Victor Maciel é FinOps Analyst no Inter&Co, com experiência em infraestrutura AWS e gerenciamento de custos de nuvem. Atua na intersecção entre engenharia e governança de FinOps, transitando entre as áreas de produto, tecnologia e dados para colaborar com insights de otimização e redução de custos, sempre com foco em escalabilidade e resiliência sem comprometer disponibilidade e inovação.