La caída de AWS en Baréin: por qué multi-AZ sigue siendo un único dominio de fallo

A 16 de marzo, el registro público más sólido sobre los problemas de AWS en Oriente Medio era el propio canal de estado de AWS, no los relatos más ruidosos construidos encima.

Lo que AWS había confirmado públicamente para entonces ya bastaba. A principios de marzo, sus regiones de Oriente Medio sufrieron una interrupción prolongada que afectó tanto a me-south-1 en Baréin como a me-central-1 en Emiratos. AWS pidió a sus clientes que activaran los planes de recuperación ante desastres, restauraran desde copias remotas y trasladaran cargas de trabajo a otras regiones cuando hiciera falta. 1

Esa es la parte útil de la historia. Mucha cobertura de caídas deriva enseguida hacia una precisión inventada: número exacto de servicios, secuencia exacta de restauración, causa raíz exacta antes de que exista un análisis público. En la fecha de este artículo, la lección duradera era más simple. Una región sigue siendo una frontera de resiliencia compartida, aunque contenga varias zonas de disponibilidad.

Qué había confirmado AWS públicamente

Las propias actualizaciones de AWS describieron un problema inicial y localizado de suministro eléctrico en una zona de disponibilidad de Baréin el 1 de marzo, mes1-az2, que provocó problemas de conectividad, errores de API y degradación del servicio para los recursos de esa zona. El 2 de marzo AWS ya decía a sus clientes que la recuperación tardaría al menos un día y recomendaba lanzar recursos de reemplazo en zonas no afectadas o en otra región. 1

Lo de Emiratos fue otra clase de fallo. El 2 de marzo AWS informó de que dos zonas de disponibilidad de me-central-1 estaban seriamente dañadas y de que tanto la región de Emiratos como la de Baréin habían sufrido daños físicos relacionados con el conflicto en curso en Oriente Medio. En su aviso público señalaba que dos instalaciones de Emiratos habían sido alcanzadas directamente y que un impacto cerca de una instalación de Baréin también había causado daños en la infraestructura, corte de suministro y, en algunos casos, daños por los sistemas de extinción de incendios y por agua. 1

El 3 de marzo AWS anunció que pasaría a enviar avisos dirigidos a través del Personal Health Dashboard a los clientes afectados. Es decir: el registro público bastaba para establecer la forma del fallo, pero no para sostener un relato seguro sobre cada minuto y cada servicio. 1

Multi-AZ no es recuperación ante desastres

La propia página de infraestructura de AWS deja claro qué son una región y una zona de disponibilidad. Una región es una ubicación física que contiene varias zonas aisladas y físicamente separadas. Cada zona tiene su propio suministro eléctrico, refrigeración y seguridad física, y las aplicaciones repartidas entre zonas quedan mejor protegidas frente a los fallos habituales a escala de centro de datos. 2

Eso es resiliencia de verdad, pero no equivale a ser independiente de sucesos físicos o políticos que afectan a toda una región. Si el problema va más allá de instalaciones concretas —suministro eléctrico, seguridad, accesos, un conflicto—, un mismo suceso puede afectar a varias zonas a la vez. La caída regional de AWS de marzo recuerda que alta disponibilidad dentro de un proveedor no es lo mismo que recuperación ante desastres fuera de él.

El propio Well-Architected Framework de AWS hace la misma distinción. Para cargas de trabajo que exigen garantías de disponibilidad más fuertes, ahí es donde entra la arquitectura multirregión. Desplegar en varias zonas de disponibilidad mejora la resiliencia frente a muchos fallos de infraestructura dentro de una región. Protegerse de la pérdida de una región entera exige una estrategia de recuperación multirregión. 3

Tres cosas que reducen el fallo correlacionado

Tres decisiones de arquitectura reducen ese riesgo.

Geografía física distinta: otro país, en otra red eléctrica, al que llega otra fibra; no otra zona de disponibilidad en la misma ciudad.

Jurisdicción distinta, porque una caída deja de ser un problema de hardware muy deprisa.

Proveedor distinto, porque si tu entorno principal y tu respaldo llegan en la misma factura, comparten plano de control, organización de soporte y política de suspensión de cuentas.

La mayoría de los equipos entiende la primera y se queda ahí. A la tercera se resisten porque añade trabajo operativo. Y es justo la que te protege cuando el problema es mayor que las hipótesis de diseño regional de un solo fabricante.

Cuatro países, cuatro redes eléctricas

Somos una red distribuida, no un único campus grande. AVS ISP tiene sedes en Tirana, Skopie, Ámsterdam y Dublín: cuatro países, cuatro marcos regulatorios, cuatro entornos separados de suministro eléctrico y fibra.

En la práctica eso importa por una razón sencilla. Quien tiene un VPS de 5 €/mes en Ámsterdam y otro en Tirana consigue separación geográfica y jurisdiccional real por el precio de un menú para llevar. Para comprar independencia no hace falta un contrato corporativo de 50.000 €. Hacen falta dos sistemas que difícilmente vayan a fallar por lo mismo.

A quien gestiona su propio enrutamiento le ofrecemos AS210464 con validación RPKI y un juego completo de comunidades BGP, para que controles desde dónde se anuncian tus prefijos, incluido el anuncio selectivo por región y por tipo de peer, y el blackholing activado de forma remota cuando lo necesites. Las sesiones BGP empiezan en 5 €/mes.

Si quieres ver la red antes de confiar en ella, nuestro looking glass ejecuta ping, traceroute y consultas BGP en directo desde cada una de nuestras sedes. Sin registro y sin llamada comercial.

Nosotros tampoco somos inmunes

No vamos a decir que una red europea de cuatro sedes sea inmune a lo que le pasó a AWS en marzo. Ninguna lo es. El riesgo de concentración es un gradiente, no un interruptor, y compartimos proveedores de tránsito e interconexiones con todos los demás que operan en Europa.

Lo que sí diremos es que el seguro más barato del hosting sigue siendo el más antiguo: pon tu segunda carga de trabajo o tu copia de seguridad en un sitio que no pueda fallar por la misma razón que el primero. En la práctica sigue siendo una de las formas más simples de ganar resiliencia.

Si quieres probarlo con nosotros, levanta un VPS en un segundo país y mira lo que cuesta. Aceptamos criptomonedas, no pedimos KYC y puedes estar funcionando en minutos.

Fuentes

1. AWS Service Status RSS Feed, avisos de AWS sobre me-south-1 y me-central-1 del 1 al 3 de marzo de 2026
2. AWS Regions and Availability Zones, Amazon Web Services
3. AWS Well-Architected Framework – Disaster Recovery Strategy, Amazon Web Services