CRN desglosa cinco hallazgos y conclusiones importantes de un nuevo informe de análisis de AWS, comenzando con la causa raíz del fracaso de Amazon y terminando con su costo potencial de 581 millones de dólares. “Haremos todo lo posible para aprender de este evento y utilizarlo para mejorar aún más nuestra disponibilidad”, afirma AWS.
La interrupción de Amazon, que afectó a miles de empresas y millones de personas, fue causada por dos sistemas automatizados que actualizaban los mismos datos al mismo tiempo, lo que provocó un problema de DNS (Sistema de nombres de dominio) que bloqueó la base de datos DynamoDB de AWS.
La empresa de análisis de riesgos cibernéticos CyberCube acaba de publicar una estimación preliminar de pérdidas de seguro por la falla de AWS, proyectando pérdidas de hasta 581 millones de dólares.
“Pedimos disculpas por el impacto que este incidente ha tenido en nuestros clientes”, dijo AWS en un informe post mortem sobre los resultados del accidente y la causa raíz.
(Relacionado: Interrupción de AWS de 15 horas: 5 grandes claves que debe conocer sobre IA, DNS, EC2 y centros de datos)
“Sabemos que este evento ha impactado significativamente a muchos clientes”, dijo AWS. “Haremos todo lo posible para aprender de este evento y utilizarlo para mejorar aún más nuestra accesibilidad”.
CRN desglosa los cinco aspectos más importantes sobre una interrupción de AWS que todo cliente, socio y usuario de Amazon debe saber.
#1: CyberCube estima $581 millones en pérdidas
CyberCube publicó una estimación preliminar de las pérdidas aseguradas por la falla de AWS, prediciendo un rango de $38 millones a $581 millones.
CyberCube, proveedor de análisis de riesgos de ciberseguridad, dijo que la violación afectó a más de 2.000 grandes organizaciones y alrededor de 70.000 organizaciones en general.
Se espera que AWS compense a las empresas afectadas por los costos del tiempo de inactividad, lo que podría limitar las pérdidas aseguradas y evitar demandas, según la firma de analistas de seguridad.
CyberCube señaló que es posible que muchos clientes no presenten reclamaciones, lo que es un factor que contribuye al pronóstico de pérdidas más bajo porque la interrupción duró menos de un día. La compañía espera que la interrupción tenga un impacto de bajo a moderado en las aseguradoras cibernéticas, y es probable que la mayoría de las pérdidas se produzcan en el extremo inferior del rango de CyberCube.
Lea las otras cuatro cosas principales que debe saber sobre la interrupción de AWS, incluida la causa raíz y los cambios que AWS planea realizar.
#2: La causa raíz del error que provocó que DynamoDB fallara
Aproximadamente a las 2:48 a. m. ET del 20 de octubre, un error crítico en el sistema de administración de DNS de DynamoDB se convirtió en una interrupción de aproximadamente 15 horas que finalmente interrumpió las operaciones de millones de personas.
La causa principal del fallo fue que dos sistemas automatizados estaban actualizando los mismos datos al mismo tiempo.
AWS informó que el problema era que dos aplicaciones competían por escribir el mismo registro DNS al mismo tiempo, lo que daba como resultado un registro DNS vacío para el punto final regional del servicio.
La tasa de error fue causada por una “falla oculta” en el sistema automatizado de administración de DNS, dijo Amazon, que controla cómo se enrutan las solicitudes de los usuarios a los servidores.
Esto resultó en la eliminación accidental de todas las direcciones IP para el punto final del servicio de base de datos regional.
El problema de DNS provocó que la base de datos DynamoDB de AWS fallara, lo que luego creó un efecto en cascada que afectó a muchos servicios de AWS, como EC2 y su equilibrador de carga de red.
#3: Investigar la causa raíz del DNS de DynamoDB
Amazon dijo que la falla fue causada por una condición de carrera en el sistema automatizado de administración de DNS de DynamoDB, que dejó un registro DNS vacío para el punto final regional del servicio.
El sistema de administración de DNS de Amazon consta de dos componentes separados: DNS Planner, que monitorea el estado del balanceador de carga y crea planes de DNS, y DNS Enactor, que aplica cambios a través de Amazon Route 53.
Según Amazon, la condición de carrera se produjo cuando un DNS Enactor experimentó “retrasos anormalmente altos” mientras el DNS Planner seguía generando nuevos planes.
Luego, el segundo DNS Enactor comenzó a aplicar los nuevos planes y realizó el proceso de limpieza justo cuando el primer Enactor completó su inicio retrasado.
Esta “limpieza” eliminó el plan anterior, que eliminó inmediatamente todas las direcciones IP para el punto final regional y dejó el sistema en un estado inconsistente, impidiendo que cualquier DNS Enacar aplicara más actualizaciones automáticas.
Antes de la intervención manual, los sistemas que se conectaban a DynamoDB experimentaban fallas de DNS, incluido el tráfico del cliente y los servicios internos de AWS, lo que afectaba el lanzamiento de la instancia EC2 y la configuración de la red, según Amazon.
Problema de equilibrio de carga de red
Después del problema de DNS, el administrador de red de AWS comenzó a distribuir una gran cantidad de configuraciones de red retrasadas, lo que provocó que las instancias EC2 recién lanzadas experimentaran retrasos en la configuración de red.
Estos retrasos en la red afectaron el servicio de equilibrio de carga de red (NLB) de AWS.
El subsistema de verificación de estado de NLB eliminó nuevas instancias EC2 que no pasaron la verificación de estado debido a retrasos en la red y luego las restauró después de verificaciones posteriores exitosas.
Los servicios dependientes de AWS, incluidos Lambda, Elastic Container Service (ECS) y Elastic Kubernetes Service (EKS), tuvieron problemas al iniciar instancias EC2.
“La causa principal de este problema fue una contención oculta en el sistema de administración de DNS de DynamoDB, que resultó en un registro DNS vacío incorrecto para el punto final regional del servicio (dynamodb.us-east-1.amazonaws.com), que la automatización no pudo solucionar”, dijo Amazon. “Todos los sistemas que necesitaban conectarse al servicio DynamoDB en la región (AWS North Virginia Datacenter, US-East-1) a través del punto final público inmediatamente comenzaron a experimentar fallas de DNS y no pudieron conectarse a DynamoDB. Esto incluyó el tráfico de clientes así como el tráfico de los servicios internos de AWS que dependen de DynamoDB”.
N.º 4: Amazon está realizando cambios para evitar este tipo de fallos
Amazon dijo que estaba realizando varios cambios en sus sistemas después de la interrupción, incluida la solución de un “escenario de condición de carrera” que provocó que dos sistemas automatizados sobrescribieran el trabajo del otro.
AWS ha deshabilitado globalmente DynamoDB DNS Planner y DNS Enactor hasta que se implementen medidas de seguridad para evitar que la carrera vuelva a ocurrir.
Amazon también dijo que creará un conjunto adicional de pruebas para ayudar a detectar errores similares en el futuro y mejorar los mecanismos de limitación.
“A medida que continuamos trabajando en los detalles de este evento en todos los servicios de AWS, buscaremos formas adicionales de evitar el impacto de un evento similar en el futuro y cómo reducir aún más los tiempos de recuperación”, dijo Amazon.
“Sabemos que este evento ha tenido un impacto significativo en muchos clientes”, dijo Amazon en un comunicado. “Haremos todo lo posible para aprender de este evento y utilizarlo para mejorar aún más nuestra accesibilidad”.
#5: El ex ejecutivo de AWS dice que era “inevitable”
El ex ejecutivo de AWS, Debanjan Saha, dijo a CRN que el fracaso de AWS era “inevitable”.
“Dada su enorme escala global y la complejidad de estos sistemas distribuidos, es realmente sorprendente que fallas a gran escala como ésta sean tan raras”, dijo Saha en un correo electrónico a CRN.
El fracaso de AWS era “inevitable en un horizonte bastante largo”, dijo, ya que tanto los proveedores de nube pública como los de nube privada fracasan con el tiempo.
“No es una cuestión de si, sino de cuándo”, añadió Saha.
Saha fue anteriormente vicepresidente y director general de la división de bases de datos de AWS de 2014 a 2019, antes de pasar a rivalizar con Google Cloud en 2019 como vicepresidente y director general de la división de análisis de datos de Google. Se convirtió en director ejecutivo de DataRobot en 2022.
“Todas las empresas que dependen de la infraestructura de la nube deben tener una estrategia de resiliencia clara”, afirmó Saha. “Esto significa pensar más allá de un solo centro de datos o región, pero idealmente más allá de un solo proveedor, creando un entorno multirregional y, cuando sea posible, multinube o híbrido”.
Amazon planea informar los resultados financieros trimestrales del tercer trimestre de 2025 el 30 de octubre.
