AWS Builder Center

Builder Center

Pruebas de resiliencia recomendadas en AWS Resilience Hub: un runbook que nunca se ejecutó es una hipótesis

Casi todos los runbooks de conmutación entre Regiones tienen una cifra de tiempo en alguna parte: cuántos minutos para detectar, cuántos para decidir, cuántos para que el tráfico llegue a la Región de recuperación. Casi ninguno dice cuándo fue la última vez que alguien midió esa cifra. Mientras nadie la ponga a prueba, el runbook describe lo que el equipo espera que pase.

vtjean

En esta serie ya tratamos qué señal observar y contra qué objetivo medirla. Esta entrada vuelve al runbook, esta vez para probarlo antes de que lo pruebe un incidente. El 3 de agosto de 2026, la nueva generación de AWS Resilience Hub incorporó pruebas de resiliencia recomendadas. Son pruebas preconfiguradas que inyectan fallas controladas con AWS Fault Injection Service (AWS FIS) y deciden si el servicio pasó según dos cosas que el equipo ya definió: sus alarmas y su objetivo de tiempo de recuperación, el RTO.
La guía de usuario documenta la nueva generación en una sección aparte de la versión anterior, que ya ofrecía experimentos de AWS FIS con plantillas precargadas. Esta entrada trata solo la nueva generación.

Plantilla, prueba y ejecución

La función se apoya en tres conceptos:
  • Plantilla de prueba: una prueba recomendada y preconfigurada que define qué capacidad de resiliencia se valida, qué acciones ejecuta y qué parámetros acepta.
  • Prueba: la plantilla configurada para un servicio concreto, con sus criterios de éxito, sus condiciones de parada y el resto de los ajustes. Cada servicio tiene una prueba por plantilla, y la configuración se guarda para las siguientes ejecuciones.
  • Ejecución: cada vez que se inicia la prueba. Toma los recursos que el servicio tiene en ese momento y produce un resultado de aprobado o reprobado, con sus resultados y un reporte. Una misma prueba puede ejecutarse muchas veces.
Las pruebas corren a nivel de servicio. En cada ejecución, Resilience Hub incluye en el alcance todos los recursos descubiertos del servicio a los que aplica la prueba, la configura con las alarmas de éxito, las condiciones de parada y los destinos de logs que se hayan definido, inyecta las fallas con experimentos de AWS FIS durante el tiempo indicado y evalúa el resultado contra los criterios de éxito.

Las cuatro pruebas

Tres de las plantillas siguen los límites de aislamiento de fallas de AWS, que son las zonas de disponibilidad y las Regiones. La cuarta valida las dependencias.

Availability Zone: recovery

Inyecta los síntomas de una interrupción eléctrica en una sola zona de disponibilidad, con efecto en el cómputo, la red, el almacenamiento y las bases de datos de esa zona. Entre sus acciones están detener instancias de Amazon EC2 en la zona afectada, impedir que se lancen instancias nuevas ahí, cortar el tráfico de las subredes de esa zona y forzar la conmutación de un clúster de Amazon RDS si el nodo de escritura está en la zona afectada.
Es una prueba de recuperación. La cuenta del RTO empieza cuando empiezan las acciones, y la prueba pasa si todas las alarmas de éxito vuelven al estado OK dentro del RTO y se mantienen ahí hasta que terminan las acciones. La duración predeterminada es el RTO de la política del servicio más 30 minutos. También sirve para descubrir dependencias de una sola zona que nadie tenía en el mapa.

Dependency validation

Bloquea dependencias dentro de la Región para ver cómo se comporta el servicio sin ellas. Las acciones inyectan un 100 % de pérdida de paquetes desde instancias de Amazon EC2, tareas de Amazon ECS (sobre Amazon EC2 y AWS Fargate) y pods de Amazon EKS sobre Amazon EC2 hacia las dependencias elegidas.
Es una prueba sostenida: pasa si todas las alarmas de éxito se mantienen en OK hasta que terminan las acciones. Sirve para confirmar que una dependencia que el equipo considera blanda de verdad lo es. Si las alarmas se disparan, esa dependencia probablemente es dura. La duración predeterminada es de 30 minutos.

Multi-Region: isolation

Corta la conectividad entre dos Regiones. Eso incluye el tráfico de red, la replicación entre Regiones de Amazon S3, Amazon DynamoDB y Amazon MemoryDB, y de forma opcional las dependencias entre ambas. Valida que una Región puede operar sola.
También es una prueba sostenida, con una duración predeterminada de 3 horas. La documentación la propone como paso previo a la recuperación multirregión: primero se confirma que la Región de recuperación funciona aislada y después se prueba la conmutación completa.

