- AWS reportó problemas operativos desde la noche del jueves, y una interrupción vinculada al sobrecalentamiento de un centro de datos en la región US-East-1 del norte de Virginia afectó a plataformas de transacciones como Coinbase y FanDuel
- En una actualización del viernes a las 3:29 p. m. (ET), AWS indicó que todavía esperaba que la recuperación total tomara varias horas más, y que las tareas de recuperación avanzaban más lentamente de lo previsto anteriormente
- AWS explicó que el problema ocurrió en una Availability Zone única de esa región, y que estaba recuperando el hardware restante al poner en línea capacidad adicional del sistema de enfriamiento
- FanDuel dijo que, tras investigar dificultades técnicas que impedían a los usuarios acceder a la plataforma, determinó que estaban relacionadas con una interrupción más amplia de AWS, y usuarios se quejaron de pérdidas en apuestas por no poder retirar efectivo
- Coinbase indicó que fallas en varias zonas de AWS provocaron una interrupción prolongada de sus servicios centrales de transacciones, y publicó que los problemas principales ya estaban completamente resueltos
Avance de la recuperación
- En una actualización del viernes a las 9:51 a. m. (ET), AWS señaló que “estamos trabajando activamente para poner en línea capacidad adicional del sistema de enfriamiento, lo que nos permitirá recuperar el hardware restante en el área afectada”
- AWS está resolviendo fallas en instancias EC2, que proporcionan capacidad de servidores virtuales
- El panel de estado de AWS publicó por primera vez el jueves a las 8:25 p. m. (ET) que estaba “investigando fallas de instancias”
- AWS no emitió comentarios adicionales
Impacto por servicio
- FanDuel informó en X el jueves a las 9 p. m. (ET) que estaba al tanto de las dificultades técnicas actuales que impedían a los usuarios acceder a la plataforma y que estaba investigando
- Cerca de 2 horas después, FanDuel actualizó que el problema estaba vinculado a una interrupción más amplia de AWS
- Usuarios de FanDuel se quejaron de pérdidas en apuestas por no poder retirar efectivo en la plataforma
- Coinbase también publicó el viernes en X que fallas en varias zonas de AWS causaron “una interrupción prolongada de los servicios centrales de transacciones”
- Coinbase indicó en esa publicación que los problemas principales ya estaban completamente resueltos
Contexto del mercado cloud
- AWS representa aproximadamente un tercio del mercado de tecnología de infraestructura cloud
- AWS presta servicio a millones de empresas
1 comentarios
Comentarios de Hacker News
AWS US-East 1 sigue siendo el talón de Aquiles de internet
Puedes desplegar en varias regiones y zonas de disponibilidad, pero AWS ha repetido incidentes donde los problemas de US-East 1 tienen un impacto más amplio, y eso hace que la redundancia y la resiliencia no sean tan altas como AWS da a entender
Todos los servicios de identidad y acceso de la nube pública fuera de China, es decir, lo que los empleados llaman “IAM para la partición aws”, están centralizados en us-east-1. Para tener una vista coherente de cuentas, facturación y permisos, en la práctica se necesita este tipo de centralización
IAM tampoco es una pila de software totalmente independiente, sino que depende de algunos servicios como DynamoDB, y esos servicios a su vez tienen dependencias circulares con IAM
Durante una caída de us-east-1, a veces es posible seguir usando tokens o sesiones existentes en otras regiones, pero puede que no se puedan emitir nuevos tokens. Recuerdo que en un trabajo anterior le decían al equipo de guardia que no cerrara sus sesiones SSH ni las pestañas del navegador con la consola de AWS, porque podían quedarse bloqueados hasta que terminara la caída
En los últimos 3 años operé startups casi por completo en use-1 y solo hubo una caída regional, y aun esa fue parcial, así que la mayoría de las instancias no se vieron afectadas
Siendo sinceros, como todo lo de los clientes también está en use-1, existe la ventaja de que la caída está correlacionada con los clientes
En un mundo mágico de fantasía, la carga estaría distribuida uniformemente entre varios proveedores de nube y no existirían puntos únicos de falla
También me habría ido bien con mi primera novia, los gemelos hablarían inglés y coreano, y sabríamos que no hay que depender de un solo AWS para desplegar servicios a gran escala
También podríamos pagar la atención médica en Estados Unidos. Pero en la realidad pasa otro día más y un solo AWS US-East 1 puede tirar la mayor parte de internet
Con 2 regiones necesitas el doble de capacidad, con 3 regiones necesitas 1.5 veces la capacidad, y en una configuración multirregión las máquinas ya deben estar corriendo. No debes esperar poder levantar instancias ni conseguir capacidad durante una caída, y además tienes que absorber la complejidad extra del hosting multirregión
Es un poco gracioso ver que las configuraciones de varias regiones/zonas de disponibilidad parecen tan obviamente de adorno y aun así todos las creen como si fueran un credo de la religión de la nube
Este tipo de apuestas es riesgoso. Porque alguien, como un empleado capaz de tumbar AWS, puede apostar
Estas apuestas no son tan inocuas como parecen, porque muchas veces quien apuesta puede influir o cambiar el resultado
En general, estoy de acuerdo con el argumento de que estos mercados de predicción pueden incentivar el uso de información privilegiada y escenarios negativos. Eso crea el incentivo de aprovecharse de esas situaciones para obtener ganancias
Yo pensaba que la refrigeración de un centro de datos estaba casi totalmente planificada de antemano y que no instalaban más de lo que se podía enfriar
Aquí me da curiosidad si fue una falla del equipo de refrigeración, si hubo una causa externa del sobrecalentamiento, o si Amazon está sobrevendiendo la capacidad de refrigeración del centro de datos
Nunca nos dijeron la causa exacta, pero parece que la tubería entre cada piso y el techo no estaba redundada, y la reparación tomó casi 24 horas
La refrigeración de centros de datos, como todo lo demás, tiene a la vez sobreaprovisionamiento y subaprovisionamiento
Los grandes equipos de intercambio térmico están en N+1, y en instalaciones de carga pequeña muy críticas se configuran como 2N/3N, así que están sobreaprovisionados. Eso es porque hay que apagarlos para mantenimiento programado, tienen tasas de falla más altas que los componentes tradicionales de centros de datos y requieren reparaciones mecánicas hechas por personal especializado con tiempos de suministro largos
En instalaciones grandes no es raro que la refrigeración sea N+3 o más a medida que N crece. Siempre hay algo en mantenimiento, o hay equipos esperando piezas porque es más barato fabricar en taller una pieza de algo que ya no existe que reemplazar todo el equipo
Por otro lado, si toda la capacidad de cómputo de una instalación sube repentinamente de su consumo promedio de energía al 100%, entonces se supera la capacidad de refrigeración, así que también está subaprovisionada. La electricidad y otras rutas también suelen quedar sobrecargadas; la naturaleza de la industria se parece mucho a la sobreventa
Normalmente no es un gran problema. Es raro que la carga de cómputo suba al 100% de la capacidad total, y aunque suba, no dura mucho, además de que nadie diseña una instalación con la refrigeración o la potencia operando al filo de la navaja
El problema aparece cuando se cruzan varios eventos. Diseñas el sistema de refrigeración para soportar el 200% de la carga promedio, con margen suficiente para mantenimiento y fallas
El martes un técnico llega a revisar una unidad, detecta un rodamiento defectuoso y como hay que traer la pieza de otro estado, deja la unidad apagada toda la noche para evitar el riesgo de dañar el conjunto del ventilador
Dos unidades de refrigeración vecinas empiezan a trabajar un poco más fuerte, pero una de ellas tenía un motor ligeramente desbalanceado o un fusible flojo que ya se estaba calentando, y una pieza que llevaba años aguantando termina reventando por el aumento de uso
Ahora en una instalación N+2 faltan dos unidades, pero como estaba diseñada para el 200% de la carga promedio, todavía no es crítico
Si una tercera unidad del lado opuesto a la primera defectuosa también falla bajo la carga aumentada, ya son tres unidades menos en una instalación N+2. Aun así, como fue diseñada para el 200% de la carga promedio, todavía no es una catástrofe total
Pero son las 4 de la mañana, el operador en sitio no puede arreglar esa falla, el proveedor se despierta a las 7 y llega a las 9. Mientras tanto, la carga empieza a subir
Esto pasa todos los días en algún centro de datos de Estados Unidos, y probablemente le ocurre a todos los centros de datos al menos una vez al año
La parte que termina saliendo en las noticias es cuando se suma el siguiente evento. Un cliente grande decide que justo ese es un buen momento para lanzar un trabajo masivo por lotes. Alguna fintech corre un modelo grande antes de la apertura del mercado, o una petrolera hace un análisis rápido de un nuevo yacimiento
Levantan 10,000 VM nuevas. En condiciones normales no habría problema porque hay capacidad libre
Pero la refrigeración solo estaba planificada para el 200% de la capacidad promedio de enfriamiento, y este nodo no está ejecutando una carga moderada sino cálculos numéricos intensivos optimizados que consumen la energía máxima y generan el calor residual máximo
Entonces no solo aumenta la carga por cantidad total de máquinas, sino también el impacto del calor residual promedio. Ahí se dispara una falla en cascada y la refrigeración pasa a N-4
Los ventiladores de los servidores empiezan a girar más rápido y a consumir más energía, la refrigeración pasa a N-5. Suenan alarmas por todas partes
Los mecanismos de seguridad de las unidades de refrigeración se activan uno tras otro por la carga y el aumento de presión del refrigerante, y la refrigeración pasa a N-6, N-7 y luego a 0
Me pregunto si este año en la UE Hetzner tuvo mejor uptime que AWS
Siento que la UI de Hetzner es demasiado confusa y difícil de administrar
Publicación relacionada: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
Siempre es East 1. Bromas aparte, no entiendo por qué east-1 se cae tan seguido en comparación con otras regiones
A nivel de arquitectura, parecería que debería ser bastante parecida a las demás regiones
Debe tener más carga que otras regiones, y como se construyó al principio, cuando había menos experiencia, probablemente también arrastra más deuda técnica y deuda de arquitectura/ingeniería
Según recuerdo, hay servicios como IAM o algunas configuraciones de S3 que dependen de east-1 como punto único de falla
Coinbase dijo que varias zonas de disponibilidad se cayeron, pero el anuncio de AWS decía que solo se vio afectada una sola zona de disponibilidad
Me pregunto si alguien sabe más detalles
Estoy operando sistemas en us-east-1 y durante el incidente vi problemas intermitentes de conexión difíciles de explicar y que nunca había visto antes, incluso fuera de az4
Solo algunas cargas en varios entornos tuvieron un pequeño deterioro en volúmenes EBS de una sola zona de disponibilidad, y definitivamente fue un problema de una sola zona de disponibilidad (use-az4)
La vez pasada vi la frase “si eres amigo de alguien, no dejas que use USE1”, y cuando apareció en Slack un mensaje diciendo que USE1 y todo lo desplegado ahí se había roto por completo, me acordé de eso
En los comentarios de aquí hay mucha de la discusión habitual de que us-east-1 está centralizado, que es el punto único de falla de AWS, que hay que arreglarlo y que no deberías desplegar ahí
Esta vez fue un problema de un solo centro de datos dentro de una sola zona de una región multizona
IAM, R53, etc. sí están centralizados ahí, y sería bueno rediseñar esos servicios para que sean descentralizados y entre regiones. Pero us-east-1 en sí ya es una región multizona con 6 zonas, y una séptima prevista para 2026, y dentro de cada zona también hay varios centros de datos
Según recuerdo, cuando se caen servicios globales como IAM, muchas veces no es tanto que “si hubiera sido entre regiones no habría muerto”, sino más bien un bug de implementación o de dependencias
Esta vez no fue una caída de servicios globales de AWS. Lo único que pareció tener un impacto mayor fue MSK, y eso probablemente tenga más que ver con Kafka que con AWS
Me pregunto por qué no construyen estas cosas cerca del mar. Supongo que instalaciones como las plantas nucleares, que necesitan mucha capacidad de refrigeración, hacen algo así
Parecería que bastaría con sacar el calor mediante una circulación de 2 circuitos con intercambiadores térmicos
En los años 90, cerca de la mitad del tráfico global de internet pasaba por MAE-East, y como resultado AWS puso ahí su primera región. us-east-1 apareció 2 años antes que eu-west-1 y 3 años antes que us-west-1
A medida que aumentó la cantidad de gente que sabía construir centros de datos y de proveedores capaces de abastecerlos, el corredor de Dulles se convirtió en un hub principal de centros de datos para varias empresas
En AWS, us-east-1 es la primera región, así que es por mucho la más compleja y rara, y muchos planos de control de otros servicios de AWS terminaron dependiendo de ella. Por eso se cae más seguido que otras regiones y, cuando se cae, a diferencia de eu-south-2 en España, se vuelve noticia nacional
NoVA es solo un caso de centros de datos, no de fábricas, pero es el mismo tipo de clúster económico que estudió Paul Krugman en el trabajo por el que ganó el Nobel de Economía
Uno fue cuando el centro de datos de Hosting.com en SOMA se calentó tanto que intentaron enfriarlo echándole agua con mangueras desde el techo, y el otro fue cuando el centro de datos de Alibaba en Chai Wan se calentó tanto que todo lo que corría ahí, incluido el plano de control, se vino abajo
Así que no creo que estar cerca del mar aporte una ventaja extra desde el punto de vista de la disipación de calor de emergencia. La capacidad para sacar calor al exterior es finita, y todo el sistema tiene que estar diseñado para cumplir cierto rendimiento, estés en la costa o en medio de Nebraska
En las diapositivas aparecían los factores que influyen en la elección del sitio para un centro de datos, y varios incluían la disponibilidad de espacio suficiente y de personal calificado para trabajar ahí. También mencionó que a veces la política influye en la selección de la ubicación del siguiente centro de datos
El terreno costero es mucho más caro y, si te vas a una costa remota, es probable que el acceso a la energía no sea tan bueno
Los sitios costeros también suelen estar expuestos a fenómenos meteorológicos más severos
Y hay cosas menos predecibles. La planta nuclear Diablo Canyon ha tenido problemas con tomas de agua de mar para refrigeración bloqueadas por desechos y migraciones de medusas
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
Además, el agua tiene que ser lo bastante profunda; de lo contrario, termina calentándose hasta la temperatura de la superficie. Y también tendría que ser competitiva en precio frente al enfriamiento evaporativo tradicional
Un caso de libro donde esto funciona bien es Toronto. Tiene relativamente cerca de la costa un lago de agua dulce profundo, y en el centro la vivienda es cara, así que los métodos tradicionales están limitados
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System