AWS confirmó que no puede recuperar los datos de su región en Bahréin: la pregunta que tu respaldo no responde

El 15 de septiembre de 2026, AWS confirmó algo que ningún proveedor de nube grande había admitido antes: no puede restaurar el acceso a los datos de clientes alojados exclusivamente en su región me-south-1, en Bahréin, ni en la zona mec1-az2 de su región me-central-1, en Emiratos Árabes Unidos. No es una interrupción. Es pérdida permanente. Y le pega directo a cualquier empresa que tenga un sistema completo viviendo en una sola región de un solo proveedor, sin copia restaurable en otro lado.

El dato que importa no es la guerra en Medio Oriente. Es que "alta disponibilidad dentro de una región" y "respaldo fuera de la región" son dos cosas distintas, y buena parte de las empresas que contratan nube las confunde sin saberlo hasta que es tarde.

Qué confirmó AWS, y qué no había confirmado nunca antes

El origen son los ataques con drones que, según reivindicó la Guardia Revolucionaria de Irán, golpearon instalaciones de AWS en Emiratos Árabes Unidos en marzo de 2026, con daño adicional en Bahréin por una explosión cercana. Entre marzo y abril de ese año hubo interrupciones repetidas en ambas regiones, documentadas en el reporte de Help Net Security sobre el anuncio.

Seis meses después, AWS cerró el expediente con una frase que vale la pena leer completa, citada por InfoQ a partir del comunicado de AWS: el daño a su infraestructura en Bahréin "abarcó múltiples zonas de disponibilidad y superó lo que nuestros servicios regionales y multi-AZ están diseñados para resistir". En Bahréin cayeron las tres zonas de disponibilidad de la región. En Emiratos, una de tres, la mec1-az2, quedó también sin recuperación posible.

AWS fue explícito sobre a quién no le pasó nada grave: la mayoría de sus clientes en ambas regiones ya se había reubicado antes de que la pérdida se volviera permanente, usando respaldos propios o reconfigurando su operación en otra región, según recoge The National en su cobertura del anuncio. A los que no tenían ese respaldo, AWS les dijo literalmente que agotó cada opción posible para recuperar lo que no se había migrado a tiempo. No hay apelación ni compensación que devuelva el dato.

Multi-AZ no es multi-región, y la confusión le costó caro a quien la tenía

Aquí está el error de diseño que repiten muchas empresas, y que este caso vuelve imposible de ignorar. Una región de AWS se compone de varias zonas de disponibilidad, centros de datos físicamente separados mentro de un radio de unos 100 kilómetros entre sí. Ese diseño multi-AZ protege contra una falla de energía, un incendio local o un problema de hardware en un solo centro de datos. No está construido para resistir un evento que daña varias zonas de la misma región al mismo tiempo, sea un sismo mayor, un huracán que cubra toda una zona metropolitana, o un ataque como el de este caso.

La replicación entre regiones es una capa distinta, y es la única que responde a la pregunta "¿qué pasa si toda la región desaparece?". Contratar un plan de alta disponibilidad multi-AZ y dar por hecho que eso cubre también el escenario de pérdida regional es el malentendido exacto que separó, en este incidente, a quien perdió datos para siempre de quien sólo tuvo una interrupción operativa.

Vale aclarar lo que no hay que sacar de esta historia: no es que la nube sea poco confiable, ni que un proveedor sea mejor que otro. El riesgo de concentrar todo en una sola región existe en cualquier proveedor grande, no es exclusivo de AWS. El punto es arquitectónico, no de marca.

Lo que sí puede medirse: el costo de tener la copia fuera de la región

La razón por la que muchas empresas no replican entre regiones no es que no sepan que deberían. Es que mover datos entre regiones cuesta, y ese costo se acumula mes con mes mientras el riesgo que cubre parece remoto, hasta que deja de serlo.

AWS cobra por transferencia de salida entre regiones, y la tarifa depende del origen y el destino: desde us-east-1 hacia la mayoría de los destinos el precio ronda 0.02 dólares por gigabyte, con excepciones que llegan hasta 0.08 dólares por gigabyte hacia regiones específicas como Asia Pacífico (Tailandia), según el desglose de tarifas verificado en septiembre de 2026. A esa cifra hay que sumarle el almacenamiento duplicado en la región de respaldo y, si se quiere recuperación rápida, infraestructura en espera corriendo ahí también. Para un dataset de varios terabytes con cambios diarios, es un gasto recurrente real, no un redondeo en la factura.

