El incidente describe un patrón común de falla en sistemas distribuidos: una interrupción parcial o 'gris' en una zona de disponibilidad que, en lugar de ser contenida, se propaga y escala a una interrupción regional. La causa raíz es la interacción entre los mecanismos de detección de fallas (health checks) y los mecanismos de recuperación automática (Auto Scaling) que, si bien son lógicos en aislamiento, fallan catastróficamente bajo condiciones de deterioro zonal. Cuando una AZ se vuelve lenta o pierde paquetes, las instancias en esa AZ fallan los health checks. El sistema reacciona terminando estas instancias y tratando de reemplazarlas en la misma AZ deteriorada, lo que lleva a un ciclo de terminación-falla de lanzamiento y un back-off prolongado.
Las salvaguardas existentes fallaron porque estaban diseñadas para fallas 'limpias' (instancias completamente muertas) y no para el estado 'gris' de una AZ. La suposición de que una instancia que falla un health check está inherentemente 'rota' y debe ser reemplazada es incorrecta en un escenario de partición de red zonal. Esto llevó a la destrucción de capacidad funcional (instancias con caches calientes) y a la imposibilidad de recuperar el servicio durante un período prolongado, incluso después de que la causa raíz de la red se resolviera. La dependencia de que la AZ afectada pueda realizar acciones correctivas (como lanzar nuevas instancias) también contribuyó al problema.
La lección clave es la importancia de la 'estabilidad estática': durante un deterioro zonal, el sistema debe dejar de reaccionar, preservar la capacidad existente, redirigir el tráfico fuera de la zona afectada y esperar. La acción correctiva debe ser tomada por las zonas saludables, no por la zona deteriorada, ya que esta última es inherentemente poco confiable. Además, se identificaron dependencias inter-zonales ocultas (como etcd) que podían propagar el impacto de una falla zonal a zonas saludables, ampliando el 'blast radius' más allá de la ubicación física de la falla.