Historias de terror serverless

• En diversos servicios SaaS y serverless, ocurren con frecuencia casos de cobros masivos inesperados, y esta página los recopila de forma clara
• Se han dado a conocer casos en los que usuarios que pagaban normalmente su suscripción mensual terminaron recibiendo cargos de decenas a cientos de miles de dólares en un solo día debido a ataques DoS o uso indiscriminado de recursos
• En algunos servicios, incluso después de configurar un límite de gasto, se aplicaron cargos adicionales, lo que deja en evidencia limitaciones sistémicas
• En la comunidad de desarrolladores se comparten experiencias como estas, y se señalan como problemas principales las estructuras de cobro absurdas y la falta de transparencia
• En entornos serverless y de nube, un error menor o un solo ataque puede causar pérdidas económicas enormes, por lo que se subraya la necesidad de tomar precauciones

---

Casos recopilados de cobros excesivos en servicios serverless y SaaS

#1 Un cargo altísimo en Webflow

• Mientras usaba un plan mensual de 69 dólares, le cobraron $1,189.42 por un solo mes sin razón aparente

#2 Caso de ataque DoS en un sitio de juegos WebGL

• El operador de un sitio mediano para subir juegos WebGL recibió un cobro de más de $100,000 en Google Firebase en un solo día tras sufrir un ataque DoS

#3 Vercel Pro y el límite de gasto superado

• Usando el plan Vercel Pro por $20 al mes, y aun habiendo configurado un límite de gasto de $120, aparecieron cargos adicionales inesperados

#4 Facturación del proyecto y cobro extremadamente alto

• Se reportó un caso en el que un proyecto que pagaba $50 al mes recibió una mañana una factura de $70,000

#5 Uso de BigQuery y problema de cobros por datasets públicos

• Al usar BigQuery en un entorno de Playground, se generó un cargo enorme de más de $22,000

#6 Tarifas de hosting excesivas para pocos visitantes

• Aunque tenía 9,000 visitantes mensuales, se cobraban $250 al mes, lo que implica un gasto de $3,000 al año

#7 Problemas tras cambios en el codebase hechos por Devin(AI)

• Se compartió una experiencia con resultados inesperados después de que una IA llamada Devin realizara cambios en el código

#8 Cobro repentino después de usar el servicio gratis

• Nunca había pagado nada, pero un día apareció de repente un cargo de $530

#9 Cobros en sitios de documentación y otros proyectos pequeños

• Incluso a un simple sitio de documentación le cobraron casi $400, y hay muchos casos similares de cargos altos en servicios con poco uso

#10 El terror del free tier

• Incluso un cobro de alrededor de $103 se percibe como un problema. En especial, la aparición repentina de una factura mientras se usa el nivel gratuito genera preocupación

#11 Cloudflare, AWS y otros problemas

• En Cloudflare, hubo un caso de suspensión del servicio junto con un aviso para pagar $120,000 en menos de 24 horas
• En AWS S3, se produjeron cobros inesperados incluso después de crear un bucket vacío y privado
• En Netlify, se recibió una factura pendiente de $104,500, y se repiten casos similares entre distintos proveedores

#12 Ataque DoS, correo electrónico y pérdida de datos

• Durante un ataque DoS, se gastaron $11,000 en envío de correos electrónicos, y después también se perdió la base de datos

#13 Cobros masivos en Vercel y problemas con cuentas y trials

• En Vercel, un ataque de spam generó un cargo de $23,000 en un solo día, con 56,000 cuentas y trials activados

#14 Cargos inesperados durante pruebas y despliegues

• Al desplegar funciones en Vercel y otros servicios con fines de prueba, se generaron cargos inesperados
• El sitemap (sitemap.txt) consumió cientos de GB de ancho de banda y provocó cobros elevados

#15 Costos de prueba en Firebase y Cloud Run

• Con solo dos pruebas de Firebase y Cloud Run, se consumieron $72,000, dejando al servicio al borde de la quiebra

Conclusión e implicaciones

• La estructura de costos en entornos serverless y de nube puede ser opaca o muy vulnerable a ataques y errores
• Se han reportado muchos casos de cobros inesperados, por lo que es indispensable hacer monitoreo cuidadoso, gestionar el uso y configurar límites permitidos al operar servicios
• Si las funciones de automatización y monitoreo son deficientes, una simple prueba o un solo ataque externo pueden causar pérdidas inesperadas de decenas de miles de dólares
• Para desarrolladores, startups y otros usuarios de SaaS, está cobrando mayor importancia la gestión de costos y la conciencia del riesgo