Multi-Region: recovery

Inyecta fallas en dependencias de una Región para validar que el servicio se recupera y atiende clientes desde otra Región dentro de sus objetivos de recuperación. Aplica a arquitecturas activo/activo y activo/pasivo, y requiere que la política de resiliencia del servicio tenga definido un RTO multirregión.
Pasa si todas las alarmas de éxito vuelven a OK dentro de ese RTO multirregión y se mantienen ahí hasta que terminan las acciones. La duración predeterminada es ese RTO más 30 minutos.

La prueba no ejecuta el runbook por ti

En la prueba de recuperación multirregión, Resilience Hub inyecta las fallas en la Región afectada y la recuperación la ejecuta el equipo, por ejemplo iniciando la conmutación o un plan de Region switch de AWS Application Recovery Controller (ARC). La prueba observa si la Región de recuperación queda sana dentro del RTO a partir del estado de las alarmas.
Ahí se mide el runbook. Como la cuenta del RTO empieza cuando empiezan las acciones, entra todo: el tiempo que tarda la guardia en darse cuenta, el tiempo que tarda en decidir y el tiempo que tarda en ejecutar. Si el runbook dice 15 minutos y la detección ya consume 10, la prueba lo va a mostrar.
Si el equipo usa un plan de Region switch de ARC, se puede asociar a la prueba para que el reporte incluya la línea de tiempo real de la conmutación. Si la conmutación es manual o usa otra automatización, ese campo se deja vacío.
La prueba de zona de disponibilidad funciona distinto. Si los recursos tienen activado el desplazamiento zonal automático de ARC, la prueba lo ejercita sola. Si no está configurado, esa acción se omite. En la práctica, la prueba de zona valida sobre todo los mecanismos automáticos, y la multirregión valida además a las personas y el procedimiento.

Las alarmas de éxito deciden el resultado

Cada prueba necesita al menos una alarma de éxito de Amazon CloudWatch. Si hay varias, todas tienen que cumplir para que la prueba pase. También se pueden agregar alarmas adicionales, que aparecen en los resultados y en el reporte pero no afectan el resultado.
La elección de las alarmas pesa más de lo que parece, y la documentación da pautas para cada prueba:
  • En la prueba de zona, conviene usar alarmas que midan la salud regional del servicio, como la tasa de errores o la latencia de toda la Región. Las alarmas por zona sobran, porque se espera que la zona afectada quede mal.
  • En la validación de dependencias, las alarmas tienen que medir la salud del servicio y no la de la dependencia bloqueada.
  • En la recuperación multirregión, sirven las alarmas de la Región de recuperación que confirmen que atiende tráfico, o alarmas globales que reflejen la experiencia del cliente.
La documentación también pide que las dependencias bloqueadas estén recibiendo tráfico durante la prueba, porque así se confirma que el bloqueo tiene efecto, y sugiere agregar métricas de uso de la dependencia, como el número de solicitudes o los errores de conexión. Un aprobado en un entorno sin tráfico dice poco.
Hay un detalle que la documentación de Resilience Hub no trata y que conviene revisar. El aprobado se define por el estado OK de las alarmas. En CloudWatch, una alarma sin datos pasa por defecto a INSUFFICIENT_DATA, que es un estado distinto de OK. Y una alarma que trata los datos faltantes como notBreaching puede quedarse en OK justo cuando el componente que publica la métrica deja de hacerlo durante la falla. La documentación no explica cómo interpreta Resilience Hub ninguno de los dos casos, así que antes de confiar en un aprobado conviene revisar cómo trata cada alarma de éxito los datos faltantes.

Guardas antes de inyectar fallas

Estas pruebas detienen instancias, cortan tráfico y pausan replicación, y todo eso ocurre de verdad. Antes de la primera ejecución conviene preparar varias cosas.
Las condiciones de parada son alarmas de CloudWatch que detienen la prueba si superan su umbral. La documentación recomienda usarlas como protección, por ejemplo con una alarma sobre una métrica de negocio crítica como la latencia o la tasa de errores. Esas alarmas tienen que estar en la cuenta donde corre la prueba y en la Región donde se inyectan las fallas.
El orden también importa. Para la validación de dependencias, la documentación sugiere empezar con una sola dependencia blanda e ir sumando. Para la parte multirregión, sugiere probar el aislamiento antes que la recuperación. Una práctica razonable, que ya no viene de la documentación, es hacer la primera ejecución de cada plantilla en un entorno de preproducción con tráfico sintético y pasar a producción cuando el equipo entienda el efecto de cada acción.
Hay requisitos técnicos que conviene revisar antes:
  • Las acciones que bloquean dependencias necesitan el agente de AWS Systems Manager instalado en las instancias de Amazon EC2, un contenedor con ese agente en la definición de tarea de Amazon ECS, o una cuenta de servicio de Kubernetes para los pods de Amazon EKS.
  • Las dependencias tienen que ser endpoints DNS que resuelvan. Si el DNS no resuelve, la acción falla.
  • Si al bloquear una dependencia fallan los chequeos de salud y el cómputo se reemplaza, la pérdida de paquetes no se vuelve a aplicar a las tareas nuevas y la acción puede aparecer como fallida.
  • Hace falta un rol de ejecución de AWS Identity and Access Management (IAM), con permisos que cambian según la prueba y las opciones elegidas. En pruebas que abarcan varias cuentas, se usa un rol con el mismo nombre en cada cuenta.
