Histórias de terror do serverless

• Há muitos casos frequentes de cobranças inesperadas e de grande valor em vários serviços SaaS e serverless, e esta é uma página que os organiza de forma clara
• Foram revelados casos em que usuários que pagavam normalmente a assinatura mensal receberam cobranças de dezenas a centenas de milhares de dólares em apenas um dia por causa de ataques DoS ou uso descontrolado de recursos
• Em alguns serviços, ficaram evidentes limitações sistêmicas, como a cobrança de valores extras mesmo com limites de gastos configurados
• Na comunidade de desenvolvedores, experiências desse tipo vêm sendo compartilhadas, e a estrutura de cobrança sem sentido e a falta de transparência são apontadas como os principais problemas
• Em ambientes serverless e de nuvem, um erro pequeno ou um único ataque pode causar enormes prejuízos financeiros, o que reforça a necessidade de cautela

---

Coletânea de casos de cobranças excessivas em serviços serverless e SaaS

#1 Cobrança altíssima no Webflow

• Durante o uso de um plano de US$ 69 por mês, foi cobrado US$ 1.189,42 por um único mês sem motivo aparente

#2 Caso de ataque DoS em site de jogos WebGL

• O operador de um site de médio porte para upload de jogos WebGL recebeu uma cobrança de mais de US$ 100.000 no Google Firebase em apenas um dia após um ataque DoS

#3 Vercel Pro e ultrapassagem do limite de gastos

• Mesmo usando o plano Vercel Pro por US$ 20 ao mês e definindo um limite de gastos de US$ 120, surgiram cobranças adicionais inesperadas

#4 Cobrança de projeto e conta altíssima

• Surgiu um caso em que um projeto que pagava US$ 50 por mês recebeu, certa manhã, uma fatura de US$ 70.000

#5 Uso do BigQuery e problema de cobrança com dataset público

• Ao usar BigQuery em um ambiente de playground, foi gerada uma cobrança enorme de mais de US$ 22.000

#6 Taxa de hospedagem excessiva em relação ao pequeno número de visitantes

• Mesmo com 9.000 visitantes mensais, foi cobrada uma taxa mensal de US$ 250, o que exigiria US$ 3.000 por ano

#7 Problema ocorrido após mudança no codebase pelo Devin(AI)

• Houve um relato de consequências inesperadas quando uma IA chamada Devin realizou alterações no código

#8 Cobrança repentina após uso gratuito

• Mesmo sem nunca ter feito um pagamento, surgiu de repente uma cobrança de US$ 530

#9 Cobranças em site de documentação e outros pequenos projetos

• Há muitos casos de cobranças altas mesmo em serviços de baixo uso, como quase US$ 400 cobrados por um simples site de documentação

#10 O terror do free tier

• Até mesmo uma cobrança de cerca de US$ 103 já é vista como um problema. Especialmente durante o uso do free tier, o surgimento repentino de uma fatura é um fator de ansiedade

#11 Cloudflare, AWS e outros problemas

• Houve um caso de interrupção de serviço na Cloudflare com aviso para pagar US$ 120.000 em menos de 24 horas
• Na AWS S3, surgiram cobranças inesperadas mesmo após a criação de um bucket vazio e privado
• Casos semelhantes se repetem em vários fornecedores, como o recebimento de uma fatura em aberto de US$ 104.500 na Netlify

#12 Ataque DoS, e-mail e perda de dados

• Durante um ataque DoS, foram gastos US$ 11.000 com envio de e-mails, e depois o banco de dados também foi perdido

#13 Cobrança massiva na Vercel e problemas com contas e trial

• Na Vercel, um ataque de spam gerou uma cobrança de US$ 23.000 em um único dia, com 56.000 contas e trials ativados

#14 Cobranças inesperadas durante testes/implantação

• Ao implantar funcionalidades para teste em plataformas como a Vercel, foram cobrados valores inesperados
• Um sitemap (sitemap.txt) consumiu centenas de GB de banda, gerando uma cobrança altíssima

#15 Custo de teste com Firebase e Cloud Run

• Apenas dois testes com Firebase e Cloud Run consumiram US$ 72.000, levando o serviço à beira da falência

Conclusão e implicações

• A estrutura de custos em ambientes serverless e de nuvem é opaca ou muito vulnerável a ataques e erros
• Há muitos relatos de cobranças inesperadas, e é indispensável um monitoramento cuidadoso, gestão de uso e configuração de limites permitidos na operação dos serviços
• Se os recursos de automação e monitoramento forem insuficientes, um simples teste ou um único ataque externo pode causar perdas inesperadas de dezenas de milhares de dólares
• A importância da gestão de custos e da percepção de riscos está crescendo para desenvolvedores, startups e outros usuários de SaaS

