I. Una factura de 1.700 millones… con una cuota mensual de menos de 5 dólares
El 17 de julio de 2026, un usuario de AWS llamado nprateem publicó en Hacker News que su factura mensual estimada de AWS mostraba $1.700.000.000 —mil setecientos millones de dólares. Su cuota mensual normal, sin embargo, era de menos de 5 dólares.
Pensó que había leído mal, se frotó los ojos. No había leído mal.
El usuario abrió de inmediato un ticket de emergencia y preguntó en el hilo: «¿A alguien más le ha pasado esto?»
La respuesta fue: sí, a muchísima gente.
En Reddit y en X (antes Twitter) empezaron a aparecer rápidamente montones de capturas. Un usuario que el mes anterior había gastado solo 0,19 dólares recibió una factura estimada de casi 2.500 millones. Otro usuario escribió en X: “I just saw $1.5 trillion on my AWS bill, my soul left my body.” Ese tuit acumuló 1,3 millones de visualizaciones y casi 19.000 me gusta.
Hubo quien, preso del pánico, borró de golpe todos los recursos de su cuenta entera — “Needless to say, I panicked and destroyed everything on that account.”
Pero estas cifras no eran cargos reales. AWS confirmó pronto que el problema afectaba a la «factura estimada», no a los cobros reales. Aun así, al ver esa cifra, nadie pudo mantener la calma.
II. ¿Qué pasó exactamente?
AWS dio una causa raíz 90 minutos después del incidente: «un problema de fijación de precios por unidad en el subsistema de cálculo de facturas estimadas». Suena enrevesado; en lenguaje llano significa —se escribió mal una unidad.
Quien explicó realmente el asunto fue donavanm, un ex ingeniero de AWS. Escribió esto en los comentarios de Hacker News (traducido por la redacción):
“I’ve handled this exact same error while at AWS. It was a units error. We’d intended to charge $0.05/GB but omitted the unit (GB), and the billing system defaulted to billing per byte. $0.05 per byte of data transfer meant some customers saw million-dollar bills within hours. Woken up at 2am by the support team, fixed and deployed between 3 and 4am, then sent an apology email.”
Este relato revela varias claves:
Primera, no es la primera vez. Este mismo tipo de error ya había ocurrido antes — y «antes», probablemente, más de una vez.
Segunda, el factor de amplificación del error es brutal. 1 GB = 1.073.741.824 bytes. Si olvidas poner «GB», el sistema factura por byte y la factura se infla mil millones de veces. Una tarifa de uso de 0,05 dólares se convierte en 53.687.091,20 dólares.
Tercera, este error no lo detecta nadie automáticamente antes del despliegue. Atravesó desarrollo, pruebas y despliegue, y solo se descubrió cuando los usuarios vieron la captura, entraron en pánico y empezaron a publicar.
III. ¿Cómo es posible que «olvidar una unidad» atraviese todas las defensas?
Esta es la parte más inquietante.
donavanm explicó más a fondo cómo funciona el sistema de facturación de AWS. Los datos de medición del servicio (cuánto recurso se usó) y la información de precios (cuánto cuesta cada unidad) se almacenan por separado. Cada SKU (cada línea de cargo) se define en un «plan de precios» que incluye tipo de unidad, región aplicable, precio unitario, etc. Los registros de medición y los planes de precios se cruzan mediante campos como el ID de cuenta, la región y el número de SKU.
Si en el plan de precios se rellena mal el tipo de unidad —debía ser GB y se dejó en blanco o se puso byte—, la conversión entre medición y precio falla. Y ninguna comprobación automatizada puede detener ese error.
Un comentario de Hacker News fue al grano:
“No tests? Just get some obscure detail wrong—and then hundreds of thousands of admins get a heart-attack-inducing bill?”
Otro usuario respondió a esa pregunta:
“Of course there are tests. Test 1 verifies the service emits metering data correctly (‘we performed 100 byte operations, confirmed the billing system received 100 bytes of data, pass’). Test 2 confirms the billing system’s calculation logic (‘input 100 GB units into SKU#12345, calculate $17, pass’). But nobody runs the two test suites together—because that spans different teams, different management layers, and is harder to do.”
Me parece una explicación muy lúcida. Revela un problema clásico de gestión de ingeniería: cada eslabón funciona bien por separado, pero al juntarlos fallan. Un usuario de HN añadió: “Someone said in some meeting ‘we should have tests actually walk through the billing flow’, then someone said ‘having tests actually generate real charges could be a legal/financial issue, even criminal’—and then nobody followed up on what the second-best alternative was.”
IV. El verdadero «villano»: la complejidad de la facturación en la nube
Si se reduce este incidente a «un ingeniero distraído escribió mal una configuración», se pierde por completo el punto.
El verdadero villano es la complejidad del propio sistema de facturación en la nube.
AWS tiene aproximadamente 300.000 SKU distintos (unidades de precio). No 300, sino 300.000. Cada SKU tiene su propia lógica de precios —por tiempo, por tráfico, por número de peticiones, por capacidad de almacenamiento, por región. Y se apilan entre sí: una simple petición web puede disparar tarifa de cómputo, de transferencia de red, de lectura de almacenamiento, de registro de logs, de datos de monitorización… cada una con su unidad y sus reglas.
La generación de datos de uso y la configuración de precios son dos sistemas completamente independientes. Su cruce se basa en asociación por campos, no en validaciones codificadas a fuego. Este diseño no está mal en sí —da a AWS una flexibilidad enorme para ajustar precios sin tocar el sistema de medición—, pero el coste es: nadie comprende del todo «cuánto me va a costar exactamente esta operación».
De hecho, la facturación de AWS es tan compleja que ha surgido una profesión dedicada a interpretarla: el consultor de optimización de costes en la nube. Que sobre un negocio de más de 100.000 millones de dólares al año haga falta un «traductor» que explique a los clientes cuánto han gastado ya dice mucho.
Incluso los propios ingenieros de AWS, en la conversación de HN, admitieron algunos hechos inquietantes. Un ex empleado escribió: «toda la empresa es como una máquina de Rube Goldberg (un artefacto deliberadamente hipercomplejo), y a pocos les importa lo que ocurre fuera de su pequeña parcela —porque no tienen incentivo para importarles».
Otro ex empleado añadió: «me metieron en un plan de mejora del rendimiento (Focus) porque mi ‘contribución no era visible para la dirección’. En ese entorno, si veo un fallo en el código de un compañero, no tengo ningún incentivo para señalarlo y arreglarlo yo —si lo arreglo, al final del año la evaluación de desempeño seguirá obligando a clasificar a un porcentaje de la gente como ‘ineficiente’; ¿por qué no puede ser el compañero que dejó el bug?»
Claro, hubo voces discordantes. Otro ex empleado de nivel de dirección replicó: «cualquier impacto en el cliente de esa magnitud dispara un informe COE (corrección de errores), lo que significa redactar un montón de acciones correctivas obligatorias, consumiendo al menos un mes-hombre de una persona. El COE es un enorme quebradero de cabeza para todo el equipo, y eso mismo genera un fuerte incentivo para prevenir problemas».
No me posiciono. Ambas versiones pueden ser ciertas a la vez —la cultura varía muchísimo según departamento y nivel—. Pero eso mismo demuestra: en una organización con decenas de miles de ingenieros, aunque todos quieran hacerlo bien, las vulnerabilidades sistémicas pueden colarse de punta a punta.
V. ¿Cómo respondió AWS?
Según la línea de tiempo pública del panel de estado (Health Dashboard) de AWS:
- 3:52 a. m. PDT, 17 de julio: AWS confirma que la causa raíz es «un problema de fijación de precios por unidad en el subsistema de cálculo de facturas estimadas» y detiene el cálculo de estimaciones.
- 4:58 a. m.: intenta dos vías de reparación a la vez —revertir el cambio reciente o restaurar los últimos datos correctos.
- 5:54 a. m.: la monitorización interna muestra que el subsistema de facturación ya produce estimaciones correctas; sigue validando.
- 7:53 a. m.: mala noticia —el rollback no resolvió el problema; ambas vías siguen en curso. La actualización de facturas estimadas sigue en pausa.
- 9:59 a. m.: causa raíz localizada y corregida; empieza a recalcular los datos de facturación para todos los clientes. Se estima que algunos clientes lo verán en 3 horas y todos antes del mediodía del 18 de julio.
- 12:56 p. m.: va más lento de lo previsto. La recuperación completa se retrasa al amanecer del 19 de julio. La declaración subraya: «las estimaciones de facturación mostradas no reflejan el uso ni los cobros reales. Los clientes no necesitan tomar ninguna acción».
Arreglar un bug de «olvidar una unidad» le costó a AWS más de 24 horas —y el primer intento de reparación falló. Lo que a la inversa también dice: incluso los propios ingenieros de AWS no lo tienen fácil para arreglar los bugs de su sistema.
VI. ¿Qué significa todo esto?
Al final, este incidente no causó pérdida económica real —nadie pagó de más—. Pero los problemas que revela son mucho más profundos que «un ingeniero se distrajo».
Primero, la facturación en la nube se ha convertido en un sistema que «nadie comprende del todo». AWS es el ejemplo más extremo, pero Google Cloud y Microsoft Azure enfrentan el mismo problema. Cuando la complejidad de un sistema supera la capacidad de comprensión de cualquier individuo, deja de ser una herramienta controlable para convertirse en una caja negra que solo puedes «observar, conjeturar y rezar para que no falle».
Segundo, la era de la IA está subiendo la apuesta de este problema. Justo la semana pasada, AWS anunció 1.000 millones de dólares para un equipo de ingenieros de IA orientado al cliente. La factura mensual de una sola tarea de entrenamiento de IA ya puede alcanzar cientos de millones. Cuando la escala de las facturas reales es tan enorme, un error de facturación aunque sea «solo en la estimación» causa un pánico social y una pérdida de confianza muy superiores a las del pasado.
Tercero, este bug no es la primera vez y no será la última. El propio donavanm, ex ingeniero de AWS, vivió el error idéntico y fue despertado a las dos de la madrugada para arreglarlo. Eso indica que la vulnerabilidad lleva al menos varios años en el sistema de AWS, ha ocurrido al menos dos veces, y ambas provocaron pánico masivo de usuarios. Pero nunca se ha tapado de forma sistemática.
Al escribir esto, recordé la frase de donavanm describiendo la arquitectura de facturación de AWS: «los datos de medición del servicio no se vinculan directamente al precio». Dicho en román paladino: entre tu uso y tu factura hay al menos dos capas de mapeo que requieren configuración manual. Si se escribe mal cualquiera de ellas, el resultado es: 5 dólares se convierten en 1.700 millones.
Enlaces de referencia
- Hilo de HN: la conversación en Hacker News sobre la inexactitud de las facturas estimadas de AWS; el autor original nprateem colgó la captura de los 1.700 millones, generando 992 puntos y 618 comentarios (item?id=48945241)
- Análisis de causa raíz de donavanm, ex ingeniero de AWS: explica en detalle cómo un error de configuración de unidad de precio (byte frente a GB) infla la factura mil millones de veces, y el diseño arquitectónico de AWS que separa medición y precios
- Aviso del AWS Health Dashboard: la página de estado oficial de AWS con la línea de tiempo completa del evento «Billing Console - datos de factura estimada inexactos», desde la confirmación de la causa raíz hasta la finalización de la reparación
- Crónica de The Next Web: reporte integral del alcance del evento, incluyendo la reacción en Reddit (cuota de 0,19 dólares que se volvió 2.500 millones) y el cronograma de reparación de AWS
- Crónica de Cyber Kendra: cita la captura de la factura de 1,5 billones de dólares publicada por el usuario @Bharath_uwu en X, y la respuesta oficial de AWS Support
- Crónica de TechRadar: titular «mi alma abandonó mi cuerpo», recoge las reacciones de pánico de varios usuarios, incluido el caso extremo de quien borró todos sus recursos en la nube
