Lab : Configuration Failover Route 53
Objectif du Lab
Concevoir et configurer une solution de failover DNS avec Route 53 pour assurer la continuité de service lors d'une panne.
Partie 1 : Scénario
Contexte
GlobalBank est une banque en ligne qui doit maintenir une disponibilité de 99.99%. En cas de panne de l'infrastructure principale, les clients doivent être automatiquement redirigés vers un site de secours.
Architecture Cible
┌─────────────────────────────────────────────────────────────┐
│ 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% trafic → us-east-1 │
│ Failover : 100% trafic → eu-west-1 │
│ │
└─────────────────────────────────────────────────────────────┘
Exigences
| Exigence | Valeur |
|---|---|
| Disponibilité | 99.99% |
| RTO (Recovery Time Objective) | < 5 minutes |
| RPO (Recovery Point Objective) | < 1 minute |
| Détection de panne | < 90 secondes |
Partie 2 : Configuration des Health Checks
Exercice 2.1 : Créer le Health Check Primary
Complétez la configuration du 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"]
}'
💡 Solution
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"]
}'
Explications :
RequestInterval: 10= vérification toutes les 10 secondes (fast)FailureThreshold: 2= 2 échecs consécutifs = unhealthy- Temps de détection max = 10s × 2 = 20 secondes
- 3 régions pour éviter les faux positifs
Exercice 2.2 : Calculer le Temps de Détection
Avec les paramètres suivants, calculez le temps maximum pour détecter une panne :
| Paramètre | Valeur |
|---|---|
| Request Interval | 10 secondes |
| Failure Threshold | 2 |
| Nombre de checkers | 3 régions |
Temps de détection max = ?
💡 Solution
Temps de détection max = Request Interval × Failure Threshold
= 10s × 2
= 20 secondes
Note : Route 53 considère le health check comme "unhealthy" quand
au moins 18% des checkers (1 sur 3 minimum) rapportent des échecs.
Temps effectif typique : 15-25 secondes
Partie 3 : Configuration du Failover
Exercice 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"
}
}]
}'
💡 Solution
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"
}
}]
}'
Exercice 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": ___
}
}
}]
}'
💡 Solution
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
}
}
}]
}'
Note : Le secondary n'a pas besoin de HealthCheckId car il est utilisé uniquement quand le primary est unhealthy.
Partie 4 : Scénarios de Test
Exercice 4.1 : Plan de Test Failover
Complétez le plan de test :
| Étape | Action | Résultat Attendu | Vérification |
|---|---|---|---|
| 1 | État initial | ? | ? |
| 2 | Simuler panne primary | ? | ? |
| 3 | Vérifier failover | ? | ? |
| 4 | Restaurer primary | ? | ? |
| 5 | Vérifier failback | ? | ? |
💡 Solution
| Étape | Action | Résultat Attendu | Vérification |
|---|---|---|---|
| 1 | État initial | DNS résout vers ALB us-east-1 | dig www.globalbank.com |
| 2 | Stopper l'ALB primary ou retourner 503 | Health check passe unhealthy | Console Route 53 |
| 3 | Attendre 30s | DNS résout vers ALB eu-west-1 | dig www.globalbank.com |
| 4 | Restaurer l'ALB primary | Health check passe healthy | Console Route 53 |
| 5 | Attendre propagation | DNS résout vers ALB us-east-1 | dig www.globalbank.com |
Exercice 4.2 : Script de Test
#!/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é ==="
Partie 5 : Monitoring et Alertes
Configuration 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 Recommandé
| Métrique | Source | Seuil Alerte |
|---|---|---|
| HealthCheckStatus | Route53 | < 1 |
| HealthCheckPercentageHealthy | Route53 | < 100% |
| RequestCount (primary) | ALB | Info |
| RequestCount (secondary) | ALB | > 0 (failover actif!) |
| Latency | ALB | > 1s |
Partie 6 : Analyse d'Impact
Exercice : Calcul du TTL Impact
Si le TTL est de 60 secondes et qu'un failover se produit, combien de temps maximum les utilisateurs peuvent-ils encore être dirigés vers le primary en panne ?
💡 Solution
Impact TTL max = TTL du record
= 60 secondes
Scénario :
1. T=0s : Utilisateur fait requête DNS, reçoit IP primary
2. T=0s : Cache local stocke pour 60s
3. T=30s : Primary tombe, Route 53 bascule vers secondary
4. T=30s : Nouvelle requête DNS → reçoit IP secondary ✅
5. T=30s : Utilisateur avec cache → va toujours vers primary ❌
6. T=60s : Cache expire, nouvelle requête → secondary ✅
Conclusion :
- TTL court (60s) = failover rapide mais plus de requêtes DNS
- TTL long (300s) = moins de requêtes mais failover lent
- Pour DR critique : TTL 30-60s recommandé
Livrable Final
Document à Produire
- Architecture Failover (schéma)
- Configuration complète (Health Check + Records)
- Plan de test avec résultats
- Calculs (temps de détection, impact TTL)
- Monitoring (alertes configurées)
Critères d'Évaluation
| Critère | Points |
|---|---|
| Architecture correcte | /20 |
| Health Check bien configuré | /20 |
| Records Failover corrects | /20 |
| Plan de test complet | /20 |
| Monitoring et alertes | /10 |
| Qualité du document | /10 |
| Total | /100 |
Semaine suivante : MODULE 11 - Lambda