https://aws-route53-tf-labs.example.com/index.html AWS Route 53 ARC con Terraform Detección de Caídas y Failover Automático ¿Qué construimos? En este workshop aprenderás a construir una solución de alta disponibilidad para un sitio web estático usando servicios nativos de AWS. El objetivo no es recuperación ante desastres: es que el sistema detecte solo cuando el sitio principal cae, notifique a los equipos correspondientes vía SNS → Email / SMS, redirija el tráfico a una página de mantenimiento, y tenga un mecanismo para volver al sitio primario cuando esté recuperado basado 100% en Terraform. Cada lab despliega un módulo independiente con estado propio (terraform apply / terraform destroy por separado). Hugo es-ES https://aws-route53-tf-labs.example.com/00_prerequisitos/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/00_prerequisitos/index.html Lab 0: Prerrequisitos ¿Dónde correr este workshop? Este workshop es una experiencia volátil diseñada para empezar y concluir en el día. Por este motivo, el estado de Terraform se guarda localmente en archivos terraform.tfstate en el directorio de cada módulo, sin requerir buckets S3 ni almacenamiento remoto. Aviso ¡Cuidado con los archivos terraform.tfstate y AWS CloudShell! Si trabajás en AWS CloudShell, tené en cuenta que el almacenamiento es temporal y la sesión puede resetearse. Si la sesión expira o se reinicia, los archivos terraform.tfstate se perderán. Sin ellos, Terraform ya no sabrá qué recursos existen en AWS y no podrás hacer plan, apply ni destroy automáticamente, teniendo que borrarlos manualmente desde la consola. Nunca borres los archivos terraform.tfstate ni las carpetas del workshop mientras tengas recursos desplegados. https://aws-route53-tf-labs.example.com/01_sitio_primario/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/01_sitio_primario/index.html Lab 1: Sitio Web Primario (EC2 + ALB) Estructura del módulo 01_primary/ ├── main.tf VPC (nueva u default), EC2, ALB ├── variables.tf Inputs del módulo ├── outputs.tf Exports para módulos siguientes └── userdata.sh Script de bootstrap nginx Paso 1: Variables de entorno y Verificación de VPC source ~/route53-arc-tf/global.env cd ~/route53-arc-tf/01_primary Antes de continuar, podés comprobar qué modo de VPC está activo y verificar si tu cuenta posee una VPC Default: https://aws-route53-tf-labs.example.com/02_sitio_secundario/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/02_sitio_secundario/index.html Lab 2: Sitio Secundario – S3 + CloudFront Estructura del módulo 02_secondary/ ├── main.tf S3 bucket, OAC, CloudFront distribution ├── variables.tf └── outputs.tf Paso 1: Setup source ~/route53-arc-tf/global.env cd ~/route53-arc-tf/02_secondary Paso 2: Crear los archivos 1. variables.tf ¿Para qué sirve este archivo? Define las variables de entrada para el módulo del sitio de contingencia (región de AWS y tag identificador del workshop). cat > variables.tf << 'EOF' variable "aws_region" { type = string default = "us-east-1" } variable "project_tag" { type = string default = "route53-arc" } EOF 2. main.tf ¿Para qué sirve este archivo? Declara la arquitectura del sitio secundario de respuesta ante desastres: https://aws-route53-tf-labs.example.com/03_route53_arc/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/03_route53_arc/index.html Lab 3: Route 53 Health Checks + ARC Routing Controls Estructura del módulo 03_arc/ ├── main.tf ARC Cluster, Routing Controls, Health Checks, DNS ├── variables.tf └── outputs.tf Los outputs de los labs anteriores se leen via terraform_remote_state. Paso 1: Setup source ~/route53-arc-tf/global.env cd ~/route53-arc-tf/03_arc Dominio: opcional # Sin dominio (modo demo) export USE_DOMAIN="false" # Con dominio real en Route 53 # export USE_DOMAIN="true" # export DOMAIN_NAME="tudominio.com" # export APP_SUBDOMAIN="app" # export HOSTED_ZONE_ID="Z1234ABCDEF" Paso 2: Crear los archivos 1. variables.tf ¿Para qué sirve este archivo? Define los parámetros de entrada del orquestador de ARC (región, modo demo o dominio real, nombre de dominio, subdominio e ID de la Hosted Zone en Route 53). https://aws-route53-tf-labs.example.com/04_notificaciones_sns/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/04_notificaciones_sns/index.html Lab 4: SNS + Lambda Failover Estructura del módulo 04_automation/ ├── main.tf ├── variables.tf ├── outputs.tf └── lambda/ └── handler.py Paso 1: Setup source ~/route53-arc-tf/global.env cd ~/route53-arc-tf/04_automation mkdir -p lambda # EDITÁ con tu email real export NOTIFICATION_EMAIL="tu-email@ejemplo.com" # export NOTIFICATION_PHONE="+54911XXXXXXXX" # opcional Paso 2: Código Lambda lambda/handler.py ¿Para qué sirve este archivo? Es el código de la función Python que ejecutará la conmutación automática de tráfico (failover). Cuando se activa por una notificación de alerta SNS: https://aws-route53-tf-labs.example.com/05_automatizacion_lambda/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/05_automatizacion_lambda/index.html Lab 5: Simulación de Incidente No hay código Terraform nuevo en este lab — simulamos la caída utilizando la AWS CLI, obteniendo los parámetros necesarios a partir de los outputs exportados por los módulos de Terraform. Paso 1: Cargar variables desde el estado Terraform source ~/route53-arc-tf/global.env # Outputs del Lab 3 (ARC) cd ~/route53-arc-tf/03_arc export PRIMARY_RC_ARN=$(terraform output -raw primary_rc_arn) export SECONDARY_RC_ARN=$(terraform output -raw secondary_rc_arn) export CLUSTER_ENDPOINT=$(terraform output -json arc_cluster_endpoints \ | python3 -c "import json,sys; print(json.load(sys.stdin)[0]['Endpoint'])") # Outputs del Lab 1 (EC2) cd ~/route53-arc-tf/01_primary export EC2_ID=$(terraform output -raw ec2_instance_id) export PRIMARY_ALB_DNS=$(terraform output -raw alb_dns_name) # Outputs del Lab 4 (Automation) cd ~/route53-arc-tf/04_automation export ALARM_NAME=$(terraform output -raw alarm_name) export LAMBDA_NAME=$(terraform output -raw lambda_name) echo "=== Estado inicial ===" echo "ALB DNS: $PRIMARY_ALB_DNS" echo "EC2 ID: $EC2_ID" echo "Alarm: $ALARM_NAME" # Verificar Routing Controls echo "" aws route53-recovery-cluster get-routing-control-state \ --routing-control-arn $PRIMARY_RC_ARN \ --endpoint-url $CLUSTER_ENDPOINT --region $AWS_REGION \ --query 'RoutingControlState' --output text | xargs -I{} echo "Primario: {}" aws route53-recovery-cluster get-routing-control-state \ --routing-control-arn $SECONDARY_RC_ARN \ --endpoint-url $CLUSTER_ENDPOINT --region $AWS_REGION \ --query 'RoutingControlState' --output text | xargs -I{} echo "Secundario: {}" Simulación A: Forzar alarma CloudWatch (inmediato) echo "=== SIMULACIÓN A: Forzando alarma CloudWatch ===" echo "Hora: $(date)" aws cloudwatch set-alarm-state \ --alarm-name $ALARM_NAME \ --state-value ALARM \ --state-reason "Simulación de incidente – AWS Workshop Terraform Workshop" \ --region $AWS_REGION echo "⏳ Esperando que Lambda reaccione..." sleep 15 # Verificar resultado echo "" echo "--- Routing Controls post-failover ---" aws route53-recovery-cluster get-routing-control-state \ --routing-control-arn $PRIMARY_RC_ARN \ --endpoint-url $CLUSTER_ENDPOINT --region $AWS_REGION \ --query 'RoutingControlState' --output text | xargs -I{} echo "Primario: {} (esperado: Off)" aws route53-recovery-cluster get-routing-control-state \ --routing-control-arn $SECONDARY_RC_ARN \ --endpoint-url $CLUSTER_ENDPOINT --region $AWS_REGION \ --query 'RoutingControlState' --output text | xargs -I{} echo "Secundario: {} (esperado: On)" Ver logs de Lambda: https://aws-route53-tf-labs.example.com/06_simulacion_incidente/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/06_simulacion_incidente/index.html Lab 6: Failback – Volver al Sitio Primario El failback siempre es manual y deliberado: primero verificás que el primario esté sano, después cambiás los Routing Controls. Paso 1: Cargar variables source ~/route53-arc-tf/global.env cd ~/route53-arc-tf/03_arc export PRIMARY_RC_ARN=$(terraform output -raw primary_rc_arn) export SECONDARY_RC_ARN=$(terraform output -raw secondary_rc_arn) export CLUSTER_ENDPOINT=$(terraform output -json arc_cluster_endpoints \ | python3 -c "import json,sys; print(json.load(sys.stdin)[0]['Endpoint'])") cd ~/route53-arc-tf/01_primary export EC2_ID=$(terraform output -raw ec2_instance_id) export PRIMARY_ALB_DNS=$(terraform output -raw alb_dns_name) cd ~/route53-arc-tf/04_automation export ALARM_NAME=$(terraform output -raw alarm_name) echo "ALB DNS: $PRIMARY_ALB_DNS" Paso 2: Reparar el sitio primario (si usaste Simulación B) COMMAND_ID=$(aws ssm send-command \ --instance-ids $EC2_ID \ --document-name AWS-RunShellScript \ --parameters 'commands=["systemctl start nginx && systemctl status nginx --no-pager | head -3"]' \ --region $AWS_REGION \ --query 'Command.CommandId' --output text) sleep 10 aws ssm get-command-invocation \ --command-id $COMMAND_ID --instance-id $EC2_ID \ --region $AWS_REGION \ --query '{Status: Status, Output: StandardOutputContent}' --output json Paso 3: Verificar que el primario está sano Aviso No hagas el failback hasta confirmar que el ALB responde HTTP 200. Si volvés el tráfico antes, los usuarios seguirán viendo errores. https://aws-route53-tf-labs.example.com/07_limpieza/index.html Mon, 01 Jan 0001 00:00:00 +0000 https://aws-route53-tf-labs.example.com/07_limpieza/index.html Lab 7: Destroy – Eliminar todos los recursos Con Terraform la limpieza es directa: terraform destroy en cada módulo en orden inverso. Aviso Ejecutá este lab al finalizar. Los recursos generan costos mientras existen. Orden de destroy Los módulos tienen dependencias via terraform_remote_state local. El orden de eliminación es inverso al de creación: 4 → 3 → 2 → 1 Paso 1: Variables source ~/route53-arc-tf/global.env Paso 2: Destroy Lab 4 – SNS + Lambda cd ~/route53-arc-tf/04_automation terraform destroy \ -var="notification_email=dummy@example.com" \ -auto-approve echo "✅ Lab 4 destruido" Paso 3: Destroy Lab 3 – ARC + Route 53 cd ~/route53-arc-tf/03_arc terraform destroy -auto-approve echo "✅ Lab 3 destruido" Información El destroy del ARC Cluster puede tardar 3-5 minutos — AWS lo desaprovisiona de múltiples regiones.