- La caída del AWS, el servicio de nube más grande del mundo, dejó fuera de línea miles de sitios web y apps, encendiendo alertas sobre la dependencia excesiva de la infraestructura de internet en pocas empresas
- Entre los servicios afectados estuvieron Snapchat, Roblox, Signal y Duolingo, así como instituciones públicas y financieras como Lloyds Bank, Ring y HMRC
- AWS atribuyó el incidente a un error interno de sistema en su región este de EE. UU., descartó una posible amenaza cibernética y recuperó la mayoría de los servicios en pocas horas
- Expertos advirtieron que “la base del discurso democrático y el periodismo independiente no debería quedar supeditada a la infraestructura de unas pocas compañías”, y enfatizaron la necesidad de diversificar la infraestructura en la nube
- La estructura dominada por grandes proveedores de nube habría revelado la fragilidad de internet a nivel global y reavivado el debate sobre la soberanía tecnológica de la infraestructura pública
Descripción general de la caída
- En la región US-East-1 (este de EE. UU.) de AWS, un error interno provocó una interrupción masiva de servicios globales
- La caída comenzó alrededor de las 8:00 a. m. (hora local) del lunes,
- Amazon señaló que la tasa de errores de API y la latencia aumentaron
- Según Downdetector, el impacto alcanzó a más de 2.000 empresas en todo el mundo, y se reportaron incidentes de más de 1,9 millones en EE. UU., 1 millón en Reino Unido y 410.000 en Australia
- AWS identificó como causa un problema en el subsistema de supervisión del balanceador de carga interno y descartó la posibilidad de un ataque cibernético
- Se reportó un error relacionado con DynamoDB, que provocó fallos en la respuesta de API
- Para evitar una avalancha de tráfico, AWS introdujo temporalmente un límite al número de solicitudes
- AWS anunció por la tarde un “retorno a la operación normal”, aunque algunos servicios siguieron reportando interrupciones
Alcance del impacto
- Servicios principales: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton y varios más
- En Reino Unido, hubo caída en el acceso al sitio web de instituciones financieras como Lloyds, Halifax y Bank of Scotland y a HMRC (la agencia tributaria)
- Usuarios de Ring Doorbell informaron interrupciones en el servicio de monitoreo de apertura de puertas
- También se reportaron fallos de acceso en plataformas globales como Epic Games, Pokémon Go y Wordle
Análisis de expertos
- Dr. Corinne Cath-Speth (Article 19): “Es riesgoso que los cimientos del discurso democrático y de un periodismo independiente dependan de la infraestructura de pocas empresas. La diversificación de la nube es urgente”
- Cori Crider (Future of Technology Institute): “Reino Unido debe alejarse de la dependencia de las Big Tech estadounidenses. Este fue un caso donde la economía moderna se paraliza por una sola caída de AWS”
- Madeline Carr (UCL): “La capacidad de inversión de las grandes nubes mantiene la seguridad y la escalabilidad, pero la estructura que encadena al mundo entero a un mismo riesgo es extremadamente peligrosa”
- Steven Murdoch (UCL): “Se estima que la causa fue un error operativo interno de AWS, y no un ciberataque”
Respuesta gubernamental y regulatoria
- El gobierno británico declaró que activó canales de contacto de emergencia con AWS y monitoreó la situación de la recuperación
- El Comité de Finanzas de la Cámara de los Comunes pidió que AWS sea designado como “tercero crítico” en el sector financiero
- Si eso ocurre, AWS quedará bajo supervisión de los reguladores financieros, lo que permitiría reforzar la estabilidad de la infraestructura financiera
- La presidenta de la comisión, Meg Hillier, criticó que AWS “hable de resiliencia” mientras, en la práctica, exponía vulnerabilidad
Contexto y consecuencias
- AWS concentra más del 30 % del mercado global de nube, liderando con amplia ventaja
- Junto a Microsoft Azure y Google Cloud, avanza una estructura de concentración de tres nubes dominantes
- En 2024, una falla de software de CrowdStrike provocó el conocido “pantallazo azul” global en PCs con Windows
- Este incidente volvió a destacar el riesgo sistémico de la concentración en la infraestructura digital y encendió discusiones en distintos países sobre soberanía tecnológica y estrategias de dispersión de la nube
3 comentarios
¡Ánimo, Naver Cloud!
“Si no quieres la nube, arma y usa tu propia infraestructura.” Entonces me pregunto si realmente hay algo discutible.
¿Multi-cloud? La implementación y la administración tampoco te las va a hacer nadie.
Opinión de Hacker News
Actualmente se está discutiendo que varios servicios están caídos en AWS us-east-1, y hay un hilo largo al respecto aquí.
En 2021, durante la caída de Fastly también hubo críticas similares por parte de “expertos”, pero en la práctica no hubo ningún cambio claro. Una semana después, esto ya no aparece en los periódicos. Los profesionales saben lo difícil que es operar a escala de AWS. Las medidas reales para prepararse para esto son tan costosas que para la mayoría de las empresas el beneficio es mínimo. Si un servicio es realmente “crítico”, entonces sí debería diseñarse para aguantar este tipo de fallas. El hecho de no poder iniciar sesión en Fortnite muestra lo poco realista y costoso que es implementarlo en la práctica. Los medios normalmente no hablan de la importancia de la multirregión o la multicloud hasta que ocurre un incidente y luego lo olvidan rápido. Al final, uno solo se queda con la curiosidad de cuál fue la causa técnica. Las críticas de los “expertos” sin seguimiento no significan mucho. Lo importante es un análisis de incidente constructivo y sin culpas, mejor que una crítica sin acciones de seguimiento.
Cuestionar la dependencia de la nube te lleva, en la práctica, a aceptar que habrá que aguantar más de 16 horas de downtime al año. Cuando hay una caída de unas pocas horas, los usuarios la sienten mucho, pero en realidad la degradación de rendimiento del resto de las 8,742 horas puede ser más grave. Si 16 horas de caída bastaran para hundir una empresa, entonces yo o la otra persona no entendemos bien el negocio. A mí me interesan más la alta disponibilidad, la georedunancia y la durabilidad alta de los sistemas.
La redundancia multirregional/multicloud que se menciona en la prensa la considera con poca efectividad. Aunque en apariencia parezca que solo una región está fallando, en realidad muchas veces el impacto se extiende a servicios distribuidos en varias regiones. El hot standby multicloud se vuelve bastante costoso a medida que la infraestructura se complica. Sin una planificación inicial, incorporarlo después es muy difícil.
Tal vez habría que intentar hablar de “la nube” o “internet” como “el almacén de Virginia”. Por ejemplo: “nuestro servicio está completamente en el almacén de Virginia”, “todos mis archivos están en el almacén de Virginia”, “el almacén de Virginia está diseñado para resistir una guerra nuclear”, etc. Original
Ya hay distintos proveedores de VPS, y hay casos recurrentes de que al migrar ahí se reducen costos; en la práctica esto es un tema de lock-in de nube y marketing.
Hoy en día las empresas usan servicios PaaS de alto nivel de AWS como DynamoDB y RedShift, no servicios IaaS de bajo nivel como EC2. Azure y Google Cloud están en una situación similar. Si te atascas a esos servicios de alto nivel, migrar a VPS como Hetzner o self-hosting implica volver a instalar y operar el stack de AWS desde cero, lo que es tremendamente complejo. No basta con “solo instalar PostgreSQL”.
A los posts que dicen que bajaron costos con VPS siempre le siguen réplicas tipo “AWS es web scale y no se cae, mientras que VPS solo tiene un día de uptime al mes”.
Amazon también ofrece un VPS como EC2; me pregunto si EC2 también se vio afectado en este incidente.
La opinión de “expertos” suele enfocarse más en el contexto geopolítico (por ejemplo, la dependencia en tiempo real del sistema de un país entero a una empresa extranjera) que en lo técnico. Para una empresa común, depender de un solo proveedor reduce la complejidad y no empeora la frecuencia de fallas. No hace falta usar multi-cloud. Incluso con uno solo, la frecuencia de caídas puede mejorar.
Creo que toda la industria está atrapada en el lock-in de la nube. Me pregunto cómo podremos deshacerlo. Yo diría que Docker también es uno de los causantes del lock-in, al igual que los grandes proveedores cloud.
Desde el punto de vista de un ingeniero de operaciones o personal de soporte, la realidad es que a la 1 a. m., al detectar que todo AWS había colapsado y todo se había roto, nadie busca cambiar esa situación.
Me intriga por qué Docker es un problema.
Dejé la operación de nube hace tiempo, pero en ese momento las capacidades base (“primitives”) se estaban igualando entre proveedores. Me pregunto si la redundancia multicloud era demasiado costosa, si la brecha técnica era alta o si ni siquiera valía la pena analizarlo desde una perspectiva de negocio. Diapositiva pets vs cattle
Desplegar y operar en múltiples nubes es una carga de gestión y cognitiva enorme para el equipo. Mantener experiencia técnica en infraestructura de dos o más nubes requiere mucho personal. No es adecuado para equipos pequeños o muy rápidos. La simplicidad de usar una sola nube se traduce en más uptime. Para las grandes empresas suele ser más conveniente comprar en volumen en un solo cloud y bajar costos unitarios. Y nadie pierde su trabajo por haber elegido AWS.
La multicloud es poco efectiva porque si un otro cloud tiene caída en su región, tampoco puede responder si el otro cae. Los proveedores siguen imponiendo al 100% su propio estándar, y el plano de control sigue siendo Kubernetes. Al final, todos terminaron en Kubernetes.
Todos los clouds ofrecen compute barato, pero el egreso de red es escandalosamente caro. Montar multicloud hace que el costo de tráfico se dispare. Esto me parece deliberado.
En la práctica parece que los proveedores ganan dinero con la tarifa de egreso. Por eso, en muchos clouds y aplicaciones, la redundancia multicloud, e incluso la redundancia entre regiones o AZ dentro de un mismo cloud, resulta demasiado cara. Si hay una caída global en una nube, la redundancia por región tampoco sirve. Además, mover tráfico a otro cloud cuando uno cae es difícil y el costo en trabajo no se justifica frente al beneficio. Para la mayoría de aplicaciones es mejor asumir esas pocas horas de caída y usar dinero y esfuerzo en otras prioridades.
Hay muchos clientes con archivos/datos en la nube; si esos datos están en otra nube que la del proveedor, operar el servicio no es fácil y tampoco ayuda a captar clientes reales. Como el proveedor se convierte en el estándar del mercado y los clientes concentran sus datos ahí, cuesta justificar el costo de usar almacenamiento en ambas nubes. Yo también empecé queriendo ser independiente de plataforma, pero en realidad la complejidad bajó porque todos los clientes potenciales usan la misma nube.
No se podía prever antes de este año que AWS us-east-1 solo alcanzaría dos nueves de uptime.
Como alguien que lleva cerca de 20 años usando AWS, no entiendo por qué elegirían us-east-1, que es la de más tráfico y criticidad. Es uno de los más antiguos y el más inestable.
Me pregunto si instancias como EC2 también se vieron impactadas en la práctica.
Se piensa que si todo se cae, estás exonerado, pero con un servicio para clientes comunes, la experiencia dice lo contrario.
La causa de este incidente estaba en un subsistema interno encargado de los health checks de los balanceadores de carga de red. Página de estado de servicios de AWS