AWS confirma que los datos de su Region de Baréin no vuelven

Seis meses después de los ataques con drones, AWS declaró irrecuperables los datos alojados solo en me-south-1 y en la AZ mec1-az2 de EAU: el daño excedió lo que el diseño multi-AZ soporta.

Seis meses después de los ataques con drones que dañaron sus centros de datos en el Golfo, AWS acaba de decir en voz alta lo que nadie quiere leer de un proveedor de nube: los datos que vivían únicamente en su Region de Baréin no van a volver. No hay una fecha de restauración, no hay un plan de recuperación pendiente. Se perdieron.

Qué pasó

El 15 de septiembre AWS publicó en su Health Dashboard su primera actualización pública sobre el incidente desde abril. El mensaje es corto y definitivo: todo lo que estuviera alojado exclusivamente en la Region de Baréin (me-south-1) sigue inaccesible y así se va a quedar.

"El daño a nuestra infraestructura abarcó múltiples Availability Zones y excedió lo que nuestros servicios regionales y multi-AZ están diseñados para soportar. Tras una evaluación exhaustiva, hemos determinado que no podemos restaurar el acceso a los recursos y datos alojados exclusivamente en esta Region." — AWS Health Dashboard, 15 de septiembre de 2026

La misma conclusión aplica, en menor escala, a Emiratos Árabes Unidos: la Availability Zone mec1-az2 —una de las tres de la Region de EAU— tampoco se recupera. AWS dice que sigue trabajando en mec1-az1 y mec1-az3, las otras dos zonas afectadas, y que "la mayoría de los clientes" ya reanudaron operaciones en otras Regions restaurando desde backups o copiando lo que quedó accesible.

Consultado por The Register, AWS declinó añadir nada a lo publicado en el dashboard.

Ficha técnica

Region perdida

Baréin (me-south-1) — inaccesible de forma permanente

AZ perdida

mec1-az2 (Region EAU), 1 de 3 zonas

En recuperación

mec1-az1, mec1-az3

Causa

daño físico por ataques con drones (marzo–abril 2026)

Estado

sin restauración posible; AWS confirmó pérdida definitiva el 15-sep-2026

Alcance del diseño

el daño excedió la tolerancia multi-AZ de la Region

zonas de disponibilidad aisladas, una de ellas fracturada y a oscuras — Imagen | Generada con IA

La línea de tiempo

Marzo 2026. En los primeros días de la guerra entre Estados Unidos e Irán, dos centros de datos de AWS en EAU son golpeados directamente por drones. Una instalación en Baréin queda dañada por un impacto cercano. El Cuerpo de la Guardia Revolucionaria Islámica reclama la autoría y declara que atacó el sitio de Baréin por el apoyo de Amazon al ejército estadounidense.
Marzo 2026. Tras el daño a la primera AZ de Baréin, AWS avisa a sus clientes que migren cargas a otras Regions y advierte que la inestabilidad en Medio Oriente probablemente continúe, volviendo las operaciones "impredecibles".
Abril 2026. Nuevos ataques afectan una segunda Availability Zone en Baréin y dejan la Region entera indisponible. AWS publica una actualización y después guarda silencio público.
15 de septiembre de 2026. Seis meses después, AWS confirma que ni Baréin ni mec1-az2 son recuperables.

Vale la pena subrayar el dato que AWS sí ofrece como consuelo: la mayoría de los clientes se movió a tiempo, entre el aviso de marzo y el colapso de abril. Los que no lo hicieron son los que hoy no tienen a quién pedirle sus datos.

Por qué importa

Toda la disciplina de arquitectura en la nube se enseña con la misma jerarquía: una Region es un área geográfica que contiene varias Availability Zones aisladas, y cada AZ son uno o más centros de datos con energía, enfriamiento y red independientes. Distribuye tu aplicación en varias AZ y sobrevives a la pérdida de un sitio. Ese es el mantra, y funciona muy bien para el modo de falla que se diseñó: incendio, inundación, corte eléctrico, un backhoe cortando fibra.

