Dos zonas de disponibilidad, seis horas de diferencia
A las 12:51 UTC del 2 de marzo de 2026, la zona de disponibilidad que AWS designa mec1-az2, en su región de Oriente Medio Emiratos, dejó de dar servicio con normalidad. A las 18:46 UTC del mismo día, mec1-az3 también estaba afectada. AWS confirmó que ambas habían sido alcanzadas directamente por drones durante el conflicto más amplio en la zona. Una tercera instalación, mes1-az2 en la región independiente de Baréin, se había visto interrumpida hacia las 06:56 UTC de aquel lunes, algo que AWS atribuyó a un impacto de dron en las inmediaciones que causó efectos físicos en su infraestructura.
Los impactos provocaron incendios. Los incendios activaron los sistemas de rociadores de los centros de datos, y el agua dañó el equipamiento. AWS informó de que los clientes veían altas tasas de fallo en la entrada y salida de datos en servicios como S3, que necesita al menos una zona sana por región para funcionar. La compañía estimó que restaurar las instalaciones y sus sistemas de refrigeración llevaría al menos un día.
Retenga esa estimación durante el resto del artículo. Se hizo de buena fe, por un operador con mejor información que ningún cliente, y describía la reparación con exactitud.
La frase del aviso que de verdad importaba
Junto a las actualizaciones de estado, AWS dijo a sus clientes algo de mayor calado. Les aconsejó respaldar sus datos y posiblemente migrar sus cargas a otras regiones de AWS, con el argumento de que el conflicto en curso en la zona hacía impredecible el entorno operativo. Los proveedores de nube no piden a la ligera a un cliente que paga que abandone una región que ellos mismos venden.
Ese aviso es el artefacto útil de todo el episodio, porque es la única instrucción que aborda el modo de fallo real. El daño por rociadores es una reparación. Un entorno operativo impredecible no es una reparación, es una propiedad del emplazamiento, y ninguna ingeniería dentro del edificio la cambia. AWS estaba diciendo en la práctica a sus clientes que la respuesta correcta a esta clase de suceso es la salida y no la paciencia.
La parte incómoda: la mayoría de los manuales de recuperación tienen una página para esperar y ninguna para marcharse.
Al menos un día, medido contra el calendario
El 30 de abril, el propio estado de servicio de AWS decía que la región de Oriente Medio Emiratos había sufrido daños a consecuencia del conflicto en Oriente Medio y no podía en ese momento sostener con fiabilidad las aplicaciones de los clientes. Fíjese en lo que cambió en esa frase. En marzo la región tenía una caída y una estimación. A finales de abril tenía una condición y ninguna estimación en absoluto.
El 28 de julio Cloudflare publicó su revisión trimestral de sucesos de interrupción de internet, extraída de los datos de red de Radar. En ella consta que el tráfico HTTP hacia me-central-1 ha seguido bajo, y describe la reducción sostenida como la firma aguas abajo del daño físico a la infraestructura del centro de datos subyacente. Eso es una medición independiente en lugar de una declaración del proveedor, y apunta en la misma dirección unos cinco meses después de los impactos.
La aritmética que llevar a su próxima revisión de continuidad: la estimación publicada fue al menos un día, y la respuesta observable se sigue midiendo en meses.
La resiliencia regional se diseñó para el fallo equivocado
La arquitectura con múltiples zonas de disponibilidad es una respuesta genuinamente buena al fallo para el que se diseñó. Las zonas se separan para que un incendio, una inundación, un incidente eléctrico o un fallo de red en una no arrastre a las otras. Ese supuesto de diseño aguanta de maravilla cuando el peligro es local a un edificio e independiente entre edificios. Deja de aguantar cuando el peligro es regional y está correlacionado, porque entonces la separación entre zonas se mide en kilómetros y lo que causa el daño no.
Dos de las tres zonas de Emiratos fueron alcanzadas el mismo día. Una instalación en otra región, en otro país, se vio afectada esa misma semana. La independencia de zonas es una afirmación física sobre una lista concreta de peligros, y el conflicto armado no está en esa lista. Conviene decirlo con claridad porque es la parte que después parece obvia y antes casi nunca aparece en una revisión de diseño.
Para las empresas europeas la obligación ya existe: las entidades financieras sujetas a DORA deben a su supervisor un plan documentado de salida y continuidad para los proveedores críticos de TIC, y ese plan debe sobrevivir a que una región del proveedor quede indisponible y no meramente lenta.
Cuatro cambios en su manual esta semana
Primero, ponga por escrito su objetivo real de tiempo de recuperación ante la pérdida de una región entera y no de una zona, y sea honesto sobre si alguna vez lo ha probado. Si la respuesta honesta es que la pérdida de región queda fuera de alcance, eso es una decisión, y debe quedar registrada con un responsable con nombre en lugar de como una omisión. Segundo, separe sus escenarios de reparación de sus escenarios de salida. Un escenario de reparación espera. Un escenario de salida se mueve, y necesita sus datos, su configuración de identidad y sus rutas de red ya preparados en otro sitio.
Tercero, decida por adelantado qué evidencia dispararía un traslado. El disparador útil aquí no fue la caída del 2 de marzo, fue el aviso que decía a los clientes que consideraran migrar. Los proveedores rara vez dicen eso, y cuando lo hacen debe tratarse como la señal y no como ruido de fondo. Cuarto, compruebe dónde están físicamente sus copias de seguridad. Una copia dentro de la región de la que intenta salir no es una copia, y el momento en que la necesita es el momento en que la región es el problema.
Leer a continuación: OpenAI le pagó con aquello que falló | Un cuarto gigante de la nube es más plausible
