Lab : Configuração de Failover Route 53
Objetivo do Lab
Projetar e configurar uma solução de failover DNS com Route 53 para garantir a continuidade do serviço em caso de falha.
Parte 1 : Cenário
Contexto
GlobalBank é um banco digital que precisa manter uma disponibilidade de 99,99%. Em caso de falha da infraestrutura principal, os clientes devem ser automaticamente redirecionados para um site de contingência.
Arquitetura Alvo
┌─────────────────────────────────────────────────────────────┐
│ ARQUITETURA 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áfego → us-east-1 │
│ Failover : 100% tráfego → eu-west-1 │
│ │
└─────────────────────────────────────────────────────────────┘
Requisitos
| Requisito | Valor |
|---|---|
| Disponibilidade | 99,99% |
| RTO (Recovery Time Objective) | < 5 minutos |
| RPO (Recovery Point Objective) | < 1 minuto |
| Detecção de falha | < 90 segundos |
Parte 2 : Configuração dos Health Checks
Exercício 2.1 : Criar o Health Check Primary
Complete a configuração do 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"]
}'
💡 Solução
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"]
}'
Explicações:
RequestInterval: 10= verificação a cada 10 segundos (rápido)FailureThreshold: 2= 2 falhas consecutivas = unhealthy- Tempo máximo de detecção = 10s × 2 = 20 segundos
- 3 regiões para evitar falsos positivos
Exercício 2.2 : Calcular o Tempo de Detecção
Com os seguintes parâmetros, calcule o tempo máximo para detectar uma falha:
| Parâmetro | Valor |
|---|---|
| Request Interval | 10 segundos |
| Failure Threshold | 2 |
| Número de checkers | 3 regiões |
Tempo máximo de detecção = ?
💡 Solução
Tempo máximo de detecção = Request Interval × Failure Threshold
= 10s × 2
= 20 segundos
Nota: O Route 53 considera o health check como "unhealthy" quando
pelo menos 18% dos checkers (mínimo 1 de 3) reportam falhas.
Tempo efetivo típico: 15-25 segundos
Parte 3 : Configuração do Failover
Exercício 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"
}
}]
}'
💡 Solução
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"
}
}]
}'
Exercício 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": ___
}
}
}]
}'
💡 Solução
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: O secondary não precisa de HealthCheckId pois ele é utilizado apenas quando o primary está unhealthy.
Parte 4 : Cenários de Teste
Exercício 4.1 : Plano de Teste Failover
Complete o plano de teste:
| Etapa | Ação | Resultado Esperado | Verificação |
|---|---|---|---|
| 1 | Estado inicial | ? | ? |
| 2 | Simular falha do primary | ? | ? |
| 3 | Verificar failover | ? | ? |
| 4 | Restaurar primary | ? | ? |
| 5 | Verificar failback | ? | ? |
💡 Solução
| Etapa | Ação | Resultado Esperado | Verificação |
|---|---|---|---|
| 1 | Estado inicial | DNS resolve para ALB us-east-1 | dig www.globalbank.com |
| 2 | Parar o ALB primary ou retornar 503 | Health check fica unhealthy | Console Route 53 |
| 3 | Aguardar 30s | DNS resolve para ALB eu-west-1 | dig www.globalbank.com |
| 4 | Restaurar o ALB primary | Health check fica healthy | Console Route 53 |
| 5 | Aguardar propagação | DNS resolve para ALB us-east-1 | dig www.globalbank.com |
Exercício 4.2 : Script de Teste
#!/bin/bash
# test-failover.sh
DOMAIN="www.globalbank.com"
PRIMARY_IP="52.xxx.xxx.xxx"
SECONDARY_IP="54.xxx.xxx.xxx"
echo "=== Teste Failover Route 53 ==="
# Etapa 1 : Verificar o estado inicial
echo "1. Estado inicial..."
CURRENT_IP=$(dig +short $DOMAIN | head -1)
if [ "$CURRENT_IP" == "$PRIMARY_IP" ]; then
echo " ✅ DNS aponta para PRIMARY"
else
echo " ❌ DNS não aponta para PRIMARY: $CURRENT_IP"
exit 1
fi
# Etapa 2 : Simular a falha (manual)
echo "2. Simule a falha do PRIMARY agora..."
echo " (Pare o ALB ou modifique /health para retornar 503)"
read -p " Pressione Enter quando estiver pronto..."
# Etapa 3 : Aguardar o failover
echo "3. Aguardando o failover (máx 60s)..."
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 realizado em $((i*5)) segundos!"
break
fi
done
# Etapa 4 : Verificar acesso
echo "4. Testando acesso ao secondary..."
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN/health)
if [ "$HTTP_CODE" == "200" ]; then
echo " ✅ Site acessível via SECONDARY"
else
echo " ❌ Site não acessível: HTTP $HTTP_CODE"
fi
echo "=== Teste finalizado ==="
Parte 5 : Monitoramento e Alertas
Configuração CloudWatch Alarm
# Alerta quando o health check fica 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 | Fonte | Limite de Alerta |
|---|---|---|
| HealthCheckStatus | Route53 | < 1 |
| HealthCheckPercentageHealthy | Route53 | < 100% |
| RequestCount (primary) | ALB | Info |
| RequestCount (secondary) | ALB | > 0 (failover ativo!) |
| Latency | ALB | > 1s |
Parte 6 : Análise de Impacto
Exercício : Cálculo do Impacto do TTL
Se o TTL for de 60 segundos e ocorrer um failover, por quanto tempo no máximo os usuários ainda podem ser direcionados para o primary fora do ar?
💡 Solução
Impacto TTL máx = TTL do record
= 60 segundos
Cenário:
1. T=0s : Usuário faz requisição DNS, recebe IP do primary
2. T=0s : Cache local armazena por 60s
3. T=30s : Primary cai, Route 53 alterna para secondary
4. T=30s : Nova requisição DNS → recebe IP do secondary ✅
5. T=30s : Usuário com cache → ainda vai para o primary ❌
6. T=60s : Cache expira, nova requisição → secondary ✅
Conclusão:
- TTL curto (60s) = failover rápido mas mais requisições DNS
- TTL longo (300s) = menos requisições mas failover lento
- Para DR crítico: TTL 30-60s recomendado
Entregável Final
Documento a Produzir
- Arquitetura Failover (diagrama)
- Configuração completa (Health Check + Records)
- Plano de teste com resultados
- Cálculos (tempo de detecção, impacto do TTL)
- Monitoramento (alertas configurados)
Critérios de Avaliação
| Critério | Pontos |
|---|---|
| Arquitetura correta | /20 |
| Health Check bem configurado | /20 |
| Records Failover corretos | /20 |
| Plano de teste completo | /20 |
| Monitoramento e alertas | /10 |
| Qualidade do documento | /10 |
| Total | /100 |
Semana seguinte: MODULE 11 - Lambda