AWS en Medio Oriente: meses de reparaciones por ataques a data centers y su impacto en DevOps

Introducción

En febrero de 2026, el conflicto en Medio Oriente escaló con ataques entre EE.UU., Israel e Irán que derivaron en una serie de represalias con drones. Tres de los data centers de AWS en Emiratos Árabes Unidos (ME-CENTRAL-1) y Bahrein (ME-SOUTH-1) fueron alcanzados, generando daños estructurales, fallas en sistemas de enfriamiento y activación de sistemas antiincendio que inundaron racks de servidores. Las regiones afectadas no volvieron a operar con normalidad hasta, al menos, mayo de 2026, según el último reporte de AWS del 30 de abril de 2026.

El impacto no fue solo técnico. AWS suspendió la facturación automática para clientes en estas regiones —una medida que, según estimaciones internas citadas por Business Insider, representó un costo de $150 millones solo para marzo de 2026—. Además, la compañía recomendó explícitamente la migración inmediata de recursos a otras regiones cloud y el uso de backups remotos, una estrategia que no todos los equipos lograron implementar a tiempo.

Qué ocurrió

El 28 de febrero de 2026, tras un ataque inicial de EE.UU. e Israel contra Irán, el país persa respondió con una serie de ataques con drones contra infraestructura crítica en Medio Oriente. Tres data centers de AWS —dos en Emiratos Árabes Unidos (Dubai y Abu Dabi) y uno en Bahrein— fueron alcanzados, según documentos internos obtenidos por Business Insider.

Los daños reportados incluyen:

• 14 racks de servidores EC2 fuera de línea en uno de los data centers, afectando instancias de clientes que dependían de capacidades de cómputo escalable.
• Fallas en sistemas de enfriamiento, lo que provocó sobrecalentamiento y activación involuntaria del sistema antiincendio, generando inundaciones en los racks afectados.
• Daños mecánicos en la infraestructura física, con impactos en sistemas de energía redundante y redes de comunicación interna.

AWS confirmó en su status page del 30 de abril de 2026 que las regiones ME-CENTRAL-1 y ME-SOUTH-1 seguían sin poder soportar aplicaciones de clientes, y que la restauración completa tomaría varios meses más. Esto implica que, desde febrero hasta, al menos, julio de 2026, los equipos de DevOps y SRE en la región enfrentaron interrupciones prolongadas.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

El incidente expone la dependencia crítica de la redundancia geográfica en arquitecturas cloud. Equipos que no implementaron estrategias de multi-region o multi-cloud se vieron obligados a migrar cargas de trabajo en horas, como el caso de Careem, la superapp de Dubai, que logró recuperarse en menos de 24 horas tras migrar sus servicios a regiones de AWS fuera de Medio Oriente.

Sin embargo, no todos tuvieron la misma suerte. La falta de backups recientes o la incapacidad de escalar rápidamente a otras regiones generó:

• Tiempos de inactividad no planificados (según AWS, algunas instancias podrían no ser recuperables).
• Pérdidas económicas indirectas por falta de disponibilidad de servicios (ej.: empresas que dependían de EC2 para procesamiento de transacciones).
• Riesgo de corrupción de datos en sistemas que no contaban con réplicas sincronizadas.

Para equipos de Cloud e Infraestructura

AWS suspendió la facturación automática, pero esto no exime a los clientes de costos operativos adicionales:

• Migración de datos entre regiones implica transferencias de tráfico y posible aumento de latencia.
• Reconfiguración de balanceadores de carga (ALB/NLB) para redirigir tráfico a nuevas regiones.
• Actualización de políticas de IAM para restringir acceso solo a regiones operativas.

Además, la suspensión de facturación no aplica para servicios no afectados por la interrupción. Esto genera un escenario complejo donde algunos clientes pagan por recursos que no pueden usar, mientras otros enfrentan costos de migración no presupuestados.

Para equipos de Seguridad

El ataque abre preguntas sobre resiliencia en infraestructura cloud frente a conflictos geopolíticos. Aunque AWS no reveló detalles sobre posibles vulnerabilidades explotadas para el ataque, sí confirmó daños físicos en sistemas de seguridad:

• Fallas en sistemas antiincendio que activaron inundaciones, comprometiendo hardware.
• Pérdida de redundancia en energía, lo que podría haber dejado servidores sin protección contra cortes prolongados.

Equipos de seguridad deben revisar:

• Planes de continuidad operativa (BCP/DRP) para escenarios de interrupción prolongada.
• Estrategias de backup fuera de la región, incluyendo almacenamiento en cold storage o con proveedores alternativos (ej.: Azure, GCP).
• Auditorías de compliance (ISO 27001, SOC 2) para asegurar que los cambios post-incidente no violen regulaciones locales.

Detalles técnicos

Regiones y servicios afectados

• Sistemas de enfriamiento: Fallas en unidades CRAC (Computer Room Air Conditioning) llevaron a sobrecalentamiento y activación del sistema antiincendio, inundando racks con agua.
• Energía: Daños en UPS (Uninterruptible Power Supply) dejaron servidores sin respaldo en caso de cortes prolongados.

Comando de AWS para verificar regiones afectadas

aws ec2 describe-regions --region-names me-central-1 me-south-1 --query "Regions[].{Name:RegionName, Status:State}" --output table

Impacto en costos y facturación

