Pilot light multi-región en AWS: el diagrama era lo fácil, el failover no
Una implementación de referencia con Terraform monta el patrón pilot light en dos regiones de AWS y cronometra el failover: RPO de segundos y RTO de 10 a 15 minutos.
Los artículos sobre recuperación ante desastres suelen acabar donde empieza lo interesante: dos cajas, una flecha que pone "replicate" y un RTO que nadie ha medido. Alguien ha publicado en GitHub una implementación de referencia que intenta cubrir el resto, con Terraform, un failover cronometrable y una justificación escrita para cada decisión. El repositorio levanta una API de notas en dos regiones de AWS siguiendo el patrón pilot light.
La aplicación es deliberadamente pequeña. Lo que se enseña es la arquitectura: eu-west-1 (Irlanda) atiende todo el tráfico, mientras eu-west-3 (París) recibe cada escritura de base de datos y cada objeto de S3 pero ejecuta cero instancias de aplicación. Route 53 sondea el primario cada 10 segundos y cambia el DNS por su cuenta cuando falla. Después, una persona promociona la réplica de lectura de RDS y escala el Auto Scaling Group dormido, las dos cosas con un único script. El cliente sigue usando la misma URL y no cambia nada.
Los objetivos mandan sobre el patrón
La elección no salió de una preferencia estética. Los objetivos declarados eran un RPO por debajo de un minuto (en la práctica, segundos de lag asíncrono) y un RTO por debajo de 30 minutos, con una expectativa de 10 a 15. Con esas cifras, backup and restore no llega: son horas. Active-active exige Aurora Global Database o resolución de conflictos en la aplicación, que es otro producto. Warm standby parece el término medio hasta que se mira dónde está el cuello de botella: no es arrancar instancias, es promover la réplica, y pagar computación ociosa no acelera esa operación.
Las dos regiones se construyen con los mismos módulos de Terraform y son estructuralmente idénticas: VPC en dos zonas de disponibilidad, subredes públicas con el ALB y un NAT, subredes privadas con la API y RDS, sin IP pública para nada más. El ALB termina TLS con certificado ACM regional, el Auto Scaling Group usa Amazon Linux 2023 y no hay SSH, solo Session Manager. PostgreSQL en RDS, S3 para adjuntos y Secrets Manager para la contraseña.
Solo cambian dos cosas entre regiones: qué base de datos es escribible y la capacidad deseada del ASG, dos instancias en Irlanda y cero en París. Ese número es el pilot light entero.
Un solo paso irreversible
Hay dos flujos de replicación. RDS replica entre regiones de forma asíncrona y la promoción tarda entre 5 y 10 minutos; es un camino de ida. S3 usa replicación entre regiones con delete markers y no requiere acción porque el bucket ya está vivo en ambos sitios. Las credenciales viajan por una réplica multi-región de Secrets Manager con el mismo nombre de secreto. El runbook existe, básicamente, para una cosa: promocionar.
La cadena de failover es la parte que los diagramas se saltan. El endpoint /health ejecuta un SELECT 1 contra la base local, así que una capa de datos rota saca la instancia del target group del ALB. Dos fallos consecutivos en Route 53 marcan el registro como no saludable y el DNS apunta al ALB secundario en unos 30 segundos más el TTL, sin intervención humana. Una alarma de CloudWatch avisa por SNS y alguien ejecuta el script que promociona la réplica y escala el ASG en paralelo. El registro secundario no evalúa la salud del destino a propósito: durante el calentamiento, mandar clientes a una región a punto de estar lista es mejor que no mandarlos a ninguna parte. La verificación es una cabecera que la API ya devuelve, x-serving-region.
Lo útil aquí no es el patrón, que está documentado hasta la saciedad, sino los números medidos y el reconocimiento de que el tiempo se va en la promoción de la base de datos y no en el arranque de las instancias.