[ahwjdekf]

Trabajé en el desarrollo de un DW interno para una gran empresa, y era un proyecto para migrar los datos existentes on-premises a AWS. Pero incluso después de terminar varios meses de desarrollo y pruebas, al final se canceló. La razón fue que parecía que la facturación mensual iba a ser mucho más alta de lo esperado. Incluso para las grandes empresas, el gasto en la nube no es algo fácil.

[regentag]

A mí también me pasó que, con el objetivo de estudiar AWS, me creé una cuenta y terminé con un cobro, aunque fue por un monto pequeño.
Alguien comprometió mi cuenta y creó instancias para ponerlas a correr con ella...
Por suerte las detuve rápido, así que quedó en un cargo menor. Como no podía dedicarle tiempo a la administración, al final opté por simplemente eliminar la cuenta.

[ifmkl]

Antes de empezar con la nube, me gustaría recomendar que armen un entorno de miniserver con equipos de clase n100 o n150, que están saliendo mucho últimamente, para hacer pruebas o ir acumulando algo de experiencia operativa.

[crawler]

Incluso si es un proyecto muy pequeño, da mucho miedo que con solo subirlo a una plataforma, si hay una vulnerabilidad, eso pueda terminar en una pérdida económica.

Puse Cloudflare delante de mi contenido, pero un hacker encontró un objeto que no estaba en caché y le pegó más de 100 millones de veces. Cuando lo bloqueé, incluso encontró directamente la dirección del bucket de origen y lo atacó.

En casos así, me pregunto si también reembolsarán los costos.

[GN⁺]

Opiniones de Hacker News

• Cuando estaba aprendiendo a programar en un bootcamp, probé crear una instancia de Elastic Beanstalk gratis. Pedían una tarjeta de crédito para verificar mi identidad, y en ese momento no pensé que eso fuera a ser un problema. Pero después mi servidor recibió un ataque de spam de bots y Amazon me cobró 100 mil dólares. Al final me hicieron el reembolso, pero desde ese día terminé odiando a Amazon y me prometí que, si tenía que usar computación en la nube, usaría otro servicio. No me gustó la estructura de dashboards complejos y confusos que parece hecha para que el cliente se equivoque y pierda dinero. Habría bastado con usar la tarjeta de crédito solo como medio de verificación y bloquear a los bots. Si lo comparas con comprar unas galletas fácilmente con tarjeta en una tienda, la tecnología financiera sí puede usarse de forma realmente útil, y siento que aquí no lo hicieron
  • Esa es una de las razones por las que el hosting en la nube da miedo. No solo Amazon: Azure y Google Cloud también “normalmente” hacen reembolsos. Pero si de pronto mi proyecto demo con 5 visitas semanales recibe un DDoS y la empresa de hosting decide que esta vez no aplica lo “normal” y me pide una transferencia, podría quedar al borde de la quiebra
  • Ahora mismo tengo un cargo de 25 mil dólares. Hace tiempo dejé activada la auditoría de dataplane de SQS y en realidad la tenía conectada a un feed de eventos de auditoría en tiempo real. Como resultado, cada evento de auditoría puro generaba eventos de registro en un bucle infinito. Una cuenta que durante casi 10 años promediaba 2 dólares al día de repente empezó a generar 3 mil dólares diarios, y AWS no mandó ninguna alerta ni intervino de ninguna forma
  • Me pregunto por qué odias a Amazon si te reembolsaron los 100 mil dólares. En mi caso, AWS siempre me ha reembolsado incluso cuando el cargo caro fue completamente culpa mía. Si existiera una política de “si te pasas del presupuesto, se apaga todo”, también habría muchas otras tragedias del tipo “recibí un DDoS y AWS apagó todas mis EC2 y hasta perdí los datos que tenía en almacenamiento temporal”
  • “Esto sería facilísimo: un if de una sola línea para apagar instancias y volcar el servicio a un disco estático cuando la cuenta pase su límite. Simplemente no quisieron hacerlo: quieren aprovechar su escala para maximizar ingresos a costa de sus clientes. La misma gente que ya puso en problemas a todos con cloud compute ahora también quiere sacarle renta económica a los costos de IA aprovechando la captura de mercado. Hoy el edge compute es más fácil porque las criptomonedas hicieron que la gente sobreinvirtiera en discos duros. Al final, el mercado incentiva burbujas y malas conductas, y facilita que quienes abusan del mercado desde el poder dominen en vez de construir confianza. Los villanos inteligentes que adoptan una actitud astuta del tipo ‘¡es que tú no entiendes esto! (ah, y págame un poco más antes de que el mercado colapse)’ son el mayor dolor de cabeza de la industria. Ni las compañías de taxi te cobran mil dólares por no llevarte al destino. Cuesta creer que no puedan meter un if en un servidor. Eso implicaría que Amazon es peor que una compañía de taxis, y quizás sí lo sea. De hecho, así fue como empezó ‘Waymo’ (o tal vez es broma)”
