Como Reduzir Custos de Nuvem em até 40% (AWS, GCP e Azure) sem Perder Performance

A história se repete em quase toda empresa de software: o produto ganha tração, novos clientes chegam, novas features são lançadas em produção e, antes do final do mês, a fatura da AWS, GCP ou Azure salta de R$ 3.000 para R$ 18.000 sem que o faturamento tenha acompanhado na mesma proporção.

A nuvem foi desenhada para facilitar a escala horizontal, mas também foi desenhada para cobrar por cada gigabyte transferido, cada IOPS de disco e cada hora ociosa de CPU. Em equipes ágeis, a prioridade número um é entregar valor para o cliente — e a otimização de infraestrutura é frequentemente postergada até que a conta ameace o fluxo de caixa.

Neste guia prático, compilamos as estratégias que aplicamos no ecossistema de SaaS para cortar entre 30% e 45% da fatura de nuvem sem degradar a experiência do usuário ou arriscar a estabilidade do sistema.

O maior erro dos founders e líderes técnicos é tentar cortar custos desligando servidores essenciais ou diminuindo memória aleatoriamente. Custos de nuvem não devem ser cortados no susto; eles devem ser otimizados por eliminação de desperdício arquitetural.

Em uma auditoria típica de SaaS B2B, a composição do desperdício costuma se dividir em:

• 35% de recursos ociosos ou superdimensionados (máquinas com 5% de uso médio de CPU).
• 25% de armadilhas de rede (especialmente NAT Gateways e tráfego entre Zonas de Disponibilidade).
• 20% de armazenamento zumbi (volumes EBS/Persistent Disks desacoplados, snapshots antigos e logs sem política de retenção).
• 20% de falta de estratégia de compra (pagar 100% On-Demand sem Savings Plans ou instâncias reservadas).

Se você usa AWS, abra o AWS Cost Explorer agora mesmo e filtre por serviço. É muito provável que o Amazon Virtual Private Cloud (VPC) ou especificamente o EC2-Other seja um dos itens mais caros da sua fatura, frequentemente rivalizando com o banco de dados.

O que encarece o NAT Gateway? O AWS NAT Gateway cobra uma taxa fixa por hora (~$0,045/hora por gateway, o que já soma ~$32/mês por AZ), mas a verdadeira facada é a taxa de **$0,045 por gigabyte de dados processados**.

Quando seus contêineres ou instâncias EC2 em subnets privadas baixam imagens Docker do Docker Hub, enviam backups para o Amazon S3, ou chamam APIs externas públicas (como OpenAI, Stripe, Asaas ou Sentry), todo esse tráfego passa pelo NAT Gateway e é tarifado.

Como resolver: 1. **Ative VPC Endpoints para serviços da AWS**: Crie um **Gateway VPC Endpoint** para o Amazon S3 e Amazon DynamoDB. Eles são **100% gratuitos** e garantem que o tráfego para buckets não passe pelo NAT Gateway nem pela internet pública. 2. **Utilize Interface Endpoints (AWS PrivateLink)** ou configure um proxy reverso interno (como um container Nginx leve ou Envoys) para tráfego intenso. 3. **Atenção ao tráfego Inter-AZ (Cross-Availability Zone)**: Quando o microserviço A na Zona 'us-east-1a' faz consultas frequentes ao banco de dados na Zona 'us-east-1b', você paga $0,01 por GB em cada ponta ($0,02/GB no total). Mantenha serviços de comunicação frequente alinhados na mesma AZ ou use topologias de rede conscientes de zona.

O provisionamento de infraestrutura costuma ser guiado pelo "medo da lentidão". Engenheiros escolhem uma instância t3.xlarge (4 vCPU, 16 GB RAM) para uma API que tem pico de 30 requisições por segundo.