Lo que este caso demuestra es que el aislamiento entre AZ es una propiedad de ingeniería, no un escudo. Las tres AZ de una Region están, por definición, en la misma área geográfica. Frente a una amenaza que opera a escala geográfica —un conflicto armado— la separación de decenas de kilómetros deja de ser una barrera. AWS lo dice con precisión quirúrgica: el daño "excedió lo que nuestros servicios regionales y multi-AZ están diseñados para soportar".

Dos consecuencias prácticas, y ninguna es teórica ya:

Multi-AZ no es DR. Es alta disponibilidad dentro de una Region. Si tu RPO/RTO asume que una Region completa nunca desaparece de forma permanente, tu plan de continuidad tiene un supuesto que ya se rompió en producción, con nombre y con fecha.
El riesgo geopolítico entró al diagrama de arquitectura. La pregunta de dónde vive el dato ya no es solo de latencia, costo y soberanía regulatoria. Ahora también es de exposición física a conflicto. Y el modelo de responsabilidad compartida sigue en pie: elegir la topología es del cliente.

replicación de datos entre regiones geográficamente distantes — Imagen | Generada con IA

El efecto colateral: el boom de datacenters del Golfo

El Golfo lleva dos años posicionándose como el tercer polo mundial de infraestructura de IA, con capital soberano detrás y anuncios de gigavatios. El caso más visible es UAE Stargate, el campus que OpenAI, Nvidia, Oracle y Cisco firmaron como socios centrales en mayo de 2025: 5 GW proyectados sobre unas 10 millas cuadradas.

Según CNBC, EAU ahora está considerando revisar el proyecto para dispersar las instalaciones por el país en lugar de concentrarlas, y sumar medidas de seguridad reforzadas que incluirían construir algunos sitios bajo tierra. Es un cambio de premisa notable: la concentración masiva —que es justamente lo que hace eficiente un campus de entrenamiento de IA, por la interconexión de baja latencia entre decenas de miles de GPUs— resulta ser exactamente lo que un dron convierte en un solo punto de falla.

Ese es el fondo del asunto y no se resuelve con un SLA. La economía de la IA empuja hacia la concentración; la seguridad física empuja hacia la dispersión. En regiones estables la tensión es administrable. En un teatro geopolítico caliente, no.

Qué hacer

Si operas cargas en la nube —y más si eres el que firma el plan de continuidad—, esta es una buena semana para revisar cuatro cosas:

Inventaría lo que vive en una sola Region. No preguntes "¿tengo multi-AZ?", pregunta "¿qué se pierde para siempre si esta Region no vuelve?". Buckets S3 sin replicación cross-region, snapshots de RDS que nunca salieron de casa, backups de Backup Vault en la misma Region que el origen, imágenes AMI y secretos en un solo lugar. Todo eso es el mismo huevo en la misma canasta.
Verifica que el backup esté fuera del dominio de falla. Un backup en la misma Region que el dato productivo no es un backup ante este escenario, es una copia. Cross-Region Replication, copias de snapshot a otra Region y, para lo verdaderamente crítico, una copia en otro proveedor o en on-prem.
Prueba el restore, no solo el respaldo. Los clientes que salieron bien de esto son los que pudieron restaurar en otra Region. Un restore que nunca se ensayó es una hipótesis. Métele un game day con la Region primaria declarada perdida y cronómetro.
Mete el riesgo geopolítico al criterio de selección de Region. Para cargas sensibles, evalúa la exposición física y la estabilidad del país, no solo la latencia al usuario. Y documenta la decisión: cuando el auditor pregunte por qué el DR está donde está, la respuesta debe existir por escrito.

La lectura

El mensaje del Health Dashboard es de las cosas más honestas que ha publicado un hyperscaler: hay un límite de diseño, se rebasó, y no hay magia detrás. La nube nunca prometió ser indestructible; prometió una tolerancia específica a fallas específicas. Lo que cambió en 2026 no es la nube, es el catálogo de amenazas: el modelo de riesgo de la infraestructura crítica ya incluye la guerra convencional, y el diagrama de tu arquitectura tiene que reflejarlo.

Y si algo se queda de este caso, es la frase que va a repetirse en cada revisión de arquitectura de aquí en adelante: "alojado exclusivamente en". Esa preposición es la que costó los datos.