O pesadelo que nenhum dev quer ter

Você lança um projeto pequeno, coloca na AWS, paga uns centavos por mes e esquece. Ai um dia o app aparece no Hacker News, no Reddit, ou alguém com milhões de seguidores twitta sobre ele. Em 6 horas, o tráfego vai de 100 para 100 mil usuários simultâneos.

Até ai tudo bem - a AWS escala automaticamente. O problema e a fatura que chega no final do mes. Casos reais de devs relatam contas de US$ 30 mil, US$ 50 mil, até US$ 100 mil por um único evento de tráfego. Sem limite, sem alerta, sem proteção.

Isso não e ficção. Acontece com frequência suficiente para ter um nome na comunidade: 'bill shock'. E a triste realidade e que a AWS não cancela a cobrança só porque você não sabia o que estava fazendo.

Como a fatura explode: entendendo o modelo de preços

A AWS cobra por uso. Parece simples, mas a complexidade esta nos detalhes. Cada serviço tem sua própria lógica de preços: EC2 cobra por hora de instância, Lambda cobra por número de invocações e GB-segundo de memoria, S3 cobra por armazenamento E por requisições de leitura, RDS cobra por instância e storage, CloudFront cobra por GB transferido e por número de requisições.

O problema e que esses custos se multiplicam. Um usuário que abre sua página pode gerar dezenas de requisições para o S3, uma chamada Lambda, consultas ao RDS e transferência de dados pelo CloudFront. Multiplique isso por 100 mil usuários simultâneos durante horas.

Outro fator ignorado: a transferência de dados entre regiões AWS e entre serviços pode ser cara. Muita gente não sabe que mover dados de uma região para outra ou para fora da AWS tem custo por GB.

Os principais vilões da conta

Com base em relatos da comunidade e na estrutura de preços da AWS, esses são os serviços que mais assustam quando o tráfego explode:

  • Data Transfer Out: cada GB enviado para a internet tem custo. Aplicações com muitos assets (imagens, vídeos, downloads) explodem aqui.
  • Lambda com alta concorrência: funções que demoram mais do que o esperado e escalam para milhares de execuções simultâneas.
  • RDS sem connection pooling: banco relacional sem PgBouncer ou RDS Proxy abre uma conexão por request, gerando custos de instância maior e possível travamento.
  • NAT Gateway: tráfego de subnets privadas para a internet passa pelo NAT Gateway e e cobrado por GB. Fácil de esquecer, caro de escalar.
  • Elastic Load Balancer (ALB/NLB): cobrado por hora e por LCU (Load Balancer Capacity Units). Pico de tráfego = pico de LCUs = conta alta.

Como configurar alertas antes que seja tarde

O primeiro passo e criar um AWS Budget. Va em AWS Budgets no console, crie um orçamento mensal e configure alertas por email quando o custo projetado ultrapassar 50%, 80% e 100% do limite. Isso não impede o gasto, mas pelo menos você fica sabendo.

O segundo passo e configurar alarmes no CloudWatch para métricas críticas. Monitorar: número de invocações Lambda por minuto, número de conexões ativas no RDS, bytes transferidos pelo CloudFront. Quando qualquer um desses ultrapassar um limite saudável, você recebe um alerta no SNS ou email.

Para um controle mais rigoroso, use o AWS Cost Anomaly Detection. Ele usa machine learning para identificar gastos fora do padrão e alerta automaticamente. E gratuito para configurar.

Arquitetura para sobreviver a um pico sem pagar fortuna

A escolha da arquitetura impacta diretamente no custo em picos. Algumas estratégias práticas:

Use CloudFront na frente de tudo. Assets estáticos (imagens, CSS, JS) servidos pelo CloudFront tem custo muito menor do que servir do EC2 ou S3 diretamente. Além disso, o cache do CloudFront reduz o número de requisições que chegam no seu backend.

Para APIs, considere rate limiting na borda com WAF ou Lambda@Edge. Limitar requisições por IP impede que um único cliente (ou bot) gere milhares de chamadas e exploda sua conta.