• Pensé que iban a hablar del dolor de serverless en hosting/desarrollo/debugging, pero era sobre explosiones de precio. Como los costos de ancho de banda no suelen pegarme tan fuerte, normalmente paso por alto la mayoría de estos textos, pero este me pareció curioso: un caso en el que un bucket vacío de S3 puede disparar la factura de AWS, donde cuentan que solo con hacer llamadas a la API sin autenticación al S3 de otra persona puedes trasladarle el cobro. Eso sí fue nuevo para mí
  • Creo que tomaron medidas poco después de que esa publicación se hiciera viral: Amazon S3 deja de cobrar por algunos códigos de error
  • Uno de los problemas reales de los entornos serverless es que la plataforma misma es opaca, como una caja negra (aunque justamente esa también es parte de su propuesta de valor). Heredamos un backend grande en Lambda, y cuando aparecen problemas internos de la plataforma, como cortes intermitentes de socket al conectarse a un secrets extension, seguirles el rastro es un sufrimiento. Además, el entorno de pruebas local es demasiado distinto al de despliegue real, y eso lo empeora todavía más. Jugar en casa con Google Cloud Functions puede funcionar, pero en un proyecto real preferiría subir directamente un servidor HTTP o un consumer de cola a contenedores en ECS o algo parecido
  • La idea era: “supongamos que creo un bucket privado vacío de S3 en mi región favorita. Resulta que una herramienta open source popular tiene por defecto guardar backups en S3 y usa como placeholder exactamente el mismo nombre que mi bucket”. Me pregunto con qué frecuencia pasa eso de verdad; no tengo claro qué tan comunes son esas colisiones de nombres
  • Hasta hace pensar que podrías usar esto para eliminar competidores. Por eso AWS no me gusta mucho. No hacen absolutamente nada para proteger a los clientes pequeños de facturas sorpresa. Azure no es mucho mejor, pero al menos tiene algunas medidas de protección
  • Yo también esperaba una historia de lock-in en la nube, donde te atan a serverless, Lambda y DynamoDB para obligarte a usar algo enorme cuando en realidad bastaría un VPS de 20 dólares con sqlite, así que me decepcionó que no fuera por ahí
• El verdadero dolor en serverless no es que un incidente te cobre muchísimo de una vez, sino las facturas que van creciendo poquito a poquito cada mes. Es muy fácil crear recursos y dejarlos abandonados. Suben unos miles de dólares cada uno o dos meses, hasta que el COO se da cuenta y toda la empresa entra en modo emergencia para bajar la factura por debajo de $10,000. Luego se repite. Si lo acumulas durante años, se desperdicia más dinero que en un solo accidente grande
  • Ese es básicamente el modelo de negocio de AWS. ¿Alguien lo ha llamado el modelo “Planet Fitness”? Inscribirte o gastar dinero es facilísimo, pero cancelar los cobros es un dolor enorme
  • Parece que las organizaciones no aprenden nada de estos periodos de facturación tan caros. Me pregunto cuál fue la causa del aumento continuo y si había alguna forma de prevenirlo de antemano
  • Este tipo de cosas también pasa on-premise. Terminas con servidores —normalmente VMs— ejecutando apps que ya nadie usa. Claro, el costo de una VM tampoco es cero
