Otimização de Custos na Nuvem: Pare de Pagar Demais pelo Seu MVP

No último trimestre, auditei a fatura da AWS de uma startup e descobri que estavam gastando US$ 2.800/mês em infraestrutura que poderia rodar confortavelmente por US$ 900. Tinham uma t3.2xlarge rodando uma API Node.js que atingia pico de 12% de utilização de CPU. Três Elastic IPs não utilizados parados a US$ 3,65/mês cada. Um deployment RDS Multi-AZ para um banco de dados com 200 linhas. Um NAT gateway roteando tráfego que poderia ter ido por um VPC endpoint gratuitamente. Nada disso era malicioso ou particularmente descuidado — era o acúmulo de decisões de "provisiona algo que funcione" tomadas durante um sprint para lançar.

Isso é a norma, não a exceção. A maioria das startups em estágio inicial desperdiça 40-60% dos seus gastos com nuvem porque ninguém no time tem tempo ou incentivo para otimizar custos quando há funcionalidades para entregar. O problema se agrava: uma vez que a infraestrutura está provisionada e funcionando, ninguém mexe.

As Maiores Armadilhas de Custo que Continuo Vendo

Antes de mergulhar nas soluções, ajuda entender para onde o dinheiro realmente vai. Essas são as armadilhas que encontro com mais frequência ao revisar infraestrutura de startups.

Instâncias de Computação Superdimensionadas

Esta é a maior fonte individual de desperdício. Equipes escolhem um tamanho de instância durante a configuração inicial — geralmente baseado em um post de blog ou uma mentalidade de "só por segurança" — e nunca revisitam. Já vi instâncias m5.xlarge rodando cron jobs que executam por 30 segundos a cada hora. A instância fica ociosa por 59,5 minutos, queimando US$ 0,192/hora (US$ 140/mês) para fazer essencialmente nada.

A causa raiz é psicológica: ninguém quer ser a pessoa que subdimensionou o servidor e causou uma queda. Então todos arredondam para cima. Duas vezes.