Un último punto: si el servicio no tiene recursos del tipo al que apunta una acción, esa acción se omite. Un aprobado puede haber ejercitado menos componentes de los que el equipo imagina, así que vale la pena revisar qué acciones corrieron realmente.

Ejemplos con la AWS CLI

Estos comandos de la AWS Command Line Interface (AWS CLI) aparecen en la documentación. Cada uno va en una sola línea.
Para ver las plantillas disponibles:
1
aws resiliencehubv2 list-test-templates --region us-east-1
Para ver la definición completa de una plantilla, con sus acciones y sus parámetros:
1
aws resiliencehubv2 get-test-template --test-template-arn "arn:aws:resiliencehub:us-east-1:aws:test-template/aws-az-recovery:rtaz001" --region us-east-1
La respuesta indica, para cada parámetro, si es obligatorio, su tipo y su valor predeterminado. Conviene revisarla, porque los valores predeterminados de duración y dependencias solo aplican en la consola.
Para iniciar una ejecución de una prueba ya creada y consultar su resultado:
1
2
aws resiliencehubv2 start-test-run --test-id "test-id"
aws resiliencehubv2 get-test-run --test-run-id "test-run-id"

Resultados y reportes

Cada ejecución muestra el estado, los tiempos, el resultado de cada alarma de éxito, una línea de tiempo de las acciones y las dependencias bloqueadas. Desde el detalle se llega al identificador del experimento de AWS FIS y al resultado de cada acción. Por API están las operaciones ListTestRuns y GetTestRun, más ListTestRunSourceEvents para la línea de tiempo de cambios de estado de las alarmas y ListTestRunDependencies para las dependencias bloqueadas.
El reporte se genera solo al terminar cada ejecución, siempre que el servicio tenga configurado un bucket de Amazon S3 como destino de reportes. Si no hay destino, no hay reporte. El reporte incluye la configuración, el resultado de los criterios de éxito, una línea de tiempo visual de cómo respondió el servicio y el resultado final, y no tiene costo adicional. Los logs detallados de la prueba se pueden enviar a Amazon S3, a Amazon CloudWatch Logs o a ambos, con permisos adicionales en el rol de ejecución.
La documentación da como ejemplo correr la prueba de zona una vez al mes para seguir la evolución. Ese ritmo encaja con el runbook: cada reporte muestra en qué parte del RTO se fue el tiempo, y ese es el dato para corregir el procedimiento antes de la siguiente ejecución.

Limitaciones

  • Las pruebas recomendadas están disponibles en 15 Regiones, según el anuncio. En Sudamérica, la única es São Paulo.
  • Inyectan fallas reales, así que hay que planificar dónde y cuándo se corren.
  • Se cobran según el precio por minuto de acción de AWS FIS.
  • Cada servicio admite una prueba por plantilla.
  • El reporte solo se genera si el servicio tiene un destino de Amazon S3 configurado.
  • Los valores predeterminados de duración y dependencias solo aplican en la consola. Por API hay que indicarlos.
  • La pérdida de paquetes aplica a instancias de Amazon EC2, tareas de Amazon ECS sobre Amazon EC2 y AWS Fargate, y pods de Amazon EKS sobre Amazon EC2, y requiere el agente de AWS Systems Manager o una cuenta de servicio de Kubernetes.
  • La recuperación multirregión requiere un RTO multirregión en la política, y la conmutación la ejecuta el equipo.
  • Las acciones sin recursos del tipo correspondiente se omiten, así que un aprobado puede cubrir menos de lo esperado.
  • La documentación no explica cómo afectan al resultado las alarmas de éxito en INSUFFICIENT_DATA ni las que tratan los datos faltantes como notBreaching.

Recursos

# aws-resilience-hub# resilience# sre# cloud-operations# chaos-engineering
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article