• Muchas veces la responsabilidad no está clara. Los clientes quieren herramientas mágicas y sin fricción con las que puedan desplegar infraestructura de hardware con un clic. Si un usuario sin experiencia configura algo mal y termina con una factura enorme, y la nube le cobra todo tal cual, la reputación del proveedor queda mal; pero si el proveedor decide filtrar o limitar a los usuarios desde antes, también le cierra la puerta a desarrolladores pequeños que quieren intentar crear una startup. En casos así, cuando aparece de golpe una factura de $10,000, siempre me pregunto filosóficamente quién debería pagar qué parte y hasta dónde llega la responsabilidad por costos generados por error. Si en mi código uso recursos de forma 10 veces más ineficiente, ¿debería ser simplemente “si configuraste mal, es tu culpa”? ¿O da igual si el proveedor que usé es un gigante como AWS o una API de una startup pequeña, y como cliente ni siquiera debería tener que pensar en eso?
  • ¿Qué tal sistemas de excedente de presupuesto / circuit breaker (topes de gasto)? No parece un problema imposible de resolver
  • La respuesta en realidad es sencilla: poner un límite de presupuesto
  • Esa también es una de las razones por las que uso servidores reales y no serverless
• En Hetzner puedes tener 16TBx2 HDD, 1TBx2 SSD, 64GB de RAM y 20TB de tráfico gratis por $70 al mes. En cambio, en una instancia micro de AWS usé 1TB de tráfico y pagué $150, según recuerdo. No hay necesidad de esto
• Sobre la historia de “puse Cloudflare delante de mi contenido, pero un hacker encontró objetos no cacheados y les pegó más de 100 millones de veces; cuando lo bloqueé, encontró directamente la dirección del bucket de origen y atacó eso”, me pregunto si esto no podría pasarle a cualquiera. No sé si exponer un objeto sin caché filtrado es un error tan grave como dejar abierto el puerto 22 con una contraseña débil, y en S3 (sobre todo imágenes) ¿no es normal que cualquiera pueda acceder muchas veces?
  • Para nada. Un bucket de S3 debe ser privado y tener reglas de seguridad para que solo se pueda acceder desde el CDN. Así te aseguras de que todo pase obligatoriamente por el CDN
  • Da la impresión de alguien presumiendo que deja vulnerabilidades del OWASP Top 10. Configurar bien el control de acceso no es tan difícil; si alguien se equivoca en algo tan básico, es muy probable que también esté siendo descuidado en otras partes. No confiaría en un sistema a cargo de alguien así
  • Lo más básico es dejar los objetos de S3 como privados y, como mínimo, poner un proxy de CloudFront delante. Cosas como imágenes deben pasar sí o sí por caché
• Llamarlo serverless es engañoso porque en realidad sigues ejecutando servidores en infraestructura cloud. En el fondo, igual escribes software según un modelo cliente-servidor, y para que el usuario lo use, algún servidor tiene que estar corriendo en alguna parte. En mi opinión, el verdadero “serverless” sería algo que el usuario descarga una vez y luego puede usar sin internet. O, si envía datos a un servidor, que funcione sin depender de un lugar específico definido por el desarrollador
  • El término “serverless” en esencia significa “un sistema administrado en el que los recursos (servidores) suben y bajan automáticamente según la carga”, y eso es lo central. Si la carga sube, aumentan los servidores; si baja, disminuyen. Serverless solo muestra su verdadero valor cuando puedes reorganizar toda la estructura del código para adaptarse eficientemente a ese entorno. O sea, es una arquitectura que solo deberías usar cuando realmente la necesitas
  • Normalmente a eso se le llama software “local”. “Serverless” es un nombre bastante malo, pero en realidad habla de una forma de despliegue de cierto backend. No significa que sea una app sin backend
  • “Serverless” es como decir “una empresa sin empleados”. En realidad sí hay gente prestando el servicio, solo que todos son contratistas
  • Un “servidor” normalmente es una sola máquina con un sistema operativo y varias capas de software encima (incluyendo herramientas de monitoreo) que permite al usuario acceder a la lógica de negocio. Si usas servidores directamente, tienes que encargarte de elegir el SO, instalar y actualizar software de soporte, recuperarte de fallos, etc. Serverless es un modelo de “function as a service”, así que solo te preocupas por la lógica de negocio (tu código). No tienes que instalar un SO en el servidor ni encargarte del software básico como un servidor HTTP. Tampoco tienes que hacer actualizaciones ni mantenimiento. Subes el código y se ejecuta cuando se invoca. La idea es liberarte por completo del estrés de operar servidores. Por eso se llama “serverless”: los servidores sí existen, pero no necesitas operarlos tú mismo
