Todo mês a história se repete: a fatura da nuvem chega alguns dígitos acima do orçado, o setor financeiro questiona a liderança de tecnologia e a equipe de arquitetura promete "otimizar recursos no próximo sprint". O problema é que grande parte das iniciativas de redução de custo em cloud foca no lugar errado — como tentar negociar instâncias reservadas para workloads que sequer deveriam estar rodando.

Na prática do dia a dia, os maiores desperdícios de infraestrutura raramente vêm de grandes decisões arquiteturais malucas. Eles nascem de pequenas negligências acumuladas, conveniências temporárias que viraram permanentes e total falta de visibilidade sobre o ciclo de vida dos recursos. Vamos analisar cinco pontos cegos críticos que drenam o orçamento de TI e o passo a passo prático para resolver cada um deles.

1. Armazenamento Órfão: Volumes EBS e Snapshots Abandonados

Quando uma instância virtual (EC2, Droplet, Compute Engine) é terminada, o comportamento padrão nem sempre deleta os discos adicionais atrelados a ela. O resultado? Centenas de gigabytes — ou até terabytes — em volumes EBS (ou equivalentes) desacoplados (status unattached ou available), cobrando seu valor nominal integral mês após mês.

O mesmo se aplica aos backups automáticos (snapshots) criados sem política de expiração (retention policy). Um snapshot incremental de um banco de dados de homologação criado em 2024 pode estar gerando faturas silenciosas até hoje.

Ação imediata:

  • Automatize rotinas com AWS CLI, scripts em Python ou ferramentas nativas de Lifecycle Manager para identificar e purgar volumes não anexados há mais de 7 dias.
  • Estabeleça limites claros de retenção para ambientes que não sejam de produção (snapshots de homologação raramente precisam de mais de 7 a 14 dias de histórico).

2. Overprovisioning por Medo e Falta de Métricas Reais

É muito comum ver equipes alocando servidores com 32 GB de RAM e 8 vCPUs para serviços que passam 95% do tempo com 8% de uso de CPU e 15% de memória. Esse superdimensionamento quase sempre nasce do medo de gargalos operacionais ou da falta de observabilidade durante picos reais de tráfego.

Pagar por capacidade ociosa 24/7 é o anti-padrão mais caro da computação em nuvem. Se sua aplicação não possui auto-scaling horizontal ou utiliza instâncias fixas gigantes para tarefas que oscilam conforme o horário comercial, você está literalmente queimando dinheiro.

Como corrigir:

  • Analise métricas históricas de pelo menos 30 a 60 dias (CPU percentil 95, consumo de memória real e I/O de disco).
  • Faça o downsizing gradual das instâncias: reduza uma família ou tamanho por vez e acompanhe o comportamento em produção durante dias normais de carga.
  • Adote arquiteturas baseadas em containers e orquestração inteligente que distribuam melhor os recursos físicos da máquina host.

3. Ambientes de Desenvolvimento e Staging Rodando em Finais de Semana

Um mês possui em média 720 horas. Uma equipe de arquitetura e produto trabalha ativamente em dias úteis das 8h às 19h (cerca de 220 a 240 horas mensais). Isso significa que, se os seus ambientes de testes, homologação e QA ficam ligados direto, você está pagando por 480 a 500 horas de máquina completamente inútil a cada ciclo mensal.

Manter clusters de Kubernetes, bancos de dados RDS e instâncias auxiliares de homologação funcionando no sábado à noite ou durante feriados nacionais é um dos maiores desperdícios evitáveis que existem.

Solução prática:

  • Crie automações simples (via cron jobs, Lambda agendada ou CloudWatch Events) para desligar instâncias de não-produção às 20h de sexta-feira e religá-las às 07h30 de segunda-feira.
  • Só essa rotina básica reduz a fatura desses servidores e bancos auxiliares em até 65% imediatamente.

4. Transferência de Dados Entre Zonas (Data Egress Oculto)

Os provedores de nuvem adoram cobrar pela saída e pelo tráfego de dados cruzado. O tráfego de entrada geralmente é gratuito, mas a comunicação entre diferentes Zonas de Disponibilidade (AZs) ou saídas para a internet pública sem necessidade pesam brutalmente na fatura.

Se você tem um cluster de banco de dados na zona us-east-1a e instâncias de aplicação espalhadas aleatoriamente pela us-east-1b sem tráfego via VPC Peering ou endpoints privados adequados, cada consulta SQL e tráfego de imagem gera custo de transferência de dados inter-AZ.

Boas práticas de arquitetura:

  • Utilize VPC Endpoints (Gateway e Interface) para acessar serviços internos da nuvem (como buckets S3 e registros de containers) sem sair para a rede pública.
  • Configure réplicas de leitura e nós de cache na mesma zona de disponibilidade dos consumidores primários de dados.
  • Adote CDNs como Cloudflare ou CloudFront na borda para estancar requisições diretas de arquivos estáticos na infraestrutura de origem.

5. Escolha Errada de Camadas de Armazenamento de Objetos (S3 / Storage Tiers)

Armazenar arquivos brutos de logs de 3 anos atrás ou anexos fiscais antigos na classe padrão de armazenamento (Standard Storage) é um erro clássico. A classe padrão foi projetada para arquivos que exigem acesso frequente e imediato em milissegundos.

Dados frios ou arquivos que precisam ser mantidos apenas para conformidade jurídica ou auditoria devem transicionar automaticamente para camadas de arquivamento como Infrequent Access (IA), Glacier ou Deep Archive, que chegam a custar uma fração mínima do preço original por gigabyte.

Implementação:

  • Configure regras de Lifecycle Policy nos buckets para mover arquivos com mais de 30 dias para IA e com mais de 90 dias para Glacier.
  • Defina regras de expiração e deleção automática para logs transitórios e dumps temporários de depuração.

Cultura FinOps: Otimização Contínua em Vez de Mutirões Pontuais

Reduzir custos em cloud não deve ser uma corrida desesperada que acontece uma vez por ano quando a diretoria aperta os cintos. Precisa ser um hábito integrado ao ciclo de desenvolvimento. Cada arquiteto e engenheiro deve compreender o impacto financeiro das decisões técnicas que toma diariamente.

Comece atacando os volumes órfãos e automatizando o desligamento de ambientes secundários fora do horário comercial. Com apenas essas duas ações simples e de baixo risco, a maioria das empresas já recupera entre 15% e 30% do orçamento de nuvem no primeiro mês — liberando capital para investir em inovação real e expansão de produtos.