O que é o problema de contas AWS explosivas

Todo desenvolvedor já ouviu alguma historia assim: alguém pública um projeto, o post viraliza no Reddit ou no Hacker News e, no dia seguinte, chega um email da AWS com uma fatura de centenas de dólares. Não e lenda urbana. E uma das armadilhas mais comuns da infraestrutura em nuvem.

A AWS funciona no modelo pay-as-you-go, ou seja, você paga exatamente pelo que usa. Isso e ótimo quando o tráfego e previsível. Mas quando o consumo explode de forma inesperada, os preços escalam junto. E sem alertas configurados você só descobre o estrago no final do mes.

O problema ficou ainda mais frequente com a popularização de ferramentas de IA. Muita gente sobe um app com uma API de modelo de linguagem, esquece de limitar chamadas por usuário e acorda com uma conta altíssima. Entender como a AWS cobra e como se proteger virou habilidade essencial para qualquer dev.

Como funciona o modelo de preços da AWS

A AWS tem mais de 200 serviços, cada um com sua própria lógica de preço. Alguns cobram por hora (EC2), outros por requisição (Lambda, API Gateway), outros por volume de dados trafegados (CloudFront egress, S3) ou por espaço armazenado (S3, RDS). A combinação de vários serviços e onde surgem as surpresas.

O Free Tier da AWS existe para os primeiros 12 meses da conta e cobre limites específicos de cada serviço. Quando o limite e ultrapassado, a cobrança começa imediatamente. Vários serviços também tem Free Tier perpetuo com limites menores, como o Lambda com 1 milhão de invocações gratuitas por mes para sempre.

O fator mais traiçoeiro e a transferência de dados de saída (egress). Dentro da mesma região AWS os dados circulam de graça. Mas qualquer dado que sai para a internet e cobrado. Um app com muitas imagens ou vídeos pode gerar custos significativos só nessa linha da fatura, mesmo sem muitos usuários.

Principais serviços que geram cobranças inesperadas

Conhecer os vilões da fatura ajuda a se proteger desde o inicio do projeto:

  • EC2 sem desligar: instâncias rodando 24h por dia somam rápido. Uma t3.médium custa cerca de 30 dólares por mes. Deixou rodando esquecida em ambiente de dev? A conta aparece no final.
  • RDS Multi-AZ em dev: banco de dados com alta disponibilidade e cobrado em dobro. Para ambientes de desenvolvimento, uma instância simples já resolve e economiza metade do custo.
  • NAT Gateway: um dos itens mais subestimados. Custa por hora de uso e por GB processado. Muita gente cria uma VPC com NAT Gateway e esquece que ele permanece ativo.
  • CloudWatch Logs verbose: logs detalhados gerados por Lambda ou ECS podem acumular gigabytes rapidamente. A ingestão e cobrada por GB e pode surpreender.
  • API Gateway sem rate limit: sem limite de requisições configurado, um pico de tráfego ou um script mal feito pode gerar milhões de chamadas em minutos.

O segredo e auditar seu stack antes de ir para produção e entender exatamente o que cada serviço vai gerar de custo em cenários de alto tráfego ou de uso inesperado.

Como começar: configurar alertas e limites de custo

O primeiro passo e acessar o AWS Cost Management no console e criar um orçamento com o serviço AWS Budgets. Você define um valor mensal máximo e configura alertas por email ou SNS quando atingir 50%, 80% e 100% do orçamento. O serviço e gratuito para os primeiros dois orçamentos por conta.

Passo a passo básico para configurar um budget:

  • No console AWS, acesse "Billing and Cost Management" e depois "Budgets"
  • Clique em "Create budget" e escolha "Cost budget"
  • Defina o valor máximo mensal desejado
  • Configure alertas em 80% e 100% do valor definido
  • Adicione seu email como destinatário dos alertas

Além dos Budgets, ative o AWS Cost Anomaly Detection. Ele usa machine learning para identificar picos de gasto fora do padrão e avisa antes de virar fatura. Para apps em Lambda, configure sempre um Reserved Concurrency para limitar o número máximo de execuções paralelas e evitar explosões de custo em picos de tráfego.

Exemplo prático: o app que viralizou

Imagine um desenvolvedor indie que construiu uma ferramenta de geração de imagens com IA, hospedou tudo na AWS e dormiu tranquilo. O projeto apareceu em um fórum popular, ganhou destaque e em poucas horas teve dezenas de milhares de usuários acessando ao mesmo tempo.

Sem limite de concorrência no Lambda, cada request gerava uma execução independente. Sem cache configurado no CloudFront, cada imagem era processada do zero pela API. Sem controle de egress planejado, cada imagem gerada era transferida diretamente do S3 para o usuário via internet. O resultado: decenas de GB de egress em uma noite, mais milhões de invocações Lambda acima do free tier.

Com um CloudFront na frente do S3 e um limite de execuções simultâneas no Lambda, o custo teria sido uma fração do que foi. O aprendizado principal: simular cenários de pico antes de publicar e tao importante quanto testar funcionalidades. O custo em produção real raramente se parece com o custo em desenvolvimento.

Comparação com alternativas