Ese costo es precisamente la comparación que hay que hacer, y no contra cero: es contra el costo de perder el dato por completo, que para una empresa de certificaciones, una aseguradora o cualquier negocio que viva de registros que no pueden reconstruirse, no tiene piso.

La auditoría que tu empresa necesita hacer esta semana

No hace falta un rediseño completo de la infraestructura para responder la pregunta que AWS no te va a hacer. Hace falta esta auditoría, en este orden:

1. Inventario de dependencia por región. Lista cada sistema de misión crítica (facturación, expedientes, bases de datos transaccionales) y anota en qué región y en qué proveedor vive. Si no lo sabe tu equipo de TI de memoria, ese ya es el primer hallazgo.
2. Verificar, no preguntar, si existe respaldo fuera de esa región. Pregúntale a tu proveedor o a tu equipo interno dónde vive la copia, no si existe una copia. "Tenemos backups" no responde nada si el backup vive en la misma región que el original.
3. Probar la restauración, no sólo confirmar que el backup corrió. Un respaldo que nunca se restauró es una suposición, no una garantía. Programa un ejercicio de recuperación real, con tiempos medidos, al menos una vez al año.
4. Revisar el contrato de nivel de servicio de tu proveedor actual. Pregunta explícitamente qué cubre multi-AZ y qué no, y si el acuerdo contempla algún supuesto de pérdida regional. La mayoría no lo hace, y eso también es información.
5. Calcular el costo de la réplica contra el costo de la pérdida. No todos los sistemas justifican una segunda región. Los que manejan el dato que no se puede reconstruir, sí.

Esta auditoría es también el punto de partida de lo que cubre soporte, evolución y hosting: no es un proyecto de una sola vez, es una revisión que debería repetirse cada vez que un sistema crece o cambia de proveedor.

Dónde esto no aplica, y dónde la respuesta obvia es la equivocada

No todo sistema necesita una segunda región. Replicar entre regiones cuesta dinero y agrega complejidad operativa: más superficie para asegurar, más lugares donde algo puede desincronizarse, más piezas que mantener. Para un sistema interno de bajo impacto, con datos que se pueden reconstruir en horas desde otra fuente, forzar una arquitectura multi-región es gastar en un riesgo que no justifica el gasto.

La respuesta obvia que suele ser la equivocada es "cambiar de proveedor" o "mover todo a la región que parezca más segura hoy". El problema no es la región que se elija, es no tener nunca un plan B fuera de la que se elija. Y hay un matiz legal que complica la solución más simple: en sectores con obligaciones de residencia de datos, replicar fuera del país o de la región puede chocar contra la ley aplicable antes que contra la arquitectura técnica. Ahí el respaldo fuera de región hay que diseñarlo junto con el área legal, no sólo con TI, porque una copia cifrada en otro país no sirve de nada si la llave de descifrado también tiene que quedarse donde la ley exige que se quede.

Esto conecta con algo que ya hemos visto en otro ángulo: igual que sin MFA, EDR y respaldos inmutables ya no hay póliza de ciberseguridad que cubra un ataque, la pregunta de dónde vive físicamente tu respaldo va a empezar a aparecer en auditorías, pólizas y contratos con clientes, no sólo en conversaciones internas de TI. Y el costo de no tenerla resuelta no es sólo el de un dato perdido: también es el gasto que ya se desperdicia en la nube cuando nadie ha hecho el ejercicio de decidir qué vale la pena replicar y qué no.

Si tu empresa ya tiene un sistema corriendo en una sola región y nunca se ha probado qué pasa si esa región desaparece, ese diagnóstico y el plan para resolverlo es exactamente el tipo de trabajo que conviene hacer antes de necesitarlo, no después.

Fuentes

• Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE - Help Net Security
• Amazon Web Services unable to restore Bahrain data network knocked out by Iran - The National
• AWS Cannot Restore Data Held Only in Damaged Middle East Availability Zones - InfoQ
• AWS Cross-Region Data Transfer Cost, verificado septiembre 2026 - egresscost.com