[ahwjdekf]

Eu trabalhava no desenvolvimento de um DW interno para uma grande empresa, e era um projeto para migrar os dados on-premises existentes para a AWS. Mas, mesmo depois de concluir vários meses de desenvolvimento e testes, no fim tudo foi cancelado. O motivo foi que parecia que o valor cobrado por mês seria muito maior do que o esperado. Até mesmo para grandes empresas, gastar com cloud não é algo simples.

[regentag]

Eu também criei uma conta para estudar AWS e acabei sendo cobrado, embora por um valor pequeno.
Minha conta foi comprometida e alguém criou e executou instâncias usando a minha conta...
Consegui interromper rapidamente, então acabou ficando só em um valor baixo. Como não podia dedicar tempo à administração, acabei resolvendo isso simplesmente apagando a conta.

[ifmkl]

Acho que eu recomendaria, antes de começar com a nuvem, montar um ambiente de mini servidor com essas máquinas de classe n100 ou n150 que andam aparecendo bastante hoje em dia, para acumular um pouco de experiência com testes e operação.

[crawler]

Mesmo sendo um projeto bem pequeno, parece realmente assustador que, só de colocá-lo na plataforma, uma vulnerabilidade possa acabar gerando prejuízo financeiro

Coloquei o Cloudflare na frente do meu conteúdo, mas um hacker encontrou objetos que não estavam em cache e os atingiu mais de 100 milhões de vezes. Quando eu bloqueei, ele até encontrou diretamente o endereço do bucket de origem e atacou por lá

Fico curioso para saber se, nesses casos, eles também reembolsam os custos

[GN⁺]

Opinião no Hacker News

• Quando eu estava aprendendo programação num bootcamp, criei uma instância do Elastic Beanstalk usando o plano gratuito. Era preciso um cartão de crédito para verificar a identidade, e na época não achei que isso pudesse dar problema. Depois, porém, meu servidor sofreu um ataque de spam por bots e a Amazon me cobrou 100 mil dólares. No fim consegui o reembolso, mas desde aquele dia passei a odiar a Amazon e prometi a mim mesmo que, se fosse usar computação em nuvem, escolheria outro serviço. Não gostei daquele painel complicado nem da forma como tudo parecia estruturado para confundir o cliente e fazê-lo perder dinheiro. Teria bastado usar o cartão de crédito só como meio de verificação e bloquear os bots. Comparando com como uma mercearia consegue vender um pacote de biscoitos de forma simples com cartão de crédito, acho que dava para usar tecnologia financeira de um jeito realmente útil, mas não fizeram isso
  • Esse é um dos motivos de hospedagem em nuvem dar medo. Não é só a Amazon; Azure e Google Cloud também “normalmente” reembolsam. Mas se meu projeto demo com 5 visitantes por semana tomar um DDoS de repente e, dessa vez, a empresa de hospedagem decidir que não é um caso “normal” e me mandar pagar por transferência, eu posso acabar à beira da falência
  • No momento estou com uma cobrança de 25 mil dólares. Anos atrás eu tinha ativado a auditoria do data plane do SQS e ligado isso a um feed de eventos de auditoria em tempo real. Como resultado, cada evento puro de auditoria gerava eventos de log num loop infinito. Uma conta que por quase 10 anos custava em média 2 dólares por dia de repente começou a custar 3 mil dólares por dia, e não houve nenhum aviso nem intervenção da AWS
  • Fico curioso por que você odeia a Amazon se eles reembolsaram os 100 mil dólares. No meu caso, a AWS sempre reembolsou cobranças altíssimas que foram totalmente culpa minha. Se existisse uma política de “passou do orçamento, desliga tudo”, também teríamos muitas outras tragédias do tipo “sofri um DDoS, a AWS desligou todas as minhas EC2 e ainda perdi os dados que estavam no armazenamento temporário”
  • “Isso é algo muito fácil de fazer com um if de uma linha: se passar do limite da conta, desliga as instâncias e despeja o serviço num drive estático. Eles simplesmente não quiseram — querem usar a escala para maximizar receita em cima dos clientes. O pessoal que já complicou a vida de todo mundo com cloud compute agora também quer extrair ganho econômico do custo de IA, surfando na captura de mercado. Hoje edge compute ficou mais fácil porque, por causa das criptomoedas, as pessoas investiram demais em discos rígidos. No fim, o mercado incentiva bolhas e mau comportamento, e cria um ambiente onde fica fácil para gente que abusa da própria força dominar o jogo em vez de construir confiança. Esses vilões espertos com aquele ar de ‘você só não entende isso! (ah, e me paga mais um pouco antes do mercado quebrar)’ são o maior pé no saco da indústria. Nem empresa de táxi cobra mil dólares por não te levar ao destino. Fico me perguntando se faz sentido dizer que não dá para colocar um if num servidor. Seria como dizer que a Amazon é pior que empresa de táxi — e talvez até seja. Foi assim que a ‘Waymo’ começou (talvez seja brincadeira)”