# Check your EC2 instance CPU utilization over the past 2 weeks
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abcdef1234567890 \
  --start-time $(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum

Se sua utilização média de CPU está abaixo de 20% e seu pico abaixo de 50%, você está quase certamente superdimensionado. Reduza um ou dois tamanhos de instância, monitore por uma semana e ajuste.

Volumes EBS e Snapshots Esquecidos

Quando você termina uma instância EC2, os volumes EBS vinculados não são automaticamente excluídos a menos que você tenha configurado isso no lançamento. Isso significa que instâncias terminadas deixam volumes órfãos que continuam cobrando. Já vi contas com dezenas de volumes gp3 desvinculados, cada um custando US$ 0,08/GB/mês, totalizando centenas de dólares por armazenamento que ninguém está usando.

Snapshots são ainda mais sorrateiros. Scripts de backup automatizados criam snapshots diários sem política de ciclo de vida, então acumulam indefinidamente. Um volume de 500GB com snapshot diário por um ano gera 365 snapshots, e embora snapshots EBS sejam incrementais, os custos se somam.

# Find all unattached EBS volumes
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

# Find snapshots older than 90 days
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-12-01`].{ID:SnapshotId,Size:VolumeSize,Date:StartTime}' \
  --output table

NAT Gateway: O Assassino Silencioso do Orçamento

NAT gateways custam US$ 0,045/hora (US$ 32,40/mês) apenas para existir, mais US$ 0,045 por GB de dados processados. Para uma startup fazendo chamadas frequentes a APIs de serviços externos a partir de subnets privadas, as cobranças de processamento de dados sozinhas podem ultrapassar US$ 100/mês. Já vi cobranças de NAT gateway representando 15-20% da fatura total da AWS de uma startup pequena.

A solução depende de qual tráfego está passando pelo NAT:

• Tráfego para serviços AWS (S3, DynamoDB, SQS): Use VPC Gateway Endpoints (gratuitos para S3 e DynamoDB) ou Interface Endpoints (US$ 7,20/mês cada, mas ainda mais baratos que NAT para tráfego de alto volume).
• Tráfego para a internet a partir de funções Lambda: Considere se essas funções realmente precisam estar em uma VPC. Muitas funções Lambda são colocadas em uma VPC "por segurança" quando não acessam nenhum recurso da VPC.
• Tráfego de saída de baixo volume: Uma instância NAT em uma t4g.nano (US$ 3,02/mês) lida com tráfego modesto por uma fração do custo do NAT gateway.

Cobranças de Transferência de Dados

A AWS cobra US$ 0,09/GB para dados saindo de uma região, e tráfego entre AZs custa US$ 0,01/GB em cada direção. Essas cobranças são invisíveis até não serem mais. Uma arquitetura de microsserviços com muita comunicação espalhada por três zonas de disponibilidade, com serviços chamando uns aos outros centenas de vezes por segundo, pode gerar faturas de transferência de dados surpreendentes.

A solução arquitetural: co-localize serviços que se comunicam frequentemente na mesma AZ para workloads não-críticos, ou use load balancers internos com afinidade de AZ.

Dimensionamento Correto: Uma Abordagem Sistemática

Dimensionamento correto não é um exercício único. É algo que você deveria revisitar trimestralmente. Aqui está o processo que sigo.

Passo 1: Coletar Dados de Utilização

O AWS Compute Optimizer é gratuito e fornece recomendações de dimensionamento para EC2, EBS, Lambda e ECS. Ative-o e deixe coletar pelo menos 14 dias de dados antes de agir com base nas recomendações.

Para análise mais granular, métricas do CloudWatch são sua fonte principal de dados. As métricas-chave a observar:

• EC2: CPUUtilization, NetworkIn/Out, MemoryUtilization (requer agente CloudWatch)
• RDS: CPUUtilization, DatabaseConnections, FreeableMemory, ReadIOPS, WriteIOPS
• ElastiCache: CPUUtilization, CurrConnections, BytesUsedForCache

Passo 2: Categorizar Workloads

Nem todo workload deve ser dimensionado da mesma forma. Eu os categorizo em três grupos:

Workloads de estado estável (servidores de API, bancos de dados): Esses precisam de capacidade consistente. Dimensione encontrando a menor instância que lida com a carga de pico com 30% de margem. Use Reserved Instances ou Savings Plans para a linha de base.

Workloads variáveis (processamento em lote, servidores de build): Esses devem usar Auto Scaling Groups com políticas de escalonamento apropriadas, ou Spot Instances para jobs em lote tolerantes a falhas.

Workloads periódicos (cron jobs, relatórios agendados): Esses não deveriam rodar em instâncias dedicadas. Mova-os para Lambda, Fargate Spot ou Step Functions.

Passo 3: Agir Incrementalmente

Nunca dimensione tudo de uma vez. Reduza um tamanho de instância por vez, monitore por uma semana, depois decida se vai além. O custo de um breve período de superdimensionamento é muito menor que o custo de uma queda em produção causada por downsizing agressivo.

Reserved Instances vs Savings Plans vs Spot

É aqui que as economias reais acontecem — 30-72% de desconto sobre o preço on-demand — mas a mecânica de compromisso é confusa o suficiente para que muitas startups simplesmente evitem.

Reserved Instances (RIs)

Você se compromete com um tipo de instância específico em uma região específica por 1 ou 3 anos. Em troca, obtém 30-40% de desconto (sem pagamento antecipado, 1 ano) a 60% de desconto (pagamento antecipado total, 3 anos). O ponto de atenção: se precisar mudar o tipo de instância, Standard RIs não são flexíveis. Convertible RIs oferecem mais flexibilidade com um desconto um pouco menor (cerca de 45% para 3 anos com pagamento antecipado total).

Quando usar RIs: Bancos de dados e outros workloads onde o tipo e tamanho da instância são genuinamente estáveis. RDS Reserved Instances quase sempre valem a pena — bancos de dados raramente mudam de tamanho.

Savings Plans

Savings Plans são a alternativa moderna às RIs para computação. Você se compromete com um valor em dólares de computação por hora (por exemplo, US$ 0,10/hora) por 1 ou 3 anos. O compromisso se aplica automaticamente ao uso de EC2, Fargate e Lambda, e é flexível entre famílias de instância, tamanhos, SO e regiões.

Quando usar Savings Plans: Quase sempre preferível a EC2 RIs para workloads de computação. Compute Savings Plans oferecem a melhor relação flexibilidade-desconto. Comece com um compromisso que cubra seu gasto mínimo de base.

# Example: Calculating Savings Plan commitment
# Current on-demand spend: $500/month on EC2
# Minimum baseline (never drops below): $350/month
# Recommended Savings Plan commitment: $350/month = ~$0.48/hour
# Expected savings: ~30% on the committed amount = ~$105/month
# Remaining $150/month stays on-demand for flexibility

Spot Instances

Spot Instances oferecem 60-90% de desconto mas podem ser interrompidas com 2 minutos de aviso. São ideais para:

• Agentes de build CI/CD (use Spot Fleet com múltiplos tipos de instância)
• Jobs de processamento em lote que podem fazer checkpoint e retomar
• Ambientes de desenvolvimento e staging
• Testes de carga

Não são adequadas para servidores de API em produção, bancos de dados ou qualquer coisa que não possa lidar com terminação repentina.

# Example: GitHub Actions self-hosted runner on Spot
# This saves roughly 70% compared to GitHub-hosted runners
# for compute-heavy builds
Resources:
  SpotFleet:
    Type: AWS::EC2::SpotFleet
    Properties:
      SpotFleetRequestConfigData:
        IamFleetRole: !GetAtt SpotFleetRole.Arn
        TargetCapacity: 2
        AllocationStrategy: lowestPrice
        LaunchSpecifications:
          - InstanceType: c5.xlarge
            SpotPrice: "0.06"
          - InstanceType: c5a.xlarge
            SpotPrice: "0.06"
          - InstanceType: c6i.xlarge
            SpotPrice: "0.06"

Modelos de Custo Serverless: Nem Sempre Mais Barato

Existe um mito persistente de que serverless é sempre mais barato para startups. Frequentemente é mais barato em baixa escala, mas a economia muda conforme o tráfego cresce.

Realidade de Preços do Lambda

O Lambda cobra por requisição (US$ 0,20 por milhão) e por GB-segundo de computação (US$ 0,0000166667). Para um endpoint de API típico que roda por 200ms com 256MB de memória:

• 1.000 requisições/dia: ~US$ 0,03/mês. Efetivamente gratuito.
• 100.000 requisições/dia: ~US$ 3,00/mês. Ainda muito barato.
• 1.000.000 requisições/dia: ~US$ 30/mês. Começando a se comparar com uma instância EC2 pequena.
• 10.000.000 requisições/dia: ~US$ 300/mês. Uma t3.medium (US$ 30/mês) com cache adequado lida com isso facilmente.

O ponto de cruzamento depende muito da duração de execução e alocação de memória, mas para a maioria dos workloads de API, o Lambda deixa de ser custo-eficiente em algum lugar entre 1-5 milhões de requisições por dia. Abaixo desse limite, é quase sempre a opção mais barata.

Os Custos do API Gateway se Acumulam

As pessoas esquecem que funções Lambda atrás do API Gateway incorrem em cobranças adicionais. O API Gateway custa US$ 3,50 por milhão de requisições (REST API) ou US$ 1,00 por milhão (HTTP API). Em escala, o custo do API Gateway excede o custo do Lambda. Se você está rodando tráfego suficiente para se preocupar com custos do Lambda, deveria estar usando Application Load Balancer (US$ 0,008 por LCU-hora) em vez de API Gateway.

Fargate: O Meio-Termo

AWS Fargate fica entre Lambda e EC2 tanto em custo quanto em complexidade operacional. Você paga por vCPU e memória por segundo, sem gerenciamento de instância. Para workloads que precisam rodar continuamente mas você não quer gerenciar servidores, Fargate com capacity providers Spot oferece um bom equilíbrio.

Uma task Fargate com 0,25 vCPU e 0,5GB de memória custa cerca de US$ 9/mês rodando continuamente. Isso é competitivo com uma t4g.nano e você obtém posicionamento automático, health checks e escalonamento sem gerenciar o host subjacente.

Monitoramento e Alertas de Custos

Você não pode otimizar o que não mede. Aqui está o stack de monitoramento que configuro para cada projeto.

AWS Cost Explorer

Ative o Cost Explorer e configure um orçamento mensal com alertas nos limites de 50%, 80% e 100%. Isso é o mínimo. A visão "Custo por Serviço" do Cost Explorer mostra imediatamente para onde o dinheiro está indo.

# Create a budget with email alerts
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "Monthly-Total",
    "BudgetLimit": {"Amount": "500", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "team@startup.com"
    }]
  }]'

Infracost para Infraestrutura como Código

Se você usa Terraform, o Infracost se integra ao seu pipeline de CI e mostra estimativas de custo para cada mudança de infraestrutura antes de ser aplicada. Isso é transformador — muda a consciência de custos de uma surpresa mensal para uma conversa de pull request.

# .github/workflows/infracost.yml
name: Infracost
on: pull_request
jobs:
  infracost:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Infracost
        uses: infracost/actions/setup@v3
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}
      - name: Generate cost estimate
        run: |
          infracost breakdown --path=. \
            --format=json --out-file=/tmp/infracost.json
          infracost comment github \
            --path=/tmp/infracost.json \
            --repo=$GITHUB_REPOSITORY \
            --pull-request=${{ github.event.pull_request.number }} \
            --github-token=${{ secrets.GITHUB_TOKEN }}

Detecção de Anomalias de Custo

O AWS Cost Anomaly Detection usa machine learning para identificar padrões de gasto incomuns. É gratuito e envia alertas quando o gasto desvia dos padrões históricos. Ative-o para cada serviço e configure notificações SNS para o Slack.

Padrões de Arquitetura que Economizam Dinheiro

Além de dimensionar corretamente recursos individuais, certas decisões arquiteturais mudam fundamentalmente sua estrutura de custos.

Cache Agressivo

Uma distribuição CloudFront na frente da sua API para respostas cacheáveis custa US$ 0,085/10.000 requisições HTTPS e US$ 0,085/GB de transferência — mas elimina essas requisições de atingir seu backend. Para APIs de leitura intensiva (que a maioria é), uma taxa de cache hit de 90% significa que seu backend lida com 10x menos tráfego.

Ainda mais simples: um cache em memória como Redis ou apenas um cache LRU local na sua aplicação pode eliminar queries redundantes ao banco de dados. Já vi custos de banco de dados cair 60% após adicionar um cache de 15 minutos nos 5 endpoints mais acessados.

Use o S3 de Forma Inteligente

O S3 tem múltiplas classes de armazenamento, e usar a certa importa:

Classe de Armazenamento	Custo/GB/mês	Caso de Uso
S3 Standard	US$ 0,023	Dados ativos, acesso frequente
S3 Infrequent Access	US$ 0,0125	Backups, logs com mais de 30 dias
S3 Glacier Instant	US$ 0,004	Arquivos que precisam de acesso imediato
S3 Glacier Deep Archive	US$ 0,00099	Arquivos de longo prazo, acesso raro

Configure S3 Lifecycle Policies para transicionar objetos automaticamente entre classes de armazenamento:

{
  "Rules": [
    {
      "ID": "TransitionToIA",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_INSTANT_RETRIEVAL"
        }
      ]
    }
  ]
}

Serviços Gerenciados vs Auto-Hospedados

Esse tradeoff é nuançado. Serviços gerenciados (RDS, ElastiCache, OpenSearch Service) custam mais por unidade de computação que auto-hospedagem em EC2, mas incluem patches, backups, failover e monitoramento. Para uma startup sem uma pessoa dedicada de ops, o tempo de engenharia economizado quase sempre justifica o premium.

A exceção: serviços gerenciados nos tiers mais altos. Uma instância RDS db.r6g.2xlarge custa significativamente mais que a instância EC2 equivalente rodando PostgreSQL. Uma vez que você tenha uma equipe capaz de ops e esteja gastando mais de US$ 1.000/mês em um único serviço gerenciado, vale avaliar auto-hospedagem.

Consolide Onde Possível

Rodar instâncias RDS separadas para staging, QA e ambientes de desenvolvimento é caro. Opções:

• Use uma única instância RDS com bancos de dados separados para ambientes não-produção.
• Use Aurora Serverless v2 para dev/staging — ele escala a zero quando ocioso.
• Rode bancos de desenvolvimento em uma única EC2 Spot Instance com Docker.

Um Playbook Real de Otimização de Custos

Aqui está o processo passo a passo que sigo ao assumir um projeto de otimização de custos. Isso tipicamente alcança 30-50% de economia no primeiro mês.

Semana 1: Auditoria

1. Ative o AWS Cost Explorer se ainda não estiver ativo.
2. Puxe uma análise de custos de 3 meses por serviço.
3. Identifique os 5 principais serviços por gasto.
4. Execute o AWS Compute Optimizer e o Trusted Advisor.
5. Liste todos os volumes EBS desvinculados, Elastic IPs não utilizados e load balancers ociosos.

Semana 2: Vitórias Rápidas

1. Exclua recursos não utilizados identificados na auditoria.
2. Dimensione corretamente as instâncias mais superdimensionadas (1 tamanho abaixo, monitorar).
3. Configure VPC endpoints para tráfego S3 e DynamoDB.
4. Ative S3 Lifecycle Policies em todos os buckets.
5. Configure alertas de orçamento.

Semana 3: Compromissos

1. Analise workloads de estado estável para elegibilidade de Savings Plan.
2. Compre Compute Savings Plans para gasto computacional de base.
3. Compre RDS Reserved Instances para bancos de dados de produção.
4. Converta workloads adequados para Spot Instances.

Semana 4: Arquitetura

1. Adicione camadas de cache onde apropriado.
2. Avalie migração serverless para workloads adequados.
3. Consolide ambientes não-produção.
4. Configure Infracost no pipeline de CI.
5. Documente a linha de base de custos para monitoramento contínuo.

O que Não Otimizar

Otimização de custos tem retornos decrescentes, e algumas "economias" criam mais problemas do que resolvem.

Não sacrifique confiabilidade por custo. Rodar um banco de dados de produção em deployment single-AZ para economizar nas cobranças Multi-AZ é falsa economia. A primeira queda vai custar mais que anos de premiums Multi-AZ.

Não otimize demais para a escala atual. Se sua startup está crescendo 20% mês a mês, gastar uma semana otimizando um serviço de US$ 50/mês não é bom uso do tempo. Foque nos itens de valor alto.

Não lute contra o modelo de preços do provedor de nuvem. A AWS é projetada para ser cara se você lutar contra suas convenções. Use serviços gerenciados da forma como foram planejados, aproveite os tiers gratuitos e utilize os descontos de compromisso que oferecem. Tentar contornar os preços com arquiteturas excessivamente inteligentes geralmente sai pela culatra.

Não remova monitoramento para economizar dinheiro. CloudWatch custa dinheiro, mas voar às cegas custa mais. Os US$ 15/mês que você gasta em monitoramento detalhado vão te salvar da surpresa de US$ 500 que o monitoramento detalhado teria capturado.

O Efeito Composto

O maior argumento para otimização de custos precoce não é a economia imediata — são os hábitos e a infraestrutura que você coloca em prática. Uma startup que configura alertas de orçamento, usa Infracost no CI e revisa custos mensalmente vai manter infraestrutura eficiente conforme escala. Uma startup que ignora custos até a série B vai se encontrar com faturas de US$ 30.000/mês na AWS que levam seis meses de esforço dedicado para desembaraçar.

Comece com a auditoria. Os números vão te dizer onde focar.