AWS detalla su reciente corte de red

La interrupción de AWS del 7 de diciembre interrumpió miles de sitios web, incluidos The Associated Press, Disney + y Netflix. El incidente, que duró varias horas, afectó la infraestructura del grupo en la región US-EAST-1 y resultó en la indisponibilidad de los servicios EC2, Connect, DynamoDB, Glue, Athena, Timestream, Chime, etc.proporcionados por Amazon para comprender mejor Qué pasó. En una publicación de blog, el grupo primero indica que depende de una red interna para alojar sus servicios "fundamentales", incluidos el monitoreo, el DNS interno, los servicios de autorización, así como partes de su plano de control EC2. "Dada la importancia de estos servicios en su red interna, AWS lo conecta a múltiples dispositivos geográficamente aislados y escala su capacidad para garantizar la disponibilidad de su conectividad", explica el grupo. Estos dispositivos proporcionan enrutamiento adicional y traducción de direcciones de red, lo que permite que los servicios de AWS se comuniquen entre la red interna y la principal.

A las 7:30 a.m. PST, AWS informa que una actividad automatizada para escalar la capacidad de uno de sus servicios alojados en su red principal provocó un comportamiento inesperado por parte de una gran cantidad de puntos finales en el interior de su red interna. "Esto resultó en un fuerte aumento en la actividad de conexión que abrumaba los equipos de red entre la red interna y la principal, provocando retrasos en la comunicación entre las dos", continúa la empresa. “Estos retrasos han aumentado la latencia y los errores de los servicios que se comunican entre estas redes, provocando aún más reintentos y reintentos de conexión. Esto ha provocado una congestión persistente y problemas de rendimiento en los equipos que conectan las dos redes ”.

La red interna congestionada

Después de este evento, la congestión de la red afectó la confiabilidad de los datos de monitoreo en tiempo real, dificultando el trabajo de los equipos de operaciones para identificar su origen. “En cambio, los operadores se basaron en los registros para averiguar qué estaba pasando e inicialmente identificaron altos errores de DNS internos. Dado que el DNS interno es fundamental para todos los servicios y se suponía que este tráfico contribuiría a la congestión, los equipos se centraron en mantener el tráfico de DNS interno alejado de las rutas de red congestionadas ”, dijo el proveedor. Una vez corregidos los errores de resolución de DNS a las 9:28 am, se mejoró la disponibilidad de varios servicios sin que se redujera por completo.

“Los operadores continuaron trabajando en un conjunto de medidas correctivas para reducir la congestión en la red interna, incluida la identificación de las principales fuentes de tráfico para aislar en dispositivos de red dedicados, deshabilitar algunos servicios intensivos en recursos y poner en línea capacidad de red adicional. Esto progresó lentamente por varias razones. Primero, el impacto en el control interno limitó nuestra capacidad para comprender el problema. En segundo lugar, nuestros sistemas de implementación internos, que operan dentro de nuestra red interna, se vieron afectados, lo que obstaculizó aún más nuestros esfuerzos de remediación. Por último, dado que muchos servicios en la red principal de AWS y las aplicaciones cliente todavía funcionaban con normalidad, queríamos ser extremadamente cuidadosos para evitar afectar las cargas de trabajo operativas ”, explica el proveedor. Tuvimos que esperar hasta las 13:34 para ver que el incidente se resolvió parcialmente y las 14:22 por completo.

Múltiples impactos en los servicios de AWS

Después de este incidente, varios servicios encontraron problemas con el plano de control utilizado para crear y administrar los recursos de AWS, estos se basan en servicios alojados en la red interna del proveedor. En particular, debido a una falla en la API: "Si bien la ejecución de las instancias EC2 no se vio afectada por este evento, las API de EC2 que los clientes usan para lanzar nuevas instancias o para describir sus instancias actuales han experimentado un aumento en las tasas de error y latencias desde las 7:33 a. M. PST ”, observa AWS. Del mismo modo, aunque los servicios de Elastic Load Balancers (ELB) existentes no se vieron afectados directamente, las tasas de error de API y las altas latencias para las API de ELB dieron como resultado un aumento en los tiempos de aprovisionamiento para los balanceadores más nuevos. VM adicionales.

“Además, las API de Route 53 se corrompieron desde las 7:30 am PST hasta las 2:30 pm PST, lo que impidió que los clientes hicieran cambios en sus entradas de DNS, aunque las existentes y las respuestas a las consultas de DNS no se vieron afectadas durante este evento. », Especifica AWS. El Servicio de token seguro (STS) también encontró altas latencias al enviar credenciales para proveedores de identidad de terceros a través de OpenID Connect (OIDC). “Esto ha provocado fallas de conexión para otros servicios de AWS que usan STS para la autenticación, como Redshift”, explica Amazon. La consola de administración de CloudWatch también se vio afectada y el acceso a los buckets de Amazon S3 y las tablas de DynamoDB a través de los puntos de enlace de la VPC se vio afectado. “Las API de Lambda y la invocación de funciones de Lambda funcionaron normalmente durante todo el evento. Sin embargo, API Gateway, que se utiliza a menudo para llamar a funciones de Lambda, así como un servicio de gestión de API para aplicaciones cliente, ha experimentado un aumento de las tasas de error. Los servidores de API Gateway se vieron afectados por su incapacidad para comunicarse con la red interna al comienzo de este evento ”, dijo el editor. "EventBridge, que también se usa a menudo junto con Lambda, encontró una gran cantidad de errores durante las etapas iniciales del evento, pero vio alguna mejora a las 9.28 am PST cuando se resolvió el problema del DNS interno".

Los servicios de contenedores de AWS, incluidos Fargate, ECS y EKS, experimentaron mayores tasas de error y latencias de API durante el evento. Si bien las instancias de contenedor existentes (tareas o pods) continuaron funcionando normalmente durante el evento, si una instancia de contenedor se detuvo o encontró una falla, no se pudo reiniciar debido al impacto en las API del plan de control EC2. Además, Amazon Connect también experimentó altas tasas de fallas en el manejo de llamadas telefónicas, sesiones de chat y contactos de tareas durante el evento. Los problemas con las puertas de enlace de la API que utiliza Connect para ejecutar las funciones de Lambda dieron como resultado altas tasas de fallas para las llamadas telefónicas entrantes, las sesiones de chat ...

Evitar que el problema vuelva a ocurrir

Para evitar que este evento se repita, AWS ha desactivado las actividades de escalado automatizado que desencadenaron este evento, pero planea reanudarlas cuando se hayan tomado todas las acciones correctivas. Estamos desarrollando una solución para este problema y planeamos implementar este cambio en las próximas dos semanas. También hemos lanzado una configuración de red adicional que protege los equipos de red potencialmente afectados en caso de que vuelva a ocurrir esta congestión ”, dice AWS. Medidas correctivas que deben darle al proveedor la seguridad de no ver recurrencia de este problema.