• Achei que fosse falar sobre o sofrimento do serverless em hospedagem/desenvolvimento/debug, mas era sobre explosão de custos. Como custo de banda nunca pareceu tão urgente para mim, geralmente passei batido por textos assim, mas esse achei curioso — como um bucket S3 vazio pode fazer sua conta da AWS explodir: a ideia é que dá para fazer chamadas de API sem autenticação ao S3 de outra pessoa e jogar a cobrança para ela. Isso era novidade para mim
  • Acho que tomaram providências logo depois que esse post viralizou: Amazon S3 deixa de cobrar por alguns códigos de erro
  • Um dos verdadeiros problemas do ambiente serverless é que a própria plataforma é opaca como uma caixa-preta (o que, aliás, também é parte da proposta de valor do serverless). Herdamos um backend grande em Lambda, e quando aparece algum problema interno da plataforma — como desconexões intermitentes de socket ao falar com uma extensão de segredos — é um sofrimento enorme rastrear a causa. O ambiente local de teste é tão diferente do ambiente real de produção que isso piora tudo. Brincar em casa com Google Cloud Functions funciona bem, mas num projeto de verdade eu preferiria muito mais subir um servidor HTTP/consumer de fila direto em contêineres tipo ECS
  • A ideia era algo como: “imagine que eu crie um bucket S3 privado vazio na minha região favorita. Por acaso uma ferramenta open source famosa salva backups em S3 por padrão e usou como placeholder exatamente o mesmo nome do bucket que eu criei”. Fico curioso para saber com que frequência isso realmente acontece — não faço ideia de quão comuns são esses conflitos de nome
  • Dá até para pensar em usar isso para eliminar concorrentes. É por isso que eu não gosto muito da AWS. Não existe nenhum esforço real para proteger clientes pequenos dessas cobranças-surpresa. A Azure não é muito melhor, mas pelo menos tem algumas proteções
  • Eu também esperava um caso de lock-in de nuvem, daqueles em que tudo fica amarrado a serverless, Lambda e DynamoDB, te forçando a usar uma estrutura enorme para algo que na prática rodaria num VPS de 20 dólares com sqlite. Fiquei decepcionado por não ser isso
• No serverless, a dor de verdade não é uma cobrança gigante de uma vez só, e sim o valor ir inchando um pouquinho todo mês. É muito fácil criar recursos e largar lá. A conta vai subindo alguns milhares de dólares por mês até o COO perceber, aí vira estado de emergência na empresa inteira para baixar tudo de volta para menos de 10 mil dólares. Depois se repete. Somando alguns anos, o desperdício pode ser maior do que perder uma grande quantia de uma vez só
  • Isso é basicamente o modelo de negócios da AWS. Já ouviu chamar de modelo “Planet Fitness”? Entrar e gastar dinheiro é facílimo, mas cancelar pagamento é um inferno
  • Parece que as organizações não aprendem nada com esses períodos de cobrança absurda. Fico me perguntando qual foi a causa do aumento contínuo e se não havia alguma forma de evitar isso antes
  • Esse tipo de problema também acontece em on-premises. Acaba ficando servidor rodando app que ninguém usa mais (normalmente uma VM). Claro que o custo da VM também não é zero
