Cloud FinOps na Prática: Reduzindo Gastos em AWS e GCP Sem Reduzir a Velocidade de Entrega

Em data centers tradicionais, a compra de um servidor exigia a aprovação de despesas de capital pelo diretor financeiro, um ciclo de compras e um prazo de entrega de hardware de seis semanas. Na nuvem pública, um desenvolvedor júnior pode alterar uma única linha em um arquivo do Terraform ou em um manifesto de implantação do Kubernetes às 16h45, criar um cluster de instâncias de GPU ou de banco de dados com muita memória e adicionar silenciosamente US$ 15.000 por mês às despesas operacionais da empresa antes que qualquer pessoa do setor financeiro veja uma fatura.

A computação em nuvem descentralizou a aquisição de infraestrutura para a ponta da engenharia, o que foi fenomenal para a velocidade de implantação e desastroso para a governança de custos quando deixado sem controle.

De acordo com as referências anuais da indústria do Flexera State of the Cloud Report e da FinOps Foundation, as empresas desperdiçam cerca de 27% a 32% de seus gastos totais com nuvem em computação superdimensionada, ambientes ociosos, camadas de armazenamento não otimizadas e taxas de transferência de rede evitáveis.

No entanto, quando a diretoria entra em pânico devido à redução das margens brutas e exige um corte imediato de 25% nos gastos com AWS, Google Cloud (GCP) ou Azure, a pior coisa que um diretor de tecnologia pode fazer é impor um congelamento geral nos roteiros de produtos. O verdadeiro FinOps não consiste em sufocar a engenharia, mas sim na eliminação cirúrgica de desperdícios arquitetônicos. Este é o plano de execução de 90 dias que reduz consistentemente os gastos com nuvem de 25% a 45% sem desacelerar uma única liberação de produto.

1. Dias 1, 15: Visibilidade, Marcação e Eliminação de Infraestrutura Zumbi

Você não pode otimizar o que não pode atribuir. As primeiras duas semanas de qualquer reestruturação de FinOps concentram-se no estabelecimento de tags de alocação de custos (environment, service, squad, cost-center) e na eliminação de desperdícios de risco zero que não exigem nenhuma refatoração de código:

• Armazenamento de Blocos não Associado e Snapshots Órfãos: Quando instâncias do EC2 ou Compute Engine são encerradas, seus volumes do Elastic Block Store (EBS) e anos de snapshots diários automatizados frequentemente permanecem, gerando cobranças mês após mês.
• Balanceadores de Carga Ociosos e IPs Elásticos: Microsserviços descontinuados há seis meses geralmente deixam para trás Application Load Balancers (ALBs) órfãos e endereços IPv4 públicos não utilizados.
• Cronogramas de Desligamento fora de Produção: Por que os clusters de dev, qa e staging rodam 168 horas por semana se os engenheiros trabalham apenas cerca de 45 a 50 horas por semana? Automatizar o dimensionamento de instâncias fora de produção para zero entre 20h00 e 7h00 nos dias úteis e em todo o fim de semana reduz imediatamente 65% dos custos de computação fora de produção.
• Políticas de Ciclo de Vida do S3 / Armazenamento em Nuvem: A aplicação de transições automáticas (como o S3 Intelligent-Tiering ou a movimentação de logs de aplicativos com mais de 30 dias para o Glacier) reduz rotineiramente as faturas de armazenamento em 40% a 60% da noite para o dia.

2. Dias 16, 45: Redimensionamento de Computação, Solicitações do Kubernetes e Migração para ARM

Assim que os recursos zumbis são eliminados, o próximo alvo é a utilização da computação. Em clusters típicos de Kubernetes corporativos (EKS, GKE, AKS), a utilização real média de CPU fica abaixo de 18%, enquanto a utilização de memória fica próxima de 30%.

Por quê? Porque os desenvolvedores copiam e colam requests e limits de modelos YAML antigos, solicitando 2 vCPUs e 8 GB de RAM para um microsserviço que atinge o pico de 0,15 vCPUs e 600 MB. Como o agendador do Kubernetes aloca nós com base na capacidade solicitada e não no uso real, o dimensionador automático do cluster cria dezenas de nós caros que ficam 80% vazios.

