AWS Fault Injection Service: guía práctica para probar resiliencia

AWS Fault Injection Service (AWS FIS), antes llamado AWS Fault Injection Simulator, permite probar cómo responde una carga de trabajo cuando falla un componente. Para una primera práctica, puedes detener una única instancia EC2 de prueba y pedirle a FIS que intente iniciarla de nuevo después de dos minutos. La acción ocurre sobre un recurso real: limita el objetivo, prepara una alarma de CloudWatch y verifica la recuperación antes de ejecutar.

Esta guía explica qué configurar, qué observar y qué revisar si el experimento se detiene o no logra recuperar la instancia. No necesitas una pantalla general de “activar FIS”: el flujo documentado empieza con los permisos de IAM y una plantilla de experimento.

Qué hace AWS FIS y qué no garantiza

AWS FIS ejecuta acciones de inyección de fallos sobre recursos de AWS. Una plantilla define las acciones, los objetivos, las condiciones de parada y el rol que FIS asume para realizar el experimento. Puedes trabajar desde la consola, la CLI, CloudFormation, los SDK o la API HTTPS. El manual oficial de AWS FIS describe el servicio y sus límites.

Para ver una charla de comunidad sobre observabilidad e ingeniería del caos, consulta la grabación Cloud Forge: observabilidad, ingeniería del caos y Java en AWS, organizada por AWS User Group Medellín.

Estas acciones no son una simulación aislada del recurso: FIS realiza cambios reales, como detener instancias o introducir errores en solicitudes. Una condición de parada ayuda a limitar el experimento, pero no vuelve inocua la acción ni garantiza que la aplicación se recupere. AWS recomienda planificar la prueba y empezar en un entorno de prueba o preproducción, con métricas y alertas listas. Consulta la guía de planificación de experimentos de FIS.

Antes de ejecutar: delimita el recurso, la alarma y los permisos

• Elige un entorno de prueba. Identifica una sola instancia EC2 reemplazable que no atienda producción ni almacene datos que necesites conservar. Para detenerla, debe estar en estado running y tener un dispositivo raíz respaldado por EBS: una instancia con raíz de instance store no se puede detener y volver a iniciar. Si tiene volúmenes instance store, sus datos locales se pierden al detenerla e iniciarla. Confirma también que no esté habilitada la protección contra la detención; esa protección bloquea la llamada a EC2 que FIS debe ejecutar. Consulta las guías de AWS sobre detener e iniciar instancias y protección contra la detención.
• Define qué esperas comprobar. Anota el comportamiento normal y las métricas que lo representan: disponibilidad, errores, latencia o tiempo hasta que la aplicación vuelve a estar lista. Formula una hipótesis con límites acordados para ese servicio; no uses porcentajes de ejemplo como objetivos universales.
• Prepara y prueba la alarma. Usa una alarma de CloudWatch asociada al impacto que quieres limitar, por ejemplo una comprobación de salud de la aplicación. Debe estar enviando datos y en estado normal antes del experimento. Una alarma genérica o sin datos puede no detectar el problema que te importa.
• Usa un rol de experimento separado. La guía de roles IAM para AWS FIS requiere un rol que el servicio pueda asumir y recomienda conceder privilegio mínimo. Limita la relación de confianza al servicio fis.amazonaws.com y sigue la recomendación de restringirla con aws:SourceAccount y aws:SourceArn.

Para la acción de detener y volver a iniciar una EC2, el rol de experimento necesita los permisos de EC2 correspondientes —entre ellos ec2:StopInstances y ec2:StartInstances— sobre el alcance elegido. Si el volumen EBS está cifrado, también puede necesitar kms:CreateGrant y autorización en la clave para permitir el inicio posterior. Revisa los permisos exactos de aws:ec2:stop-instances antes de guardar la plantilla.

El rol de experimento no es el rol de la persona que usa la consola. Quien crea la plantilla debe poder pasar ese rol; quien inicia el primer experimento también puede necesitar permiso para crear el rol vinculado al servicio de FIS. AWS crea AWSServiceRoleForFIS para tareas como la selección de recursos y la supervisión. Revisa cómo usa FIS los roles vinculados al servicio y evita conceder permisos de administrador por comodidad.