S3 com lifecycle policies: objetos antigos ou temporários que você não precisa acessar com frequência devem ir para S3 Glacier. O armazenamento e até 10 vezes mais barato.

Comparação: AWS vs alternativas para quem quer previsibilidade

A AWS e poderosa, mas o modelo de preços pode ser imprevisível para projetos com tráfego variável. Algumas alternativas merecem atenção:

Cloudflare Workers + Pages: execução de código na borda com plano generoso gratuito. Para muitos casos de uso, substitui Lambda com custo previsível. Vercel e Netlify: ótimos para frontends e APIs simples, com planos com limites claros e preços fixos. Fly.io e Railway: mais previsibilidade com cobranças por container ativo, sem surpresa de tráfego de saída.

Para projetos sérios que precisam da AWS, o segredo e usar Reserved Instances ou Savings Plans para workloads previsíveis. Você paga menos por hora em troca de um compromisso de 1 ou 3 anos.

Pontos positivos e limitações da AWS

A AWS tem vantagens inegáveis: escala global, serviços maduros, integração entre tudo, documentação extensa e uma comunidade enorme. Para startups que precisam crescer rápido, poucas plataformas chegam perto.

Mas as limitações são reais. O console e complexo e intimidador para quem esta começando. A curva de aprendizado e longa. E o modelo de preços tem mais de 100 páginas de documentação só para o EC2. Erros de configuração custam caro e a AWS raramente da credito por erro humano.

Outra limitação prática: sem um time de FinOps ou pelo menos um profissional dedicado a otimização de custos, a fatura da AWS tende a crescer com o tempo mesmo sem crescimento real de tráfego.

Quem passa mais por isso

Devs solo com side projects: lançam algo no Hacker News ou Product Hunt, viraliza por um dia, pagam uma fatura inesquecível. São os relatos mais dramáticos da internet. Startups em fase inicial: sem governança de custos, cada sprint adiciona serviços sem calcular o custo marginal. A conta cresce sem ninguém perceber até o final do mes. Times que migram de infraestrutura: ao mover de VPS fixo para AWS, o modelo de custos muda completamente. O que era R$ 500/mes em servidor pode virar R$ 5.000/mes sem configuração correta. Projetos de machine learning: instâncias GPU (p3, p4d) tem custo por hora muito alto. Uma instância esquecida rodando por um fim de semana pode custar centenas de dólares.

Dicas práticas para não se queimar

Antes de lançar qualquer coisa na AWS, faca o exercício mental: e se isso receber 1 milhão de requisições hoje? Abra a calculadora de preços da AWS (AWS Pricing Calculator) e simule o pior cenário. Surpreende o quanto o número pode ser grande.

Habilite o AWS Free Tier Alerts mesmo que você não esteja mais no free tier. Ele monitora serviços que costumam ter consumo inesperado. Configure uma política de SCP (Service Control Policy) nas contas da organização para bloquear serviços que você nunca vai usar - isso evita que uma configuração errada ative algo caro.

E fundamental: nunca deixe credenciais AWS expostas no código. Se uma chave de acesso com permissões amplas vazar, alguém pode minerar criptomoedas na sua conta e você recebe a fatura. Use IAM Roles em vez de access keys sempre que possível.

Vale usar a AWS mesmo assim?

Sim, mas com conhecimento. A AWS e a plataforma mais completa disponível e não ha motivo para evita-la por medo de custos - desde que você configure alertas, entenda o modelo de preços dos serviços que usa e adote uma arquitetura com custo previsível.

Se você esta começando, considere começar com serviços de preços fixos (Vercel, Railway, Cloudflare) e mover para AWS quando o projeto justificar a complexidade. Para quem já usa AWS, o investimento de uma tarde configurando budgets, alertas e revisando arquitetura pode evitar um prejuízo sério.

O próximo passo: abra o AWS Cost Explorer agora e veja os últimos 3 meses de gastos por serviço. Você provavelmente vai se surpreender com o que esta pagando sem perceber.