Simultaneamente, a recompilação de serviços conteinerizados (Node.js, Python, Go, Java, .NET 8+) e bancos de dados gerenciados (RDS, Aurora, ElastiCache) para rodar em processadores baseados em ARM (como AWS Graviton ou GCP Tau T2A) oferece uma melhoria imediata de 20% a 35% na relação preço-desempenho com o mínimo esforço de engenharia.

3. Dias 46, 75: Eliminação de Impostos Ocultos (Gateways NAT, Cross-AZ e Observabilidade)

Algumas das linhas mais dolorosas em uma fatura de nuvem não têm nada a ver com CPU ou armazenamento:

1. A Armadilha do Gateway NAT: Na AWS e no GCP, os Gateways NAT gerenciados cobram tanto por hora quanto por gigabyte de dado processado. Auditamos rotineiramente empresas que gastam mais de US$ 8.000 por mês em Gateways NAT simplesmente porque as sub-redes privadas estão puxando terabytes de imagens Docker do ECR ou lendo arquivos do S3 por meio de um Gateway NAT em vez de usar um Gateway VPC Endpoint gratuito. Adicionar cinco linhas de Terraform para provisionar um VPC Endpoint do S3/DynamoDB reduz essa taxa de transferência para US$ 0.
2. Tráfego de Comunicação entre Zonas de Disponibilidade (Cross-AZ): Os provedores de nuvem cobram de US$ 0,01 a US$ 0,02 por GB toda vez que um microsserviço em us-east-1a se comunica com um broker do Kafka, cache do Redis ou banco de dados em us-east-1b. Habilitar o roteamento sensível à topologia no Kubernetes e compactar cargas úteis elimina milhares de dólares em vazamento silencioso de rede.
3. Inchaço de Observabilidade: Enviar logs detalhados de DEBUG e INFO de serviços de alto rendimento para o Datadog, New Relic ou CloudWatch sem amostragem geralmente resulta em uma fatura de observabilidade que excede 20% de todo o orçamento de infraestrutura. Filtre o ruído de verificação de integridade na borda do coletor e separe os logs frios para armazenamento de objetos barato.

4. Dias 76, 90: Compromissos e Economia Unitária

Observe que os compromissos financeiros (Reserved Instances e Compute Savings Plans) vêm por último, nunca primeiro. Se você assinar um Savings Plan de três anos na Semana 1 em uma arquitetura inchada e superdimensionada, você acabou de bloquear seu desperdício por 36 meses. Somente após a exclusão dos ativos zumbis, o redimensionamento dos pods do Kubernetes e a conclusão das migrações para ARM é que você deve fechar Savings Plans de 1 a 3 anos para cobrir 70% a 80% de sua carga base constante limpa, enquanto usa instâncias Spot/Preemptíveis (por via do Karpenter) para cargas de trabalho em lote e de CI/CD tolerantes a falhas.

Por fim, o FinOps maduro muda a conversa de gasto mensal total para Economia Unitária: medindo o custo de nuvem por 1.000 transações de API, custo por locatário ativo ou custo como porcentagem da receita bruta (COGS). Quando cada equipe vê o impacto do custo unitário de suas solicitaçõespull diretamente ao lado da latência e das taxas de erro, a eficiência de custos se torna um hábito permanente de engenharia, em vez de uma emergência anual.

Continue lendo: explore FinOps 2030: Zero Cost Is Not the Goal e ROI Is King: Why Software Engineering Must Answer to Unit Economics.

---

Referências verificáveis e leitura adicional

• FinOps Foundation (2025). FinOps Framework & State of FinOps Report. Linux Foundation.
• FinOps Foundation (2025). Cloud Unit Economics Playbook.
• Storment, J. R., & Fuller, M. (2023). Cloud FinOps: Collaborative, Real-Time Cloud Value Decision Making (2nd Edition). O'Reilly Media.