Lab : Configuración de Failover Route 53
Objetivo del Lab
Diseñar y configurar una solución de failover DNS con Route 53 para asegurar la continuidad del servicio en caso de una falla.
Parte 1 : Escenario
Contexto
GlobalBank es un banco en línea que debe mantener una disponibilidad del 99.99%. En caso de falla de la infraestructura principal, los clientes deben ser redirigidos automáticamente a un sitio de respaldo.
Arquitectura Objetivo
┌─────────────────────────────────────────────────────────────┐
│ ARCHITECTURE FAILOVER GLOBALBANK │
├─────────────────────────────────────────────────────────────┤
│ │
│ www.globalbank.com │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Route 53 │ │
│ │ │ │
│ │ Health Check │ │
│ └──────┬───────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ │ │
│ ▼ ▼ │
│ PRIMARY SECONDARY │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ us-east-1 │ │ eu-west-1 │ │
│ │ │ │ │ │
│ │ ┌───────────┐ │ │ ┌───────────┐ │ │
│ │ │ ALB │ │ │ │ ALB │ │ │
│ │ └─────┬─────┘ │ │ └─────┬─────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌─────┴─────┐ │ │ ┌─────┴─────┐ │ │
│ │ │ EC2 ASG │ │ │ │ EC2 ASG │ │ │
│ │ └───────────┘ │ │ └───────────┘ │ │
│ │ │ │ │ │ │ │
│ │ ┌───────────┐ │ │ ┌───────────┐ │ │
│ │ │ RDS Multi │ │ │ │ RDS Read │ │ │
│ │ │ AZ │ │ │ │ Replica │ │ │
│ │ └───────────┘ │ │ └───────────┘ │ │
│ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ Normal : 100% tráfico → us-east-1 │
│ Failover : 100% tráfico → eu-west-1 │
│ │
└─────────────────────────────────────────────────────────────┘
Requisitos
| Requisito | Valor |
|---|---|
| Disponibilidad | 99.99% |
| RTO (Recovery Time Objective) | < 5 minutos |
| RPO (Recovery Point Objective) | < 1 minuto |
| Detección de falla | < 90 segundos |
Parte 2 : Configuración de Health Checks
Ejercicio 2.1 : Crear el Health Check Primary
Complete la configuración del health check:
aws route53 create-health-check \
--caller-reference globalbank-primary-$(date +%s) \
--health-check-config '{
"Type": "_______________",
"ResourcePath": "_______________",
"FullyQualifiedDomainName": "primary-alb.us-east-1.elb.amazonaws.com",
"Port": ___,
"RequestInterval": ___,
"FailureThreshold": ___,
"EnableSNI": true,
"Regions": ["us-east-1", "us-west-2", "eu-west-1"]
}'
💡 Solución
aws route53 create-health-check \
--caller-reference globalbank-primary-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"ResourcePath": "/health",
"FullyQualifiedDomainName": "primary-alb.us-east-1.elb.amazonaws.com",
"Port": 443,
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true,
"Regions": ["us-east-1", "us-west-2", "eu-west-1"]
}'
Explicaciones:
RequestInterval: 10= verificación cada 10 segundos (rápido)FailureThreshold: 2= 2 fallos consecutivos = unhealthy- Tiempo de detección máximo = 10s × 2 = 20 segundos
- 3 regiones para evitar falsos positivos
Ejercicio 2.2 : Calcular el Tiempo de Detección
Con los siguientes parámetros, calcule el tiempo máximo para detectar una falla:
| Parámetro | Valor |
|---|---|
| Request Interval | 10 segundos |
| Failure Threshold | 2 |
| Número de checkers | 3 regiones |
Tiempo de detección máx = ?
💡 Solución
Tiempo de detección máx = Request Interval × Failure Threshold
= 10s × 2
= 20 segundos
Nota: Route 53 considera el health check como "unhealthy" cuando
al menos el 18% de los checkers (1 de 3 mínimo) reportan fallos.
Tiempo efectivo típico: 15-25 segundos
Parte 3 : Configuración del Failover
Ejercicio 3.1 : Record Primary
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "_______________",
"Failover": "_______________",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "primary-alb.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": ___
},
"HealthCheckId": "xxx-primary-health-check"
}
}]
}'
💡 Solución
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "primary-us-east-1",
"Failover": "PRIMARY",
"AliasTarget": {
"HostedZoneId": "Z35SXDOTRQ7X7K",
"DNSName": "primary-alb.us-east-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
},
"HealthCheckId": "xxx-primary-health-check"
}
}]
}'
Ejercicio 3.2 : Record Secondary
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "_______________",
"Failover": "_______________",
"AliasTarget": {
"HostedZoneId": "Z1234567890DEF",
"DNSName": "secondary-alb.eu-west-1.elb.amazonaws.com",
"EvaluateTargetHealth": ___
}
}
}]
}'
💡 Solución
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890ABC \
--change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.globalbank.com",
"Type": "A",
"SetIdentifier": "secondary-eu-west-1",
"Failover": "SECONDARY",
"AliasTarget": {
"HostedZoneId": "Z1234567890DEF",
"DNSName": "secondary-alb.eu-west-1.elb.amazonaws.com",
"EvaluateTargetHealth": true
}
}
}]
}'
Nota: El secondary no necesita HealthCheckId porque se utiliza únicamente cuando el primary está unhealthy.
Parte 4 : Escenarios de Prueba
Ejercicio 4.1 : Plan de Prueba Failover
Complete el plan de prueba:
| Paso | Acción | Resultado Esperado | Verificación |
|---|---|---|---|
| 1 | Estado inicial | ? | ? |
| 2 | Simular falla primary | ? | ? |
| 3 | Verificar failover | ? | ? |
| 4 | Restaurar primary | ? | ? |
| 5 | Verificar failback | ? | ? |
💡 Solución
| Paso | Acción | Resultado Esperado | Verificación |
|---|---|---|---|
| 1 | Estado inicial | DNS resuelve hacia ALB us-east-1 | dig www.globalbank.com |
| 2 | Detener el ALB primary o devolver 503 | Health check pasa a unhealthy | Consola Route 53 |
| 3 | Esperar 30s | DNS resuelve hacia ALB eu-west-1 | dig www.globalbank.com |
| 4 | Restaurar el ALB primary | Health check pasa a healthy | Consola Route 53 |
| 5 | Esperar propagación | DNS resuelve hacia ALB us-east-1 | dig www.globalbank.com |
Ejercicio 4.2 : Script de Prueba
#!/bin/bash
# test-failover.sh
DOMAIN="www.globalbank.com"
PRIMARY_IP="52.xxx.xxx.xxx"
SECONDARY_IP="54.xxx.xxx.xxx"
echo "=== Test Failover Route 53 ==="
# Étape 1 : Vérifier l'état initial
echo "1. État initial..."
CURRENT_IP=$(dig +short $DOMAIN | head -1)
if [ "$CURRENT_IP" == "$PRIMARY_IP" ]; then
echo " ✅ DNS pointe vers PRIMARY"
else
echo " ❌ DNS ne pointe pas vers PRIMARY: $CURRENT_IP"
exit 1
fi
# Étape 2 : Simuler la panne (manuel)
echo "2. Simulez la panne du PRIMARY maintenant..."
echo " (Stoppez l'ALB ou modifiez /health pour retourner 503)"
read -p " Appuyez sur Entrée quand c'est fait..."
# Étape 3 : Attendre le failover
echo "3. Attente du failover (60s max)..."
for i in {1..12}; do
sleep 5
CURRENT_IP=$(dig +short $DOMAIN | head -1)
echo " Check $i: $CURRENT_IP"
if [ "$CURRENT_IP" == "$SECONDARY_IP" ]; then
echo " ✅ Failover réussi en $((i*5)) secondes!"
break
fi
done
# Étape 4 : Vérifier l'accès
echo "4. Test d'accès au secondary..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN/health)
if [ "$HTTP_CODE" == "200" ]; then
echo " ✅ Site accessible via SECONDARY"
else
echo " ❌ Site non accessible: HTTP $HTTP_CODE"
fi
echo "=== Test terminé ==="
Parte 5 : Monitoreo y Alertas
Configuración de CloudWatch Alarm
# Alerte quand le health check passe unhealthy
aws cloudwatch put-metric-alarm \
--alarm-name globalbank-primary-unhealthy \
--metric-name HealthCheckStatus \
--namespace AWS/Route53 \
--statistic Minimum \
--period 60 \
--threshold 1 \
--comparison-operator LessThanThreshold \
--dimensions Name=HealthCheckId,Value=xxx-primary-health-check \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789:ops-alerts \
--alarm-description "GlobalBank primary site is unhealthy"
Dashboard Recomendado
| Métrica | Fuente | Umbral de Alerta |
|---|---|---|
| HealthCheckStatus | Route53 | < 1 |
| HealthCheckPercentageHealthy | Route53 | < 100% |
| RequestCount (primary) | ALB | Info |
| RequestCount (secondary) | ALB | > 0 (¡failover activo!) |
| Latency | ALB | > 1s |
Parte 6 : Análisis de Impacto
Ejercicio : Cálculo del Impacto TTL
Si el TTL es de 60 segundos y ocurre un failover, ¿cuánto tiempo máximo los usuarios pueden seguir siendo dirigidos al primary caído?
💡 Solución
Impacto TTL máx = TTL del record
= 60 segundos
Escenario:
1. T=0s : Usuario hace consulta DNS, recibe IP primary
2. T=0s : Caché local almacena por 60s
3. T=30s : Primary cae, Route 53 cambia a secondary
4. T=30s : Nueva consulta DNS → recibe IP secondary ✅
5. T=30s : Usuario con caché → sigue yendo al primary ❌
6. T=60s : Caché expira, nueva consulta → secondary ✅
Conclusión:
- TTL corto (60s) = failover rápido pero más consultas DNS
- TTL largo (300s) = menos consultas pero failover lento
- Para DR crítico: TTL 30-60s recomendado
Entregable Final
Documento a Entregar
- Arquitectura Failover (diagrama)
- Configuración completa (Health Check + Records)
- Plan de prueba con resultados
- Cálculos (tiempo de detección, impacto TTL)
- Monitoreo (alertas configuradas)
Criterios de Evaluación
| Criterio | Puntos |
|---|---|
| Arquitectura correcta | /20 |
| Health Check bien configurado | /20 |
| Records Failover correctos | /20 |
| Plan de prueba completo | /20 |
| Monitoreo y alertas | /10 |
| Calidad del documento | /10 |
| Total | /100 |
Semana siguiente: MODULE 11 - Lambda