• Muitas vezes a responsabilidade fica nebulosa. Os clientes querem ferramentas mágicas e sem atrito, em que você sobe infraestrutura de hardware com um clique. Se um usuário sem experiência configura algo errado e gera uma conta gigantesca, a reputação da nuvem piora se ela simplesmente cobrar tudo; mas se começar a filtrar usuários e impor limites preventivos, isso também fecha a porta para desenvolvedores pequenos tentando lançar uma startup. Nessas horas, quando aparece uma cobrança repentina de 10 mil dólares, sempre fico pensando filosoficamente sobre quem deveria pagar o quê, até que ponto a pessoa precisa arcar com custos causados por engano. Se eu usar recursos de forma 10 vezes mais ineficiente por causa do meu código, deveria ser simplesmente “problema seu se configurou errado”? E o cliente deveria ou não se importar se a nuvem usada é uma gigante como a AWS ou uma API startup menor?
  • E se houvesse um sistema de estouro de orçamento/disjuntor (limite de gastos)? Não parece um problema impossível de resolver
  • A resposta na verdade é simples — colocar um limite de orçamento
  • Esse também é um dos motivos pelos quais eu uso servidor de verdade em vez de serverless
• Na Hetzner dá para ter 16TBx2 de HDD, 1TBx2 de SSD, 64GB de RAM e 20TB de tráfego grátis por 70 dólares por mês. Já na AWS, usei 1TB de tráfego numa instância micro e paguei 150 dólares (se não me falha a memória). Não tem necessidade disso
• Sobre a história de “coloquei o Cloudflare na frente do meu conteúdo, mas um hacker achou objetos não cacheados e bateu neles mais de 100 milhões de vezes; quando bloqueei isso, ele descobriu até o endereço do bucket de origem e atacou direto”, fico pensando se isso não pode acontecer com qualquer pessoa. Nem sei se deixar um objeto sem cache exposto é um erro tão grave quanto deixar a porta 22 aberta com senha fraca, e recursos S3 (especialmente imagens) normalmente não são justamente feitos para qualquer um acessar quantas vezes quiser?
  • De jeito nenhum. O bucket S3 tem que ser privado e as regras de segurança precisam permitir acesso apenas pelo CDN. Assim você obriga tudo a passar pelo CDN
  • Soa como alguém se gabando de deixar vulnerabilidades do OWASP Top 10 abertas. Configurar controle de acesso não é tão difícil assim, e se a pessoa erra o básico desse jeito, provavelmente também está relaxando em outras áreas. Eu não confiaria num sistema sob responsabilidade de alguém assim
  • O básico do básico é manter os objetos do S3 privados e colocar pelo menos um proxy CloudFront na frente. Coisas como imagens precisam obrigatoriamente passar pelo cache
• Chamar isso de serverless é estranho, porque na prática ainda existem servidores rodando em infraestrutura de nuvem. No fundo você continua escrevendo software no modelo cliente-servidor, e os usuários só conseguem usar porque há um servidor rodando em algum lugar. Para mim, o verdadeiro “serverless” seria algo que o usuário baixa uma vez e depois usa sem internet. Ou então algo que, mesmo enviando dados a um servidor, funcione sem depender de um local específico definido pelo desenvolvedor
  • O termo “serverless” essencialmente quer dizer “um sistema gerenciado em que os recursos (servidores) escalam para cima e para baixo automaticamente conforme a carga”, e esse é o ponto central. Se a carga aumenta, os servidores aumentam; se diminui, reduzem. O serverless só mostra seu verdadeiro valor quando toda a estrutura do código é moldada de forma eficiente para esse ambiente. Ou seja, é uma arquitetura que só deveria ser usada quando isso realmente for necessário
  • Em geral, isso se chama software “local”. “Serverless” é um nome ruim, mas na prática fala da forma de implantação de um backend específico. Não significa que o app não tenha backend nenhum
  • “Serverless” é como uma “empresa sem funcionários”. Na prática sempre há gente prestando o serviço, só que todo mundo trabalha como terceirizado
  • “Servidor” normalmente é uma máquina única com um OS específico e várias camadas de software em cima (inclusive ferramentas de monitoramento), permitindo que o usuário acesse a lógica de negócio. Se você opera servidores diretamente, precisa se preocupar com escolha do OS, instalação/atualização do software de suporte, recuperação em caso de falha etc. Serverless é um modelo de function as a service, então você só precisa se preocupar com a lógica de negócio (seu código). Não precisa instalar OS no servidor nem cuidar de software básico como servidor HTTP. Também não precisa fazer atualização nem manutenção. Basta subir o código e ele roda quando for chamado. É a ideia de se livrar completamente do estresse de operar servidores. É por isso que se chama “serverless” — os servidores existem, mas você não precisa operá-los diretamente
