Ingeniería de Caos y el servicio AWS FIS
La Ingeniería del Caos es ahora una disciplina esencial para garantizar la fiabilidad y la resiliencia de los sistemas modernos.
Consiste en provocar fallos deliberadamente dentro de un entorno de producción o pre-producción, de manera controlada, reproducible y segura, para observar cómo reacciona el sistema.
El objetivo de este enfoque es identificar brechas de resiliencia que no son detectadas por los métodos de prueba tradicionales (como las pruebas unitarias, de integración o de carga) y mejorar la capacidad del sistema para mantener un servicio continuo ante interrupciones que sean lo más realistas posible
A diferencia de las pruebas tradicionales, que buscan verificar que la aplicación se comporte como se espera bajo condiciones normales o ante errores previstos, la Ingeniería del Caos se centra en evaluar la robustez del sistema ante situaciones imprevistas:
- Cortes de red
- Latencias anormales
- Pérdida de recursos
- Comportamiento degradado de dependencias externas
- Y más
Este enfoque proactivo permite comprender mejor los límites de un sistema y mejorar su tolerancia a fallos antes de que ocurra un incidente real
Integración con AWS Fault Injection Simulator (FIS)
En AWS, la práctica de la Ingeniería del Caos se ve facilitada por el servicio AWS Fault Injection Simulator (FIS).
Este servicio gestionado permite la ejecución de experimentos de caos de manera segura, controlada y reproducible directamente en entornos de AWS
FIS ofrece un marco de trabajo estructurado para simular diferentes tipos de fallos, tales como:
- Detención o degradación de instancias EC2
- Interrupción del tráfico de red (pérdida de una Zona de Disponibilidad (AZ) o Región)
- Variación de la latencia en las llamadas a APIs
- Reducción de la capacidad de un clúster de ECS o EKS
Una de las principales ventajas de AWS FIS es su integración nativa con el ecosistema de AWS.
Permite definir escenarios de experimentación específicos, medir sus impactos a través de CloudWatch y AWS X-Ray, y automatizar su ejecución mediante canalizaciones de CI/CD o flujos de trabajo orquestados (como Step Functions y EventBridge).
Este enfoque permite la introducción progresiva de pruebas de resiliencia en el ciclo de vida de la aplicación, garantizando al mismo tiempo la seguridad del entorno mediante mecanismos de salvaguarda integrados (como condiciones de parada y permisos de IAM limitados)
Al combinar el rigor de la Ingeniería del Caos con las capacidades nativas de observación y automatización de AWS, FIS constituye una herramienta estratégica para fortalecer la robustez de la arquitectura en la nube y validar su comportamiento ante fallos reales.
Mejores Prácticas y Salvaguardas
La experimentación del caos solo tiene sentido si se lleva a cabo de manera controlada y medible, sin poner en riesgo a los usuarios finales ni a la infraestructura probada. Aunque el objetivo es provocar fallos, el enfoque debe, ante todo, reforzar la confianza en la resiliencia del sistema, en lugar de crear nuevas fuentes de inestabilidad.
Aquí tienes la traducción para encabezar esta sección de principios:
Aquí se presentan algunos principios fundamentales, esenciales para implementar AWS Fault Injection Simulator (FIS) de manera segura y eficaz.
1. Definir objetivos claros y medibles
Antes de lanzar un experimento de Caos, es esencial definir qué es lo que se desea aprender o validar.
Cada prueba debe responder a una hipótesis precisa, tal como:
«Si una zona de disponibilidad deja de estar disponible, nuestro servicio debe seguir siendo accesible con una latencia inferior a 500 ms».
Este enfoque hipotético-deductivo proporciona un marco científico para la experimentación, evitando el ‘probar por probar
Las métricas de validación (como la latencia, la tasa de errores, la disponibilidad y el rendimiento) deben ser medibles a través de herramientas que permitan la validación de las pruebas, tales como CloudWatch, Prometheus o Datadog
2. Empezar con algo pequeño y avanzar mediante iteraciones
La Ingeniería del Caos se basa en una progresión controlada, trabajando a través de iteraciones sucesivas
Se recomienda comenzar en un entorno de pre-producción y con un alcance limitado
- Una sola instancia EC2
- Un clúster de ECS restringido
- Un servicio específico en una arquitectura de microservicios
Con el tiempo, los experimentos pueden extenderse a toda la infraestructura y hacia el entorno de producción, pero solo una vez que las salvaguardas hayan sido validadas
Este escalado progresivo limita los riesgos mientras fortalece la confianza del equipo en los mecanismos de resiliencia. También permite corregir problemas de comportamiento, si los hubiera, a medida que se avanza
3. Implementar Condiciones de Parada
AWS FIS permite la configuración de condiciones de parada automáticas basadas en alarmas de CloudWatch
Estas salvaguardas son esenciales para interrumpir inmediatamente el experimento si se superan los umbrales críticos (por ejemplo: latencia, errores HTTP 5xx, CPU o saturación de las colas SQS)
De este modo, incluso en caso de una desviación inesperada, el experimento permanece bajo control y no compromete la disponibilidad real del servicio
4. Asegurar los permisos de IAM
Los experimentos de FIS deben ejecutarse bajo el principio de mínimo privilegio.
ree un rol de IAM dedicado, autorizando únicamente:
- Lectura e inyección de fallos en los recursos seleccionados
- Creación y eliminación controlada de experimentos
- Acceso de lectura a las métricas de CloudWatch
Esto resulta obvio, pero como todas las cosas obvias, es preferible enunciarlas:
No utilice roles genéricos o de administrador. Esto reduce los riesgos de activaciones accidentales o errores de configuración.
5. Comunicar y documentar
La Ingeniería del Caos debe ser una práctica de equipo, no una iniciativa aislada
Antes de cada experimento:
- Planificar los ejercicios e informar a los equipos implicados (operaciones, soporte, desarrollo).
- Documentar el plan de experimentación (objetivos, alcance, condiciones de éxito, salvaguardas).
- Preparar un plan de retroceso claro.
Después del experimento, organice un post-mortem para analizar los resultados, identificar debilidades y decidir las acciones correctivas. Este ciclo de aprendizaje continuo es la clave para la resiliencia organizacional.
6. Automatizar e Integrar en CI/CD
Para maximizar el valor de la Ingeniería de Caos, integra de forma progresiva FIS en tus flujos de CI/CD o en tus pruebas de resiliencia automatizadas.
Por ejemplo:
- Define semanas de pruebas de recuperación ante desastres para comenzar.
- Idealmente, activa un experimento de FIS con cada despliegue principal para verificar que los mecanismos de conmutación por error o de autoescalado sigan funcionando según lo previsto
Esta integración continua transforma la Ingeniería de Caos en un proceso de validación proactivo, en lugar de un ejercicio puntual.
7. Aprender de incidentes reales
Finalmente, cada incidente en producción constituye una oportunidad para realizar experimentación dirigida.
Una vez resuelto el incidente, recrea condiciones similares mediante FIS para validar que las correcciones implementadas eviten su recurrencia.
Así es como la Ingeniería de Caos se convierte en una verdadera herramienta de mejora continua, anclada en la realidad operativa.
Puntos clave
El uso de AWS FIS y de la Ingeniería de Caos no se realiza sin una base y sin una visión global de lo que se intenta validar.
Es necesario gestionar:
- Expectativas: Qué estamos intentando probar.
- Seguridad: No hacemos cualquier cosa; controlamos lo que debe ser controlado.
- Empezar poco a poco: Comenzar con algo pequeño e iterar hasta cubrir el máximo alcance funcional y de la aplicación.
- Aprender de los errores: Aprender de nuestros fallos e interrupciones del servicio.
Implementar AWS FIS no se trata simplemente de ‘romper cosas para ver qué pasa’, sino de probar para comprender y fortalecer. Con objetivos precisos, salvaguardas sólidas y una cultura de colaboración, este enfoque transforma el Caos en una palanca para la confiabilidad sostenible de la infraestructura.
Precios de AWS FIS
AWS Fault Injection Simulator se factura en función del número de acciones de inyección de errores ejecutadas (Fault Injection Actions) durante tus experimentos.
El modelo de precios es sencillo y no depende de la duración del experimento ni del tipo de recurso objetivo (por ejemplo, EC2, RDS, ECS).
| Tipo de coste | Detalle | Price (per action) |
| Coste base | Cada acción de inyección de errores (iniciada), ya sea que termine con éxito o falle | $0.10 USD (por acción) |
| Costes adicionales | Recursos de AWS consumidos durante el experimento (EC2, CloudWatch, etc.) | Estándar (según los servicios utilizados) |
Cálculo de las acciones de inyección de errores
Una acción de inyección de errores corresponde a una acción especificada en la plantilla del experimento de FIS que afecta directamente a un recurso.
Ejemplo 1: Terminación de instancias EC2
Si tu plantilla contiene una acción aws:ec2:terminate-instances dirigida a un grupo de 5 instancias (con COUNT(1) en la selección del objetivo), el experimento ejecuta 1 sola acción de inyección de errores, aunque afecte a un recurso específico.
Coste de FIS: $0.10 USD
Ejemplo 2: Acciones múltiples
Si tu plantilla ejecuta dos acciones distintas de forma simultánea:
- aws:ec2:reboot-instances (EC2 reboot)
- aws:rds:reboot-db-instances (RDS instance reboot)
El experimento contabiliza 2 acciones de inyección de errores
Coste de FIS: 2 x $0.10 = $0.20 USD
Ejemplo 3: Acciones secuenciales o repetidas
Si defines un experimento con tres pasos secuenciales, cada uno con una única acción de inyección de errores (por ejemplo: latencia → pérdida de zona de disponibilidad → parada de EC2), esto cuenta como 3 acciones.
Coste de FIS: 3 x $0.10 = $0.30 USD
Resumen de Precios
El modelo de precios de AWS FIS es predecible: solo pagas por cada tipo de inyección de errores que configures y ejecutes en tus experimentos.
| Escenario del experimento | Número de acciones | Coste FIS |
| Detener una instancia EC2 | 1 | $0.10 |
| Detener el 50% de un clúster de ECS | 1 | $0.10 |
| Inyección de latencia en un grupo + Parada de una instancia RDS (2 acciones) | 2 | $0.20 |
| 10 ejecuciones del experimento simple de parada de EC2 (para pruebas) | 10 | $1.00 |
Nota importante: Este precio solo cubre el uso del servicio FIS en sí mismo. Sigues siendo responsable de los costes relacionados con los recursos de AWS (EC2, CloudWatch, etc.) consumidos o reiniciados durante y después del experimento.
AWS Fault Injection Service: Explicación mediante ejemplos
Tomemos el caso sencillo de una infraestructura de tres capas muy conocida:
Objetivo
Simular la pérdida de una instancia web (EC2) en un Grupo de Auto Scaling para validar:
- El comportamiento del ALB (conmutación por error hacia instancias saludables)
- La capacidad del ASG para restaurar la capacidad deseada
- La ausencia de un impacto crítico en la base de datos RDS
- La coherencia con los requisitos de recuperación ante desastres (RTO / RPO esperados)
Arquitectura objetivo
ALB (público) → Target Group → ASG → EC2 (etiqueta Service=web, Environment=staging)
RDS (instancia única / Multi-AZ según tu infraestructura)
Prerrequisitos
Un stack desplegado (ALB, Target Group, ASG, instancias con etiquetas).
Este repositorio de Git contiene lo necesario para desplegar la infraestructura base.
Contiene un ejemplo sencillo de infraestructura en Terraform que provisiona:
- Una VPC con dos subredes públicas (eu-west-1a / eu-west-1b)
- Un Application Load Balancer (ALB) + Target Group
- Un grupo de Auto Scaling con un Launch Template (instancias web)
- Una instancia de RDS (MySQL o Postgres, según el archivo main.tf)
- Alarmas de CloudWatch utilizadas como condiciones de parada (stop conditions) para un experimento de FIS
- Una plantilla de AWS FIS para terminar una instancia del grupo de Auto Scaling
Archivos principales:
- main.tf: Recursos de red, ALB, ASG, RDS y plantilla de lanzamiento
- data.tf: Origen de datos para la AMI.
- cloudwatch.tf: Alarmas de CloudWatch (condiciones de parada o stop conditions).
- fis.tf: Rol de IAM para FIS y la plantilla del experimento aws_fis_experiment_template
- local.tf: Variable de prefijo local.
Aquí tienes la traducción al español para esta advertencia de seguridad y arquitectura:
Esta infraestructura es mínima y pública para fines de prueba. No está optimizada para producción (RDS multi-AZ, copias de seguridad, subredes privadas…).
Despliegue
terraform init (Inicialización)
terraform plan (Planificación)
terraform apply (Aplicación)Después de solicitarlo, tendrás:
- Un ALB público con un grupo de destino (target group) → ASG EC2
- Un ASG con 2 instancias web
- Un RDS MySQL/Postgres listo para recibir conexiones
Esta infraestructura está lista para ser utilizada como objetivo (target) de FIS (detención/terminación de instancias, pruebas de resiliencia).
CloudWatch recolecta estas métricas y contiene al menos 3 alarmas listas:
- <CLOUDWATCH_ALARM_ARN_HTTP_5XX> (ALB 5xx)
- <CLOUDWATCH_ALARM_ARN_HIGH_LATENCY> (ALB latency)
- <CLOUDWATCH_ALARM_ARN_DB_CONNECTIONS_CRITICAL> (RDS connections)
Un rol de IAM dedicado para FIS, creado bajo el principio de privilegio mínimo.
Autorizar a los SRE/DevOps involucrados e informar al equipo de soporte/operaciones antes de cualquier ejecución.
Implementación de la Solución
AWS proporciona plantillas
Condiciones de parada (Salvaguardas)
Antes de la ejecución, verifique que las siguientes alarmas existan y estén referenciadas en la plantilla:
- ALB_HTTP_5XX_Alarm: detener si la Suma(HTTPCode_Target_5XX_Count) > 10 durante 1 minuto.
- ALB_Latency_Alarm: detener si el Promedio(TargetResponseTime) > 1.5 s durante 2 minutos.
- RDS_Connections_Critical: detener si DatabaseConnections > umbral crítico.
Ejecución (Runbook Simplificado)
Antes: Anunciar la ventana de experimentación a todos los equipos (Slack/correo electrónico) y abrir un canal de emergencia.
Lanzamiento: aws fis start-experiment –experiment-template-id <ID> o a través de la consola de FIS.
Monitoreo (t = 0 → t + 15 min): Panel de CloudWatch que contiene ALB, ASG, EC2 y RDS. Verificar HealthyHostCount, HTTPCode_Target_5XX_Count, TargetResponseTime, GroupInServiceInstances y DatabaseConnections. → Captura de pantalla: Panel de CloudWatch durante el experimento.
Parada automática: Si se activa una condición de parada, FIS detiene el experimento. Revisar los registros y eventos de FIS.
Después: Post-mortem inmediato — recolectar métricas, logs de la aplicación, trazas de X-Ray y registrar las decisiones y puntos de acción.
Criterios de éxito (Ejemplos)
- HTTPCode_Target_5XX_Count se mantiene < 10 durante y hasta 5 minutos después del experimento.
- Mediana de TargetResponseTime < 500 ms (tolerancias del negocio).
- El ASG restaura las InServiceInstances = DesiredCapacity en menos de 10 minutos.
- RDS: sin desconexiones críticas de la aplicación (o reconexión aceptada).
Notas y Extensiones Educativas
Alternativa: Probar la detención (stop, permite reinicio) en lugar de la terminación (terminate) si se desea simular un apagado transitorio.
Inyección de latencia: Si se desea simular una degradación de red, utilizar SSM + tc/netem mediante un aws:ssm:send-command (asegurar que el agente SSM y los permisos existan).
Escalado progresivo: Ejecutar primero en el entorno de pruebas (staging) y luego, tras la validación, planificar un experimento en producción durante una ventana de bajo tráfico (con salvaguardas adicionales).
Bibliografía
- Documentación de AWS FIS: Documentación de AWS FIS
- Tutorial de AWS FIS: Tutoriales de AWS FIS
- Guía de usuario de AWS Fault Injection Simulator: Guía de usuario de FIS
- Lista de servicios de AWS explotables por FIS: Objetivos (Targets) de FIS
- Referencia de la API de AWS Fault Injection Simulator: Referencia de la API de FIS
- Referencia de comandos de AWS CLI para FIS: Referencia de la CLI de AWS para FIS