Cuánto cuesta una ejecución

Al 6 de octubre de 2026, la página de precios de AWS FIS indica una tarifa de USD 0,10 por minuto de acción en la mayoría de las regiones, más USD 0,10 por minuto de acción por cada cuenta objetivo adicional. En AWS GovCloud (US-East y US-West), la tarifa es USD 0,12 por minuto de acción, más USD 0,12 por minuto por cada cuenta objetivo adicional. FIS calcula el cargo según cuánto tiempo permanece activa cada acción y redondea ese tiempo al minuto más cercano; no depende de cuántos recursos alcance una acción.

La tarifa de FIS no incluye los cargos que puedan corresponder a los recursos objetivo ni a la telemetría. Revisa también los precios de Amazon EC2 y Amazon CloudWatch. No des por hecho que una prueba es gratuita: el costo depende de la región, las acciones, su duración y los servicios usados para medir el resultado.

Práctica: detener y volver a iniciar una sola EC2 de prueba

El objetivo de este ejercicio es observar la interrupción y comprobar que la instancia y la aplicación regresan a un estado saludable. No prueba por sí solo la alta disponibilidad de una arquitectura. Si detener esa instancia afectaría a usuarios o datos que no puedes perder, no la uses como objetivo.

1. Escribe la hipótesis. Por ejemplo: “Al detener la instancia de prueba, la alarma detectará el impacto y la aplicación volverá a responder dentro del tiempo objetivo de recuperación (RTO) definido para este entorno”. El RTO y el umbral de la alarma deben corresponder a tu propio servicio; AWS no les asigna un valor universal.
2. Crea una plantilla en la región de la instancia. En la consola de AWS FIS, crea una plantilla con una acción y un objetivo. Para el objetivo, selecciona el tipo aws:ec2:instance, el ID de esa única instancia y el modo de selección ALL. Evita filtros amplios que puedan resolver más recursos de los previstos; consulta cómo se definen los objetivos de AWS FIS.
3. Configura la acción. Elige aws:ec2:stop-instances y establece startInstancesAfterDuration en PT2M. Ese valor solicita a FIS iniciar la instancia después de dos minutos; el parámetro admite de uno a 720 minutos. Confirma los requisitos adicionales de cifrado y permisos en la referencia de la acción.
4. Agrega la condición de parada. Selecciona la alarma de CloudWatch que representa el límite de impacto acordado. Si esa alarma pasa a estado de alarma durante el experimento, FIS detiene la ejecución. No uses una condición “ninguna” para este primer ensayo.
5. Revisa el objetivo antes de inyectar el fallo. Genera una vista previa de objetivos con el modo skip-all y comprueba que aparezca exactamente el ID previsto. La vista previa omite las acciones; no verifica que FIS tenga permiso para ejecutarlas.
6. Inicia y observa. Arranca el experimento desde la consola solo cuando el equipo responsable esté listo para intervenir. Sigue el estado de la acción y del experimento en FIS; observa la alarma, la comprobación de salud y los errores o la latencia de la aplicación.

Si quieres ampliar la parte de arquitectura, la charla Diseñando arquitecturas resilientes en AWS, del AWS User Group Ecuador, ofrece otro punto de partida para pensar qué comportamiento poner a prueba.

La vista previa y la plantilla se describen en la documentación de opciones de experimentos de AWS FIS. La guía de componentes de una plantilla explica cómo se relacionan acciones, objetivos, alarmas y roles.

Qué observar, cómo detener y cómo confirmar la recuperación

Compara el periodo anterior, el experimento y la recuperación. Registra el estado de la instancia, los cambios en la alarma, la disponibilidad o errores de la aplicación y el tiempo hasta que vuelve a responder. La guía interna de Mejores prácticas de observabilidad en AWS amplía cómo combinar métricas, logs y trazas.