• “Serverless” não significa de fato que não existam servidores, e sim que você não precisa gerenciá-los diretamente nem saber em qual servidor o seu código está rodando. É algo como: “Toma aqui um código e executa isso de hora em hora. Não me importo onde vai rodar”
  • A palavra pode soar incômoda, mas linguisticamente não me parece um problema orwelliano. Em 1984, a “novilíngua” ia na direção de eliminar variedade de expressão, enquanto “serverless” é mais um neologismo criado para nomear uma categoria nova. Claro, pode obscurecer a existência real dos servidores, mas chamar isso precisamente de orwelliano não parece correto. Talvez desse até para usar algo como “servelet”, no sentido de “servidor leve”
  • Muita gente também usa aquela frase autodepreciativa: “não existe nuvem, é só o computador de outra pessoa”
  • No fim, “serverless” parece só a versão tech-bro da antiga “hospedagem compartilhada”, com “margem de 10.000%” e cobrança por requisição
  • Sistemas “no-code” também rodam sobre código. Ficar bravo porque PaaS ou seja lá o que for ainda tem servidor parece mais procurar motivo para reclamar
• Já usei AWS serverless e testar localmente era praticamente impossível; para rodar serverless run eu precisava obrigatoriamente usar uma IAM role da AWS, então a conta inteira acabava ficando com permissões muito amplas. No fim, dava quase na mesma que testar tudo em produção, o que era um baita problema
  • Também trabalhei por alguns anos em projetos serverless, e esse custo de quase não conseguir rodar nada localmente foi enorme. O tempo de debug era absurdamente longo. As ferramentas que surgiram como substitutas quase nunca servem de verdade para projeto real
  • Se você configurar direito o arquivo ~/.aws/credentials, dá para fazer testes locais com chaves de segurança da AWS. Eu automatizo o deploy de Lambdas com makefile e crio IAM roles customizadas para cada Lambda, gerenciando os requisitos de segurança em arquivos JSON. A grande vantagem da AWS é que tudo pode ser tratado pela mesma API. Dá para criar e administrar tudo programaticamente
  • 1. subir tudo em stack e implantar numa conta separada para dev (ambiente de staging grátis), 2) testar localmente com o runtime Docker oficialmente suportado, 3) escrever testes unitários normalmente, 4) emular na máquina o ambiente de staging com ferramentas como localstack — existem opções demais para eu entender como alguém pode ter tido uma experiência tão ruim assim
  • Isso está bem distante dos fatos
• Acho que “serverless” é, de todo modo, um nome orwelliano que serve para maquiar um sistema que continua sendo baseado em servidores
• Não dá para acreditar que empresas assim cobrem 550 dólares por 1TB de banda. Se eu alugar um servidor com porta garantida de 10Gb/s, acho golpe pagar mais de 3 dólares por TB. Não entendo como o serverless justificaria multiplicar esse custo por 150. Será que tanta gente assim cai nesses preços? Para algo como wiki de leitura/documentação técnica/blog, subir num VPS de 10 dólares ou no GitHub Pages já resolve sem problema, e com uma configuração razoável ainda aguenta tranquilamente 10 mil acessos simultâneos

[benjamin]

Hoje em dia, quando pessoas que estão começando agora no desenvolvimento criam algo com IA, a maioria provavelmente publica o serviço usando coisas como Vercel e Supabase, não é?

Mas, quando o serviço começa a crescer, parece que elas não calculam muito bem o preço que terão de pagar a essas empresas.
Com aquela mentalidade de “depois a gente pensa nisso”.

Imagino que os fundadores da Vercel ou da Supabase responderiam com um sorrisão: “Isso, isso, depois vocês pensam nisso!”

Claro, dá para pensar nisso depois. Desde que você tenha a capacidade de sair rápido.
Mas, sem conhecimento de ciência da computação, isso não vai ser fácil.
Você pode acabar entregando para eles todo o dinheiro que começou a ganhar com muito custo.

Na verdade, é exatamente isso que está acontecendo agora.
Ou seja… está se abrindo um grande negócio que vive de receber o dinheiro de novatos que entram sem saber nada de ciência da computação.

É por isso que precisamos continuar nos aprofundando em ciência da computação.
Enquanto algumas pessoas gastam 1 milhão de won por mês em um serviço que mal começou a dar lucro, outras operam um serviço sem pagar absolutamente nada.
Reduzir custos operacionais também é competência. Isso não é uma vantagem competitiva enorme?
É ótimo programar com IA, criar coisas e sentir essa empolgação, mas, se você não se esforçar para ir mais fundo, no fim das contas não conseguirá criar uma diferença real.

https://jeho.page/essay/2025/09/08/sucker-developer.html