O checklist de Right-sizing: * **Analise os percentis P95 e P99 de CPU/RAM**: Olhe o histórico dos últimos 30 dias no CloudWatch, Google Cloud Monitoring ou Datadog. Se o consumo de CPU em P99 não passa de 25%, você está pagando o quádruplo do que precisa. * **Migre para processadores baseados em ARM (AWS Graviton / GCP Tau T2A)**: As famílias baseadas em ARM (como instâncias `t4g`, `c7g`, `m7g` na AWS ou `c3a` no GCP) custam cerca de **20% menos** e entregam até **40% mais performance por watt** para workloads em Node.js, Go, Python, Java e bancos como PostgreSQL e Redis. A compilação multi-arch no Docker hoje é trivial (`docker buildx --platform linux/arm64`). * **Adote escalabilidade horizontal orientada a métricas reais**: Em vez de manter duas instâncias gigantes ligadas 24/7, mantenha instâncias menores e use Auto Scaling Groups ou orquestradores modernos (como AWS ECS Fargate com regras baseadas em latência de requisição ou fila BullMQ/SQS).

Quando você encerra uma máquina virtual ou exclui um cluster de Kubernetes temporário, os discos de armazenamento anexados nem sempre são apagados automaticamente.

Onde está o lixo eletrônico que cobra na sua fatura: 1. **Volumes EBS Desanexados (Available status)**: Discos que não estão montados em nenhuma máquina continuam cobrando por gigabyte alocado todo santo mês. Um disco GP3 de 500 GB esquecido custa ~$40/mês para armazenar o nada. 2. **Snapshots sem ciclo de vida**: É comum scripts criarem snapshots diários de bancos e volumes de disco sem nunca deletar os antigos. Após 1 ano, você tem 365 snapshots pagando taxa cheia no S3. Configure regras de Lifecycle no AWS Backup ou scripts periódicos para manter apenas os últimos 14 a 30 dias. 3. **IPs Elásticos (Elastic IPs) não associados**: Tanto a AWS quanto o Google Cloud cobram por endereços IPv4 públicos que foram reservados mas não estão atrelados a uma instância ligada. Além disso, desde 2024 a AWS cobra $0,005/hora por qualquer IPv4 público em uso. Sempre que possível, utilize IPv6 ou subnets privadas com balanceadores de carga compartilhados.

Se a sua empresa já encontrou o baseline estável de consumo, pagar preços On-Demand é o equivalente a queimar dinheiro.

Dica de ouro de FinOps: Nunca contrate Savings Plans para 100% da sua infraestrutura logo no primeiro dia. Comece comprometendo 50% a 60% do seu baseline mínimo com prazo de 1 ano. Conforme o produto cresce e você otimiza o código, você aumenta a cobertura gradualmente.

O banco de dados gerenciado (Amazon RDS PostgreSQL, Google Cloud SQL, Azure SQL Database) é tipicamente o item unitário mais caro de um SaaS.

1. 1Ative o Storage Autoscaling com limites sensatos: Em vez de provisionar 1 TB de antemão, inicie com 50 GB e ative o crescimento automático.
2. 2Utilize GP3 em vez de GP2: Na AWS, migrar volumes de banco de GP2 para GP3 reduz o custo de armazenamento em 20% e permite provisionar IOPS e throughput de forma desacoplada da capacidade em gigabytes.
3. 3Implemente uma camada de cache agressiva com Redis: 80% das leituras de um SaaS são repetitivas (perfil do usuário, permissões, configurações do tenant). Cada query evitada no PostgreSQL economiza CPU, I/O e conexões abertas, permitindo rodar em uma instância RDS um nível menor (db.t4g.small em vez de db.t4g.xlarge).

O grande problema de olhar a fatura da AWS ou GCP isolada é que você só vê um número consolidado: *“Gastamos R$ 8.500 de nuvem este mês”*.

Mas o que esse número significa para a saúde do seu negócio? * Qual dos seus clientes gerou a maior parte desse custo? * Aquele cliente corporativo que paga R$ 500/mês está consumindo R$ 650 em consultas de banco e tráfego? * Qual é a margem de contribuição líquida da coorte que entrou em janeiro?

É exatamente essa ponte que o DuckLedger constrói. Ao conectar suas faturas de infraestrutura e provedores de IA aos seus gateways de pagamento (Asaas, Stripe, Pagar.me, Paddle), o DuckLedger reconcilia receita e despesa, permitindo apurar o Unit Economics real por workspace, cliente e produto.

Quando sua equipe de engenharia e finanças enxerga a margem líquida real em tempo real, cortar desperdícios deixa de ser uma tarefa punitiva e se torna uma alavanca direta de rentabilidade para o negócio.