• “Serverless” no significa que no haya servidores de verdad, sino que no tienes que administrarlos directamente ni saber en qué servidor corre tu código. Es algo como: “te doy este código, ejecútalo cada hora; no me importa dónde lo corras”
  • Puede que la palabra te resulte incómoda, pero lingüísticamente no es un problema orwelliano. La “neolengua” de 1984 iba en la dirección de eliminar la diversidad expresiva, mientras que “serverless” es más bien un neologismo para señalar una categoría nueva. Claro, puede ser un término que difumine la existencia de servidores, pero no encaja del todo llamarlo orwelliano. Algo como “servelet” también podría funcionar, como diciendo “servidor ligero”
  • También se usa mucho la frase irónica “la nube no existe, solo es la computadora de alguien más”
  • “Serverless” al final se siente como la versión tech-bro del antiguo “shared hosting”, pero con “margen de 10,000%” y cobro por request
  • Los sistemas “no-code” también funcionan sobre código. Enojarse porque PaaS o lo que sea al final usa servidores es solo buscar un pretexto
• He usado AWS serverless y las pruebas locales eran prácticamente imposibles. Además, para correr serverless run sí o sí tenía que usar un AWS IAM role, así que la cuenta quedaba con permisos amplios abiertos por todos lados. Al final eso generaba un problema enorme: en la práctica era casi lo mismo que probar todo directamente en producción
  • Yo también trabajé durante años en proyectos serverless y ese hecho de no poder ejecutar casi nada en local sí fue un costo muy grande. Los tiempos de debugging eran brutalmente largos. Incluso las herramientas que salieron supuestamente para reemplazar eso casi no sirven en proyectos reales
  • Si configuras bien el archivo ~/.aws/credentials, puedes hacer pruebas locales con las llaves de seguridad de AWS. Yo automatizo el despliegue de Lambdas con un makefile y creo un IAM role personalizado para cada Lambda, administrando los requisitos de seguridad en archivos JSON. La verdadera ventaja de AWS es que todo se puede manejar con la misma API. Puedes crear y administrar todo programáticamente
  • 1. Despliegas dentro de un stack a una cuenta separada para desarrolladores (un entorno de staging gratis) 2) haces pruebas locales con el runtime oficial en Docker 3) escribes pruebas unitarias como siempre 4) emulas el entorno de staging en tu máquina con herramientas como localstack. Hay tantas opciones que no entiendo cómo alguien pudo tener una experiencia tan mala
  • Esa afirmación está muy alejada de la realidad
• Creo que “serverless” es, de todos modos, un nombre orwelliano que maquilla sistemas que en realidad sí dependen de servidores
• No puedo creer que estas empresas cobren hasta $550 por 1TB de ancho de banda. Incluso rentando un servidor con puerto garantizado de 10Gb/s, si sale arriba de $3 por TB ya me parece una estafa. No entiendo cómo serverless puede justificar multiplicar ese costo por 150. ¿De verdad tanta gente cae en esos precios? Para algo como una wiki de lectura, documentación técnica o un blog, basta con un VPS de $10 o GitHub Pages, y con una configuración decente hasta 10 mil usuarios concurrentes aguantan sin problema

[benjamin]

¿No será que ahora la mayoría de las personas que recién empiezan a desarrollar, cuando crean algo con ayuda de la IA, terminan lanzando su servicio con cosas como Vercel o Supabase?

Pero parece que no calculan bien cuánto tendrán que pagarles cuando el servicio empiece a crecer.
Con la idea de “ya lo pensaremos cuando llegue ese momento”.

Me imagino a los fundadores de Vercel o Supabase diciendo: “¡Sí, sí, claro, ya lo piensan cuando llegue ese momento!” con una sonrisa de oreja a oreja.

Claro, también se puede pensar en eso cuando llegue el momento. Siempre y cuando tengas la capacidad de salir rápido de ahí.
Pero sin conocimientos de ciencias de la computación, no va a ser fácil.
Podrías terminar entregándoles todo el dinero que apenas empezabas a ganar.

De hecho, eso es lo que está pasando ahora mismo.
O sea… se está abriendo un gran negocio que vive de sacarle dinero a los novatos que se lanzan sin saber nada de ciencias de la computación.

Aquí está la razón por la que hay que seguir profundizando en ciencias de la computación.
Hay gente que gasta 1 millón de wones al mes en un servicio que apenas empezó a generar ingresos, mientras que otra opera su servicio sin pagar absolutamente nada.
Reducir los costos operativos también es una habilidad. ¿No es una ventaja competitiva enorme?
Está bien disfrutar crear cosas programando con IA, pero si no intentas meterte más a fondo, al final no podrás marcar una diferencia real.

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