El incidente inicial de Athenahealth fue causado por la falta de una estrategia de Disaster Recovery (DR) multi-Region para su despliegue de Terraform Enterprise (TFE), que era de una sola región. Un evento de servicio regional de AWS en us-east-1 hizo que TFE fuera inaccesible, impidiendo a los equipos de ingeniería desplegar o modificar infraestructura crítica. La arquitectura inicial carecía de replicación de base de datos cross-Region, capacidad de cómputo secundaria, backups de archivos de estado de Terraform fuera de us-east-1 y DNS apuntando exclusivamente a la región primaria.
La implementación de una estrategia de DR multi-Region activa-pasiva abordó estas deficiencias. Sin embargo, la validación con AWS Fault Injection Service (AWS FIS) reveló fallos ocultos y dependencias críticas. El más significativo fue una dependencia circular en los scripts de failover: intentaban leer identificadores de infraestructura de archivos de estado de S3 almacenados en la región primaria. Durante un evento que afectara a la región primaria, estos archivos serían inaccesibles, bloqueando el propio proceso de recuperación. Esta salvaguarda falló porque la automatización de la recuperación dependía de la disponibilidad del sistema que se estaba intentando recuperar.
Otros problemas descubiertos incluyeron una Amazon Machine Image (AMI) desactualizada en la plantilla de lanzamiento del Auto Scaling Group de la región de DR, lo que habría impedido el lanzamiento de nuevas instancias. También se identificó que la configuración del connection pooling de TFE causaba retrasos extendidos en la reconexión después de un failover de base de datos. Estos problemas, aunque no fueron la causa raíz del incidente inicial, habrían comprometido gravemente el Recovery Time Objective (RTO) y el Recovery Point Objective (RPO) de la nueva arquitectura de DR si no se hubieran descubierto y corregido mediante la inyección de fallos controlada.