AWS Fault Injection Simulator
Servicio que inyecta fallos de forma segura como detención de EC2 y latencia de red mediante técnicas de ingeniería del caos para verificar la resiliencia del sistema
Descripción general
AWS Fault Injection Simulator (FIS) es un servicio totalmente gestionado para realizar experimentos de ingeniería del caos de forma segura en entornos AWS. Genera intencionalmente fallos que podrían ocurrir en producción, como detención de instancias EC2, inyección de latencia de red y simulación de fallos de AZ, para verificar la capacidad de recuperación del sistema. Se definen acciones, targets y condiciones de parada en plantillas de experimento, permitiendo reproducir fallos en un entorno controlado. Cuenta con mecanismos de seguridad que detienen automáticamente el experimento cuando produce impactos inesperados, mediante condiciones de parada vinculadas a alarmas de CloudWatch.
Diseño de plantillas de experimento y acciones
La plantilla de experimento de FIS agrupa en una sola definición el tipo de fallo a inyectar (acciones), los recursos objetivo (targets) y los dispositivos de seguridad (condiciones de parada). Las acciones incluyen detención/reinicio de instancias EC2, terminación forzada de tareas ECS, activación de failover de RDS, inyección de latencia de red y pérdida de paquetes, y simulación de throttling de API. Se pueden ejecutar múltiples acciones en paralelo o secuencialmente, construyendo escenarios de fallos compuestos como "primero detener el 30% de las instancias EC2 y 5 minutos después inyectar latencia de red". La duración de las acciones se especifica en segundos, y tras finalizar el experimento los recursos vuelven automáticamente a su estado original. Las plantillas de experimento se definen en JSON/YAML y se pueden gestionar como código con CloudFormation o Terraform. El versionado de plantillas garantiza la reproducibilidad de los experimentos, permitiendo re-ejecutar bajo las mismas condiciones que experimentos anteriores. La ejecución de experimentos requiere un rol IAM, asignando permisos mínimos necesarios por acción (ec2:StopInstances, ecs:StopTask, etc.).
Selección de targets y control de seguridad mediante condiciones de parada
La selección de targets es el punto de diseño más importante que determina la seguridad de FIS. Mediante filtrado basado en tags, se puede limitar la inyección de fallos a entornos específicos (env:staging), equipos (team:platform) o servicios (service:payment). Además, se puede especificar el porcentaje de recursos afectados (ej: 30% del total) o el número de recursos (ej: máximo 3) entre los seleccionados, controlando el radio de explosión (blast radius). Las condiciones de parada se vinculan con alarmas de CloudWatch, interrumpiendo inmediatamente el experimento cuando la tasa de errores supera un umbral o la latencia excede el rango aceptable. Se pueden configurar múltiples condiciones de parada, y si cualquiera de ellas se activa, todo el experimento se detiene. Para experimentos en producción, se recomienda un enfoque de expansión gradual del alcance. Primero se experimenta con una sola instancia EC2, y si no hay problemas, se amplía gradualmente al 10%, 30%, 50%. Los logs de ejecución de experimentos se registran en CloudTrail, dejando un rastro de auditoría de quién ejecutó qué experimento y cuándo.
Análisis de resultados y ciclo de mejora de resiliencia
Los resultados de experimentos FIS se utilizan para verificar hipótesis y derivar acciones de mejora. Antes del experimento se establece una hipótesis como "el Auto Scaling Group se recuperará de la detención del 30% de instancias EC2 en menos de 5 minutos", y después del experimento se verifica la hipótesis con métricas de CloudWatch (uso de CPU, tasa de éxito de solicitudes, latencia). Si la hipótesis se rechaza (ej: la recuperación tardó 15 minutos), se traducen en acciones de mejora concretas como revisar la configuración de cooldown del Auto Scaling o los intervalos de health check. Incorporando experimentos FIS en el pipeline CI/CD, se puede construir un mecanismo que verifica automáticamente la resiliencia con cada despliegue. Se coloca un experimento FIS como etapa en CodePipeline, avanzando al despliegue en producción solo si el experimento tiene éxito. El precio es de pago por uso basado en minutos de acción, a 0.10 USD por minuto de acción. Un experimento de 10 minutos con 3 acciones en paralelo costaría 30 minutos de acción x 0.10 USD = 3.00 USD. Cada vez más equipos institucionalizan experimentos regulares, realizando Game Days (días de entrenamiento de fallos) mensualmente.