A AWS não e a única opcao. Para projetos menores ou preços mais previsíveis, existem alternativas relevantes no mercado:

  • Vercel e Netlify: cobranças mais previsíveis para frontends e serverless. O plano Pro tem limites claros por mes. Ótimo para apps estáticos ou Next.js sem surpresas de egress.
  • Railway e Render: foco em simplicidade e preço fixo mensal. Ideal para backends e bancos de dados sem as variáveis de custo complexas da AWS.
  • Google Cloud (GCP): modelo similar ao AWS, mas com créditos iniciais generosos para novas contas. Interface de billing considerada mais clara por muitos devs.
  • Azure: forte integração com ecossistema Microsoft. Pricing similar ao AWS, com vantagens para quem já usa .NET e SQL Server no ambiente corporativo.

A AWS ainda ganha em profundidade de serviços e ecossistema. Para quem precisa de controle granular sobre infraestrutura complexa, e difícil substituir. Mas para apps simples que precisam escalar sem risco de susto na fatura, plataformas com preço previsível podem ser a escolha mais segura para começar.

Pontos positivos e limitações

Pontos positivos da AWS:

  • Maior catalogo de serviços do mercado, com mais de 200 opcoes
  • Infraestrutura global com baixa latência em qualquer região do mundo
  • Documentação extensa e comunidade enorme de desenvolvedores
  • Free Tier generoso para experimentação inicial
  • Ferramentas poderosas de cost management quando bem configuradas

Limitações reais que você vai encontrar:

  • Precificação complexa com dezenas de variáveis por serviço
  • Sem limite de gasto automático por padrão: você pode gastar qualquer valor sem trava
  • Curva de aprendizado alta para iniciantes em cloud
  • Egress de dados e caro e frequentemente subestimado em apps com midia
  • Suporte técnico básico e pago a partir de valores mensais fixos

A limitação mais crítica para devs indie e startups iniciais e a ausência de um limite de gasto absoluto nativo. A AWS permite configurar alertas, mas não trava automaticamente o consumo quando o orçamento estoura. Configurar isso corretamente exige conhecimento de AWS Organizations e Service Control Policies, o que adiciona complexidade.

Casos de uso reais

Quem costuma ser surpreendido com a fatura da AWS:

  • Desenvolvedores indie: lançam um side project, o projeto viraliza e o custo explode antes de qualquer monetização. A solução e limitar concorrência e configurar budget alert imediatamente após criar a conta.
  • Startups em fase inicial: ambientes de staging e dev esquecidos rodando 24h. Uma rotina de desligar instâncias fora do horário comercial pode economizar mais de 60% do custo mensal nesses ambientes.
  • Apps com conteúdo gerado por IA: cada chamada para APIs de modelos de imagem ou texto tem custo variável. Rate limit por usuário e obrigatório para manter o custo previsível em produção.
  • Projetos de hackathon e estudo: criam recursos para testar, esquecem de deletar. Um lifecycle policy no S3 e um scheduler para desligar EC2 fora de uso resolve esse problema de forma automática.

Dicas e boas práticas

O que desenvolvedores experientes fazem desde o inicio do projeto:

  • Budget Alert no dia 1: antes de criar qualquer recurso, configure um orçamento com alerta em 80%. Isso da visibilidade imediata de qualquer gasto inesperado.
  • Tag em tudo: use tags como "projeto=meuapp" e "ambiente=dev" em todos os recursos. O Cost Explorer mostra gastos por tag e facilita identificar o que esta custando mais.
  • Reserved Concurrency no Lambda: defina sempre um limite máximo de execuções simultâneas. Sem isso, uma rajada de tráfego pode gerar milhões de invocações rapidamente.
  • Lifecycle policies no S3: configure para deletar objetos temporários automaticamente após alguns dias. Logs e arquivos de upload temporário acumulam rápido sem que você perceba.
  • Revise o Free Tier mensalmente: o AWS Cost Explorer tem uma secao específica para uso do Free Tier. Monitore o que esta próximo do limite antes que gere cobrança.

Erros clássicos de iniciantes: deixar EC2 rodando nos fins de semana, criar RDS Multi-AZ para ambiente de dev e esquecer NAT Gateways ativos em VPCs que não estão sendo usadas. Cada um desses pode gerar dezenas a centenas de dólares por mes sem gerar nenhum valor real para o projeto.

Vale a pena usar AWS?

Para quem precisa de infraestrutura robusta, escalável e com amplo catalogo de serviços: sim, vale muito a pena. A AWS continua sendo a referência do mercado por bons motivos. O problema não e a plataforma, e não conhecer como ela cobra antes de usar em produção.

Para quem esta começando, a recomendação e clara: experimente o Free Tier com cautela, configure alertas de custo antes de qualquer outra coisa e leia a documentação de pricing de cada serviço que for usar. Uma hora investida nisso economiza muito estresse e dinheiro no futuro.

O próximo passo prático: acesse o AWS Pricing Calculator em calculator.aws e simule o custo do seu app no cenário de pior caso, com tráfego 10 vezes maior do que você espera. Se o número resultante não te assustar, você esta no caminho certo para ir para produção com tranquilidade.