Reduzindo o custo da AWS em US$ 150 mil por ano simplesmente desligando coisas

Artigo original ↗ Discussão no Hacker News ↗

A otimização de custos em cloud está surgindo como uma grande preocupação, à medida que engenheiros relatam cortar dezenas ou centenas de milhares de dólares simplesmente auditando a infraestrutura e desligando recursos da AWS não usados ou superdimensionados. Os participantes descrevem como a falta de visibilidade de custos, incentivos desalinhados e a cultura da gestão levam a anos de desperdício — enquanto ferramentas, práticas de FinOps, tagging e automação podem reduzir os gastos de forma sistemática. O debate também aborda trade-offs mais amplos, de serverless vs. bare metal e lock-in de fornecedor até se funcionários que geram grandes economias deveriam compartilhar diretamente dos ganhos financeiros.

Economias de Custo Observadas e Frutos Fáceis

  • Muitos comentaristas relatam economias enormes, “embaraçosamente fáceis”, ao desligar recursos não utilizados ou redimensionar corretamente:
    • Reduzir contas individuais de centenas de milhares por mês para uma fração.
    • Encontrar pipelines S3 abandonados ou bancos de dados de teste custando centenas de milhares a milhões por ano.
    • Descobrir artefatos de CI como node_modules sendo enviados para o S3 e baixados por clientes, adicionando custos de transferência de seis dígitos por ano.
  • Culpados comuns: clusters de teste esquecidos, logs com retenção infinita, infraestrutura de dev/test superdimensionada, NAT gateways e VMs/volumes EBS antigos que ninguém possui.

Incentivos, Bônus e Efeitos Perversos

  • Tema recorrente: engenheiros que economizam muito dinheiro raramente veem bônus proporcionais; muitas vezes recebem mais reuniões ou, no máximo, um reconhecimento discreto.
  • Alguns argumentam que isso desencoraja a otimização de custos (“por que se dar ao trabalho?”), outros dizem “isso é só fazer o seu trabalho”.
  • Pagar uma porcentagem da economia é atraente, mas visto como propenso a abuso (“cobra farming”: inflar e depois “otimizar”).

Visibilidade, FinOps e Acesso à Faturação

  • “Você não pode otimizar o que não pode ver”: forte ênfase em painéis, tagging, relatórios semanais de custo e práticas formais de FinOps.
  • Vários reclamam que devs são bloqueados dos consoles de faturação, tornando impossível perceber picos acidentais de custo.
  • Quando custos e descontos privados são mantidos em segredo pela gestão, os engenheiros deixam de tentar otimizar.

Ambientes de Dev/Staging e Automação

  • Ambientes não produtivos podem custar mais do que produção se ficarem sempre ligados ou cheios de dados de teste.
  • Estratégias populares: agendamentos de desligamento automático, políticas de opt-out apoiadas por tags, bots que impõem tempos de vida e ferramentas que eliminam recursos não usados.
  • Algumas equipes vão além com clusters EKS “blue-green” ou configurações serverless/Knative que escalam para zero.

Escolhas de Plataforma em Nuvem e Arquiteturas

  • Debate sobre migrar de grandes clouds para provedores mais baratos como Hetzner ou bare metal:
    • Pró: potencial de economia de 10x se você não precisar de serviços gerenciados ou SLAs rigorosos.
    • Contra: você reimplementa os serviços gerenciados por conta própria e paga em tempo de engenharia e risco de confiabilidade.
  • Serverless pode cortar custos drasticamente para cargas com picos ou de desenvolvimento, mas muitas vezes exige uma reestruturação substancial.

Cultura Organizacional e Prioridades

  • Muitos veem o desperdício como produto da cultura: entrega apressada de funcionalidades, falta de revisões de prontidão para produção e compromissos de cloud que reduzem os incentivos para cortar custos.
  • Para grandes empresas, até economias de vários milhões de dólares podem ser tratadas como erro de arredondamento; para pequenas empresas, isso é existencial.