Si la condición de CloudWatch se activa, FIS detiene el experimento. También puedes detenerlo manualmente desde la consola. Un experimento detenido no se puede reanudar. Al detenerlo, FIS completa las acciones posteriores pendientes que la acción tenga configuradas; en este caso, startInstancesAfterDuration permite solicitar el inicio de la instancia. Espera a que termine la acción y confirma en EC2 que la instancia está en estado running; después verifica la salud de la aplicación. Si falla el inicio o la aplicación no se recupera, sigue el procedimiento operativo de tu equipo. La condición de parada no es una reparación general ni revierte efectos de acciones que no admiten recuperación.

Para pensar más allá de esta instancia, lee Pruebas de resiliencia recomendadas en AWS Resilience Hub: un runbook que nunca se ejecutó es una hipótesis, un artículo de AWS Builder Center sobre validar runbooks con pruebas.

Al terminar, guarda el resultado frente a la hipótesis, elimina la plantilla si ya no la necesitas y limpia solo los recursos o roles que hayas creado exclusivamente para esta práctica. No termines una instancia existente como “limpieza”. FIS elimina automáticamente los experimentos completados, detenidos o fallidos después de 120 días; consulta los detalles y conserva la evidencia que tu equipo necesite antes de ese plazo.

Para diseñar pruebas de recuperación más amplias, repasa Recuperación ante desastres en AWS: RTO, RPO y estrategias. Un experimento FIS y una prueba de recuperación ante desastres pueden compartir métricas, pero cubren fallas y procedimientos de alcance distinto.

Problemas frecuentes al crear o iniciar un experimento

• Acceso denegado al crear la plantilla: revisa los permisos del operador para crear plantillas y pasar el rol elegido, además de la relación de confianza del rol de experimento.
• El experimento no encuentra la instancia: comprueba que seleccionaste el ID correcto en la región correcta y que el recurso cumple los filtros y el estado requeridos. La vista previa ayuda a detectar un alcance equivocado.
• FIS no puede detener o iniciar la instancia: revisa los permisos del rol de experimento para la acción y, si el volumen usa cifrado, el acceso a la clave de KMS. Confirma que la instancia esté en estado running, use raíz EBS y no tenga protección contra la detención habilitada. Si la protección está activa, coordina con quien administra el recurso antes de cambiarla.
• La alarma detiene el experimento enseguida: confirma que estuviera normal antes de iniciar y que su métrica represente el umbral que quieres usar como límite, no una señal que siempre esté en alarma o sin datos.
• La EC2 inicia, pero la aplicación sigue fallando: iniciar la instancia no restaura automáticamente dependencias ni valida el proceso de la aplicación. Comprueba la salud funcional y aplica el runbook correspondiente.

Comunidades y eventos para seguir aprendiendo

Comparte una descripción sin datos sensibles del experimento y sus resultados con otras personas que aprenden u operan AWS:

• AWS User Group Medellín publica su agenda y ofrece un espacio para conectar con la comunidad; allí también se organizó la charla de Cloud Forge enlazada arriba.
• AWS User Group Ecuador anuncia meetups, talleres y encuentros en ciudades del país y en línea.
• AWS Girls Argentina conecta a mujeres interesadas en aprender y compartir sobre AWS y cloud; su página enlaza eventos y su comunidad de WhatsApp.
• AWS Women Colombia publica artículos y anuncia eventos con contenido técnico en español. Puedes consultar también su grupo en Meetup para ver actividades.
• AWS re:Post es un sitio público de preguntas y respuestas donde se puede pedir orientación técnica y compartir aprendizajes. Para preguntar o responder debes iniciar sesión con credenciales de AWS, completar el perfil y verificar el correo. Su FAQ enumera inglés, chino tradicional y simplificado, japonés, francés y coreano como idiomas admitidos; no incluye español. No publiques IDs de cuenta, datos personales ni información privada de una carga de trabajo.

Si buscas otra comunidad o una próxima actividad, revisa el directorio de comunidades AWS en Latinoamérica y la agenda de eventos. Las fechas, modalidades, idiomas, requisitos de inscripción y costos —si los hay— dependen de cada grupo y evento; confirma esos datos en la página de destino.