finops-architect-toolkit

Em toda revisão de custo de que participei, a conversa travava no mesmo ponto: alguém de compras pergunta "vale a pena reservar?", alguém de engenharia responde "depende", e a reunião acaba sem número. O README resume a premissa: decisões de arquitetura definem cerca de 80% da conta, então a pergunta de FinOps cai no colo do arquiteto, quer ele queira ou não.

A pergunta que importa não é "quanto custa?", é "o que otimizar primeiro, e com que compromisso?". Para responder isso na própria reunião, preciso de contas rápidas, reproduzíveis e que falem a língua de compras (compromisso, break-even, período) e a de engenharia (invocações, duração, memória, padrão de acesso).

Este toolkit é isso: um conjunto pequeno de calculadoras e modelos que levo para essa conversa. Não substitui o Cost Explorer nem o Compute Optimizer. Ele serve para o momento anterior, quando você ainda está decidindo o desenho e quer saber a ordem de grandeza antes de abrir o console.

RI vs On-Demand: o break-even é a parte que vale a reunião. Reserva só compensa se a instância roda horas suficientes por mês durante o prazo inteiro; uma carga que vai ser migrada para container em seis meses não deveria entrar num compromisso de um ou três anos, por melhor que seja o desconto.

Classe do S3: a comparação por GB armazenado engana quando você esquece o resto da fatura. Standard-IA tem duração mínima de 30 dias e cobra objeto pequeno como se tivesse 128 KB; Glacier Flexible Retrieval tem mínimo de 90 dias e Deep Archive de 180, além do custo de recuperação. Use a calculadora para a ordem de grandeza e confira esses limites antes de escrever a lifecycle policy.

Lambda: o custo é invocações mais GB-segundo, ou seja, memória × duração × invocações. Subir a memória às vezes reduz o custo, porque a duração cai junto. Rode o cenário com duas ou três configurações em vez de assumir.

Tagging: sem tag consistente, nenhum dos números acima chega ao centro de custo certo. Defina as chaves antes de otimizar; senão você otimiza uma conta que ninguém consegue atribuir.

É uma aplicação de frontend só: Next.js 16 com React 19, TypeScript 5 e Tailwind CSS 4, em frontend/. As contas acontecem no próprio app, sem backend e sem chamada a API da AWS, o que mantém o custo de rodar perto de zero e elimina a pergunta sobre onde guardar credencial.

O README lista quatro pipelines de GitHub Actions: CI, Frontend, Vercel e Security. O deploy vai para a Vercel, com DNS na Cloudflare, e a versão publicada fica em finops.moretes.com. A licença é MIT.

Essa escolha tem um trade-off claro. Sem integração com o Cost and Usage Report, o toolkit não descobre desperdício sozinho; ele responde perguntas que você já sabe formular. Para uma ferramenta de conversa de arquitetura, prefiro assim: o custo de manter uma integração com CUR, permissões IAM e atualização de tabela de preço é maior que o valor que ela traria para esse uso.