Sua fatura de cloud sobe e ninguém sabe explicar por quê

O problema que vemos no mercado

A fatura de cloud é a despesa que mais cresce em silêncio. Ninguém aprova um aumento de 30% por trimestre numa reunião — ele simplesmente acontece, linha a linha, à medida que cada time provisiona o que precisa e ninguém desprovisiona o que parou de usar. Quando o CFO finalmente pergunta por que a conta da AWS dobrou em um ano, a engenharia não tem resposta. Não porque é incompetente, mas porque o custo de cloud é distribuído, opaco e fácil de ignorar enquanto há orçamento.

Quando abrimos a conta de um cliente, encontramos quase sempre o mesmo conjunto de desperdícios. Instâncias superdimensionadas: máquinas m5.2xlarge rodando a 8% de CPU porque alguém chutou alto no início e nunca revisou. Recursos órfãos: volumes EBS desanexados há meses, snapshots de instâncias que não existem mais, IPs elásticos alocados e parados, load balancers sem target. Ambientes de staging e dev ligados 24 horas por dia, sete dias por semana, quando são usados em horário comercial — pagando noite e fim de semana por nada.

Do lado de segurança e arquitetura o quadro rima. IAM frouxo: chaves de acesso longevas que nunca rotacionaram, políticas com Action *:* em Resource *, usuários humanos com credenciais programáticas que deveriam ser roles. E quase sempre falta infraestrutura como código: a mudança crítica foi feita à mão no console às duas da manhã durante um incidente, o Terraform (quando existe) está em drift, e ninguém sabe mais o que está realmente provisionado versus o que o repositório diz. Sem tags de custo, não dá nem pra responder a pergunta mais básica: quanto este produto, este time ou este cliente custa por mês?

Como entregamos

A auditoria é independente — não vendemos cloud, não temos comissão de provider, não temos interesse em você gastar mais. Começamos com acesso somente-leitura à sua conta (role de auditoria, sem permissão de escrita) e ao billing. A partir daí o trabalho se divide em quatro frentes que rodam em paralelo, e termina num único entregável acionável.

FinOps é a frente que paga a auditoria sozinha na maioria dos casos. Cruzamos uso real com provisionamento para identificar right-sizing (quais instâncias estão grandes demais e qual o tamanho correto pela carga observada), mapeamos e listamos todos os recursos órfãos para descomissionar, e calculamos a economia de compromissos: Savings Plans e Reserved Instances na AWS, Committed Use Discounts no GCP, Reservations no Azure — onde a carga é estável o suficiente para justificar o compromisso de 1 ou 3 anos. Configuramos budget alerts para que o próximo salto de custo dispare um aviso, não uma surpresa no fechamento do mês.

A auditoria Well-Architected revisa a arquitetura pelos cinco pilares do framework (excelência operacional, segurança, confiabilidade, eficiência de performance e otimização de custo), apontando os trade-offs reais — não uma checklist genérica, mas onde a sua arquitetura específica está deixando dinheiro, resiliência ou segurança na mesa. A revisão de IaC mede o drift entre o Terraform e o que está de fato provisionado, avalia a estrutura de módulos e o gerenciamento de state, e propõe trazer para código o que hoje só existe no console. E a frente de IAM aplica o princípio de least-privilege: identificamos chaves longevas para rotacionar ou eliminar, políticas excessivamente permissivas para restringir, e fronteiras de organização para reforçar.

Tudo isso desemboca em observabilidade de custo (Cost Explorer, billing export para BigQuery ou similar, tags de alocação) e num plano de consolidação ou migração quando faz sentido — sempre com ROI estimado por item, ordenado do maior retorno e menor risco para o mais delicado. Nada é executado às cegas: o que toca produção vai com janela e rollback definidos.

Stack que usamos em produção hoje

Providers: AWS, GCP e Azure. A maior parte do trabalho é em AWS por ser onde mora a maioria das contas que auditamos, mas os princípios de FinOps e os pilares de Well-Architected são os mesmos nos três — muda o nome do botão. Auditamos contas multi-cloud no mesmo engajamento quando o cliente tem carga espalhada.

Infraestrutura como código: Terraform é o default, e OpenTofu quando o cliente já migrou ou quer migrar para evitar a dependência de licença da HashiCorp. Trabalhamos sobre o state existente, medimos drift com plan e import, e entregamos as correções como Pull Requests revisáveis no seu repositório — não aplicamos nada direto, você lê o diff e dá merge.

Custo e billing: Cost Explorer e AWS Budgets na AWS, billing export para BigQuery no GCP, Cost Management no Azure. Quando o cliente precisa de visão unificada cross-provider ou quer dashboards próprios, montamos a partir dos exports de billing. Governança e segurança: IAM, Organizations e Service Control Policies na AWS (e os equivalentes nos demais providers) para least-privilege e fronteiras de conta.

O que vai (e o que não vai) entregar valor

Vamos ser diretos sobre quando esta auditoria rende. Ela entrega muito quando a sua fatura passou de algumas dezenas de milhares por mês e cresce sem explicação clara — aí quase sempre há desperdício de FinOps significativo (right-sizing e órfãos costumam somar de 20% a 40% da conta) esperando para ser cortado. Entrega valor quando o IAM nunca foi revisado e está acumulando risco silencioso, ou quando o Terraform está em drift e ninguém confia mais no que ele descreve.

E vamos ser igualmente diretos sobre quando NÃO é a resposta. Se a sua fatura é alta porque a aplicação faz queries ineficientes que martelam o banco, o problema não é cloud — é o app e o banco, e o caminho certo é otimização de banco de dados ou aceleração de performance, não cortar instância. Cortar a máquina sem corrigir a causa só troca lentidão por queda. Da mesma forma, se você está cedo demais — uma conta de poucos milhares por mês, ainda crescendo, sem padrão de uso estável — FinOps pesado é prematuro: o ganho de uma auditoria completa não cobre o custo dela, e o seu tempo rende mais em produto. Nesse estágio, o que cabe é higiene básica (budget alert, desligar staging fora de hora) que entregamos em uma sessão, não um engajamento.

A regra que usamos para decidir: se há desperdício estrutural de custo, risco real de IAM ou drift de infraestrutura que se acumula, a auditoria se paga. Se o gargalo é a aplicação ou se a conta ainda é pequena demais para o esforço, dizemos isso na primeira conversa — e te apontamos para o serviço certo em vez de vender uma auditoria que não vai render.

Propriedade · o resultado é seu

Você sai da auditoria com três entregáveis no seu nome, não com uma dependência de consultoria. O relatório completo (achados de custo, segurança e arquitetura, com a justificativa técnica de cada um) é seu para circular internamente. A planilha de economia priorizada lista cada item com economia estimada, esforço e risco, ordenada por ROI — é o seu roadmap de corte, executável pelo seu time ou por nós. E as correções de IaC chegam como Pull Requests de Terraform no seu repositório: você lê o diff, entende o que muda e dá merge no seu ritmo. Sem caixa-preta, sem lock-in, sem precisar nos chamar de volta para entender o que foi feito.

Próximo passo

O ponto de partida é uma conversa curta onde olhamos o formato da sua conta — provider, ordem de grandeza da fatura, se há IaC, há quanto tempo o IAM não é revisado — e respondemos uma pergunta só: há economia e risco suficientes aqui para uma auditoria se pagar, ou você está cedo demais e basta higiene básica? Saímos da conversa com uma resposta clara e, se a auditoria fizer sentido, com o escopo e a faixa de ganho estimada. Sem proposta inflada, sem PowerPoint.

Veja também

• otimização de banco de dados
• aceleração de performance