AWS suspendió la facturación automática para marzo de 2026, pero:

• Clientes con contratos de soporte Enterprise aún recibieron facturas por servicios no afectados (ej.: regiones fuera de Medio Oriente).
• Migraciones entre regiones generaron costos adicionales por transferencia de datos (AWS cobra ~$0.02/GB para transferencias out entre regiones en la misma área, pero hasta $0.09/GB para regiones cruzadas).

Riesgo de datos corruptos

AWS no garantizó la recuperación de instancias en racks inundados. Equipos de DevOps deben asumir:

• Pérdida de datos en discos no replicados (EBS no replicado en otra zona de disponibilidad).
• Corrupción en snapshots si se generaron durante el evento (AWS recomienda validar integridad con herramientas como fsck o chkdisk en instancias Linux).

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Auditar recursos en regiones afectadas

# Listar instancias EC2 en regiones ME-CENTRAL-1 y ME-SOUTH-1
aws ec2 describe-instances --region me-central-1 --query "Reservations[].Instances[].{InstanceId:InstanceId, State:State.Name, LaunchTime:LaunchTime}" --output table
aws ec2 describe-instances --region me-south-1 --query "Reservations[].Instances[].{InstanceId:InstanceId, State:State.Name, LaunchTime:LaunchTime}" --output table

Paso 2: Migrar cargas de trabajo a regiones alternativas

AWS recomienda usar AWS Backup para restaurar recursos en otras regiones. Pasos clave:

1. Crear un plan de backup (si no existe):

   aws backup create-backup-plan --backup-plan file://backup-plan.json
   

Ejemplo de backup-plan.json:

   {
     "BackupPlan": {
       "BackupPlanName": "DR-ME-Region",
       "Rules": [
         {
           "RuleName": "Daily-35Days-Retention",
           "TargetBackupVault": "DR-Vault",
           "ScheduleExpression": "cron(0 5 ? * * *)",
           "Lifecycle": { "DeleteAfterDays": 35 }
         }
       ]
     }
   }
   

1. Restaurar desde backups en otra región:

   aws ec2 restore-instance --region eu-west-1 --snapshot-id snap-1234567890abcdef0
   

1. Redirigir tráfico con Route 53:

   aws route53 change-resource-record-sets --hosted-zone-id Z1234567890 --change-batch file://traffic-shift.json
   

Ejemplo de traffic-shift.json:

   {
     "Changes": [
       {
         "Action": "UPSERT",
         "ResourceRecordSet": {
           "Name": "api.example.com",
           "Type": "A",
           "TTL": 300,
           "AliasTarget": {
             "HostedZoneId": "Z2FDTNDATAQYW2",
             "DNSName": "dualstack.api-eu-west-1.elb.amazonaws.com",
             "EvaluateTargetHealth": true
           }
         }
       }
     ]
   }
   

Paso 3: Validar integridad de datos post-migración

# Verificar integridad de un filesystem ext4 en una instancia restaurada
ssh -i "dr-key.pem" ec2-user@<IP-NUEVA-INSTANCIA> "sudo fsck -f /dev/nvme0n1p1"

Paso 4: Revisar políticas de IAM y costos

1. Restringir acceso a regiones afectadas:

   aws iam put-role-policy --role-name ProductionRole --policy-name RestrictMERegions --policy-document file://policy.json
   

Ejemplo de policy.json:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "ec2:*",
         "Resource": "*",
         "Condition": { "StringEquals": { "aws:RequestedRegion": ["me-central-1", "me-south-1"] } }
       }
     ]
   }
   

1. Estimar costos de migración:

– Activar Cost Explorer para monitorear gastos no planificados.

Paso 5: Actualizar documentación y runbooks

• Documentar la migración en el runbook de incidentes.
• Capacitar al equipo en:

– Configuración de Auto Scaling Groups en la nueva región.

– Pruebas de failover con Chaos Engineering (ej.: herramientas como Gremlin).

Conclusión

El ataque a data centers de AWS en Medio Oriente en febrero de 2026 dejó en evidencia tres lecciones clave para equipos de DevOps, Infraestructura y Cloud:

1. La redundancia geográfica no es opcional: Arquitecturas single-region son un riesgo inaceptable para negocios críticos. Equipos deben implementar multi-region con replicación sincronizada y backups automáticos.
2. Los planes de recuperación deben probarse: Careem migró en horas porque ya tenía un plan de DR probado. Si no lo tienes, ahora es el momento de implementarlo.
3. La seguridad física afecta la cloud: Daños en sistemas antiincendio y enfriamiento demostraron que la resiliencia no depende solo de software. Auditorías periódicas de infraestructura física son tan críticas como las de configuración.

AWS aún no ha detallado los costos totales de la reparación, pero el impacto en clientes —desde pérdidas por inactividad hasta migraciones forzadas— superó los $200 millones solo en costos operativos directos. Para equipos técnicos, el mensaje es claro: la nube no es mágica, y los conflictos geopolíticos sí pueden llegar a tu data center.

Fuentes

• Ars Technica: Amazon stuck with months of repairs after drone strikes on data centers
• Business Insider: Internal AWS documents reveal scale of damage from drone strikes
• AWS Status Page – April 30, 2026
• AWS Pricing Calculator
• AWS Backup Documentation
• Gremlin Chaos Engineering