El día en que unos objetos tumbaron la región de AWS en EAU y sacudieron la fe de DevOps
Parece el argumento de una novela de suspense tecnológico: "objetos" cruzando el cielo, chispas dentro de un centro de datos a hiperescala y, de repente, partes de internet se apagan. Salvo que esto no era ficción. Uno de los centros de datos de Amazon en los Emiratos Árabes Unidos fue alcanzado en pleno aumento de la tensión en la región, lo que provocó un incendio, un corte de energía y una caída en cascada que afectó a los servicios principales de AWS.
Para los ingenieros que se han pasado la última década defendiendo la resiliencia multi-AZ como una verdad absoluta, el incidente se vivió de otra forma. Nadie podía culpar a un despliegue con errores ni a un router mal configurado; la geopolítica había atravesado de lleno la capa de abstracción. Cuando los bomberos cortaron la electricidad de las instalaciones y de sus generadores, poco importaba lo limpio que estuviera tu Terraform: la nube se volvió, de golpe, algo muy físico.
"Afectado por objetos": cuando la abstracción choca con la realidad
En palabras del propio AWS, una Zona de Disponibilidad en la región ME-CENTRAL-1 se vio "afectada por objetos" que golpearon el centro de datos, generando chispas y fuego. La redacción fue comedida, casi clínica, para unas consecuencias que fueron todo menos eso.
Los clientes reportaron interrupciones en EC2, RDS y DynamoDB, junto con lentitud en las API. El panel de estado de AWS mostró un radio de impacto cada vez mayor: aumento de errores en la API de EC2, fallos al lanzar instancias, tasas de error y latencia significativas en DynamoDB y S3, además de recomendaciones para hacer failover a otra región. En cierto momento, lanzar nuevas instancias en la región resultaba imposible.
Un informe de Business Insider vinculó el incendio con ataques militares en Oriente Próximo, señalando que la empresa no concretó qué eran esos "objetos". Fotos y vídeos que circulaban por internet mostraban misiles en el cielo sobre zonas del Golfo. El mensaje era ambiguo, pero el significado quedó claro: la infraestructura en la nube se había convertido en un daño colateral.
La ilusión de multi-AZ, ¿o la prueba de que funciona?
AWS lleva años vendiendo las Zonas de Disponibilidad como dominios de fallo aislados, con suministro eléctrico independiente, redes independientes y todo por separado. La premisa es sencilla: diseña entre varias AZ y quedarás protegido frente a fallos localizados.
En su informe, AWS subrayó que los clientes con aplicaciones redundantes entre AZ no se vieron afectados por el suceso inicial. Para algunos equipos, fue una confirmación. "Es literalmente la razón por la que diseñamos las arquitecturas así", escribió un ingeniero. "Si en 2026 sigues en una sola AZ, es culpa tuya". Es la postura pragmática y curtida de DevOps: tenías las herramientas y estabas avisado.
Sin embargo, la caída no se quedó debidamente contenida. Actualizaciones posteriores describieron un "problema de suministro localizado" que afectó a más Zonas de Disponibilidad en la misma región, con múltiples servicios degradados o interrumpidos. Cuando el lanzamiento de instancias falla en toda la región y las API principales devuelven errores, hasta los sistemas bien diseñados sufren la tensión.
Una voz más escéptica intervino: "Multi-AZ te protege de fallos en un rack, quizá incluso de problemas en todo el edificio. No te protege de misiles". Ese comentario transmitía menos seguridad y bastante más inquietud.
Luego estaba el tercer grupo, el de los realistas pragmáticos. "Por esto importa la multirregión", argumentaba alguien. "Tener varias AZ es lo básico. La región es el verdadero muro de contención".
Haz failover, ahora
A medida que avanzaba el incidente, AWS recomendó de forma explícita que los clientes hicieran "failover y copia de seguridad de cualquier dato crítico a otra región de AWS". Dicho de otro modo: esto iba para largo.
Para los equipos que habían ensayado la recuperación ante desastres, este era el momento para el que se redactaron esos runbooks: aplicar cambios de DNS, promover réplicas, escalar en otra región y respirar hondo.
Para otros, fue el caos. El failover entre regiones cuesta dinero, y su complejidad es un peaje mensual en infraestructura duplicada, replicación de datos y sobrecarga operativa. Muchas startups e incluso empresas medianas funcionan en una sola región sin mayores aspavientos porque los números suelen cuadrar, hasta que dejan de hacerlo.
"Siempre dije que pasaríamos a multirregión al llegar a la Serie C", escribió un fundador anónimo. "Parece que acabamos de recibir nuestro toque de atención de la Serie C".
Hay una sinceridad cruda en esas palabras. Las buenas prácticas en la nube se apoyan con facilidad en la teoría, pero en el día a día se imponen los presupuestos, los plazos y las prioridades contrapuestas. Esta caída forzó un doloroso recálculo del coste real del tiempo de inactividad cuando lo provoca un acontecimiento geopolítico en lugar de un balanceador de carga mal configurado.
La geografía de internet es política
La cobertura de Business Insider dejó otra cosa incómodamente clara: no se trataba de un fallo técnico fortuito. El incendio ocurrió en el contexto de ataques militares estadounidenses e israelíes contra Irán y respuestas en el Golfo.
Durante años, los proveedores de nube vendieron la expansión regional como mero crecimiento. Más regiones significaban menos latencia, cumplimiento de residencia de datos y clientes más contentos. Sin embargo, cada nueva región es también una huella física en el mapa político. Un centro de datos es un edificio con coordenadas, además de racks y sistemas de refrigeración, y puede ser alcanzado.
Algunos analistas opinaron que es simplemente el coste de operar en regiones inestables. "¿Quieres baja latencia en Oriente Próximo? Construyes allí. Y a veces eso implica asumir riesgos", escribió alguien.
Otros discreparon con firmeza. "Por esto las cargas de trabajo críticas no deberían aislarse regionalmente en zonas geopolíticamente inestables. El cumplimiento normativo es una cosa; la concentración a ciegas es otra muy distinta".
La tensión existe. Cada vez más gobiernos exigen que los datos permanezcan dentro de las fronteras nacionales, de modo que las empresas cumplen y despliegan infraestructura local. Cuando estalla un conflicto, esa misma localización puede multiplicar la exposición. La nube, por mucho brillo que tenga en las presentaciones comerciales, sigue respondiendo ante la geografía.
Transparencia, medida con lupa
Los partes de AWS fueron frecuentes y detallados a nivel operativo, con cronologías, API afectadas, medidas de mitigación y recomendaciones para reintentar peticiones fallidas o indicar ID de forma explícita en llamadas a Describe. Para los ingenieros en primera línea, ese nivel de detalle importa.
Al mismo tiempo, la explicación sobre el origen mantuvo la cautela: "objetos que golpearon el centro de datos". La compañía no dio más detalles sobre la naturaleza de dichos objetos.
Algunos lectores agradecieron esa contención. "No son un medio de noticias. Dan a los clientes lo necesario para restablecer el servicio", opinó un participante. "Especular no ayuda a nadie".
Otros consideraron que la redacción rozaba lo surrealista. "¿Objetos? Todos sabemos lo que significa. Que lo digan claro", escribió otro. "Si unos misiles pueden dejar fuera de juego una AZ, los clientes merecen entenderlo sin rodeos".
La comunicación de crisis es un equilibrio delicado. Demasiados detalles atraen titulares y alarma; quedarse corto parece una evasiva. En este caso, AWS prefirió la claridad técnica al comentario político. Si eso genera confianza o la desgasta dependerá del lado de la caída en el que te encontraras.
El largo proceso de recuperación
Incluso tras las primeras mitigaciones, el panel de salud de AWS describió una "recuperación más prolongada" para instancias EC2, volúmenes EBS y otros recursos en la zona afectada. Restablecer la energía no suponía cruzar la meta. Había que levantar los sistemas de forma segura, verificar la integridad de los datos y estabilizar la red.
Los clientes rara vez ven esta parte. Hablamos de "la nube" como si fuera un interruptor que vuelves a encender, cuando levantar un centro de datos a hiperescala tras un incendio se parece más a reiniciar una pequeña ciudad. Un responsable de operaciones lo resumió sin rodeos: "No reinicias una región apretando un botón".
También queda una secuela psicológica. Aunque los paneles vuelvan al verde, la confianza no regresa al instante. Los equipos programan simulacros, la dirección hace preguntas incómodas sobre continuidad de negocio y el consejo de administración pide diapositivas sobre la exposición al riesgo regional. Una caída desaparece de las páginas de estado mucho antes de borrarse de la memoria.
Tres lecciones sin respuestas sencillas
La primera lección resulta casi previsible por conocida: la redundancia funciona, pero solo si la utilizas. Quienes tenían arquitecturas repartidas entre varias AZ quedaron protegidos del impacto inicial, y eso ocurrió en producción, lejos de folletos comerciales.
La segunda lección es más contundente. Diseñar pensando en una sola región resulta frágil en un mundo donde la infraestructura puede sufrir ataques físicos. Disponer de varias AZ ya no es el techo, y la multirregión podría convertirse en el nuevo estándar para sistemas de misión crítica.
La tercera lección es la más difícil de asumir: hay riesgos que la abstracción no puede borrar. Los proveedores de nube pueden prepararse para inundaciones, incendios o fallos de hardware, distribuir el tráfico y esquivar componentes dañados. Cuando un conflicto geopolítico entra en escena, hasta las arquitecturas más elaboradas quedan expuestas.
Una voz lo resumió con una reflexión que se queda contigo: "Construimos la nube para escapar de las ataduras físicas. Resulta que solo las movimos de sitio".
Nada de esto significa abandonar la nube. Al contrario, este incidente demostró tanto su vulnerabilidad como su capacidad de recuperación: se redirigió el tráfico, los servicios volvieron a funcionar y las indicaciones llegaron con rapidez. Lo que sí hizo fue derribar el cómodo mito de que "la nube" flota ajena a la compleja realidad del mundo. Está en edificios, en ciudades y en países, y a veces esos edificios reciben el impacto de "objetos".