Amazon Route 53 é o serviço de DNS gerenciado da AWS, com suporte a múltiplas políticas de roteamento e health checks.

🎯 Para a certificação

Questões tendem a avaliar o uso de políticas de roteamento (simple, weighted, latency, failover, geolocation, geoproximity, multivalue, IP-based), Alias Records vs CNAME, e health checks para disponibilidade e balanceamento inteligente de tráfego.

---

Resumo

DNS (Domain Name System) é a "lista telefônica" da Internet: traduz um nome fácil de lembrar (www.leware.com.br) para o endereço IP real do servidor que atende aquele nome. Sem DNS, você precisaria decorar números IP para acessar qualquer site.

Route 53 é o serviço da AWS que faz duas coisas relacionadas, mas distintas: (1) registra e hospeda domínios, respondendo a consultas DNS pelo mundo todo, e (2) decide, de forma inteligente, qual endereço devolver para uma mesma pergunta, dependendo de peso, latência, localização do usuário, ou saúde do destino.

• Políticas de roteamento: Simple, Weighted, Latency, Failover, Geolocation, Geoproximity, Multivalue Answer, IP-based.
• Alias Records: um tipo especial de registro, exclusivo da AWS, que aponta diretamente para recursos AWS (ALB, CloudFront, S3) sem os limites do CNAME tradicional.
• Health checks: monitoram endpoints e podem acionar failover automático.
• TTL e caching: influenciam o tempo de propagação de mudanças e o volume de consultas.

---

1. Como DNS funciona, por dentro

Quando você digita www.leware.com.br no navegador, acontece uma cadeia de perguntas (simplificada):

1. Seu computador pergunta a um resolver (geralmente do seu provedor de Internet) "qual o IP de www.leware.com.br?".
2. O resolver pergunta aos servidores root da Internet: "quem cuida do .br?".
3. O servidor de .br responde: "pergunte ao servidor de .com.br".
4. Eventualmente, a pergunta chega ao servidor autoritativo do domínio leware.com.br — que, se o domínio estiver no Route 53, é o próprio Route 53.
5. O Route 53 responde com o IP configurado (ou aplica a política de roteamento configurada para decidir qual IP devolver).

O Route 53 pode atuar como registrador de domínio (comprar/renovar o domínio em si) e/ou como servidor DNS autoritativo (hospedar os registros e responder as consultas) — são funções relacionadas, mas você pode registrar um domínio em outro provedor e ainda assim usar o Route 53 só para hospedar o DNS dele.

---

2. Hosted Zones — públicas vs privadas

Uma hosted zone é o container dos registros DNS de um domínio dentro do Route 53.

• Public hosted zone: responde a consultas vindas da Internet pública — é o caso comum, para o site/API que qualquer pessoa acessa.
• Private hosted zone: só responde a consultas originadas de dentro de uma ou mais VPCs específicas que você associa a ela — usada para nomes internos (ex: db.interno.leware) que não devem ser resolvíveis publicamente.

---

3. Tipos de registro DNS mais comuns

---

4. Alias Records — o conceito mais cobrado do Route 53

Este é o ponto que qualquer material de Route 53 precisa deixar muito claro, e que costuma ser mal explicado: por que existe um tipo de registro exclusivo da AWS, o Alias Record, se já existe CNAME?

4.1 O problema que o CNAME tem

Um registro CNAME aponta um nome para outro nome de domínio, não para um IP. Isso tem duas limitações importantes:

1. CNAME não pode ser usado no "apex" (raiz) de um domínio — ou seja, você não pode criar um CNAME para leware.com.br (sem subdomínio), só para algo como www.leware.com.br. Isso é uma regra do próprio protocolo DNS, não uma limitação da AWS.
2. Toda consulta a um CNAME exige uma resolução extra (primeiro resolve o CNAME, depois resolve o nome final para o IP) — uma camada indireta a mais.

4.2 Como o Alias Record resolve isso

Um Alias Record é um recurso especial do Route 53 que aponta diretamente para um recurso AWS (um Load Balancer, uma distribuição CloudFront, um bucket S3 configurado como site estático, outro registro na mesma hosted zone) como se fosse um registro A/AAAA, mas resolvendo o IP de destino dinamicamente por trás dos panos.

Vantagens práticas:

• Pode ser usado no apex do domínio (leware.com.br direto, sem www.) — resolve exatamente a limitação do CNAME.
• Sem custo de consulta adicional quando aponta para um recurso AWS (diferente de um A record comum ou de um CNAME, que são cobrados por consulta).
• Acompanha automaticamente mudanças de IP do recurso de destino (ex: se o IP por trás de um ALB mudar, o Alias já resolve para o IP correto, sem você precisar atualizar nada).

💡 Regra para a prova: "apontar o domínio raiz (apex) para um ALB/CloudFront/S3" → Alias Record, nunca CNAME. Se a questão menciona "não é possível usar CNAME no domínio raiz", a resposta é sempre Alias.

---

5. Políticas de roteamento (detalhado)

Pense no Route 53 como uma central telefônica que decide para qual servidor "ligar" o usuário, dependendo da regra escolhida.

5.1 Simple

Um único registro, sem lógica de decisão — a resposta padrão é sempre a mesma, sem considerar saúde, peso ou localização. Útil quando não há necessidade de distribuição ou failover.

5.2 Weighted

Distribui tráfego proporcionalmente entre múltiplos endpoints, conforme um peso configurado. Exemplo: peso 90 para a versão estável e peso 10 para uma versão beta — aproximadamente 10% dos usuários são direcionados à versão beta, útil para testes canary.

5.3 Latency

Direciona o usuário para a região AWS que historicamente oferece a menor latência de rede medida — não é a região fisicamente mais próxima, é a que responde mais rápido na prática (às vezes uma região "mais distante" tem rotas de rede melhores).

5.4 Failover

Configura um endpoint primário e um secundário (backup). O Route 53 usa health checks para monitorar o primário — se ele falhar, o tráfego passa automaticamente a ser direcionado ao secundário.

5.5 Geolocation

Direciona tráfego com base na localização geográfica de onde a consulta DNS se origina (país, continente, ou até estado dentro dos EUA). Usado tipicamente para requisitos de conformidade regulatória (ex: "usuários da União Europeia devem ser servidos por servidores dentro da UE") ou para personalizar conteúdo por região.

5.6 Geoproximity

Parecido com Geolocation, mas permite direcionar tráfego com base na localização geográfica do recurso (não só do usuário) e ajustar o "alcance" de uma região através de um parâmetro chamado bias: aumentar o bias de uma região expande a área geográfica de usuários que ela atende; diminuir reduz. Requer o uso do Traffic Flow (uma ferramenta visual do Route 53 para políticas de roteamento complexas). Útil para redistribuir tráfego gradualmente entre regiões sem mover recursos fisicamente.

5.7 Multivalue Answer

Permite retornar múltiplos valores (até 8 registros saudáveis) para uma mesma consulta DNS, cada um opcionalmente associado a um health check — o cliente recebe várias opções de IP e tenta uma delas. Funciona como uma forma simples de balanceamento de carga e redundância no nível de DNS, mas não substitui um load balancer de verdade (não tem a inteligência de distribuição de um ALB/NLB, é só "dar algumas opções e deixar o cliente escolher").

5.8 IP-based Routing

Permite definir regras de roteamento com base em blocos de IP de origem do cliente (CIDR) — por exemplo, direcionar tráfego de um provedor de Internet específico para um endpoint otimizado para aquela rede. Mais granular que Geolocation, que trabalha por região geográfica, não por bloco de rede.

---

6. Health Checks — tipos

• Endpoint health check: o Route 53 verifica periodicamente um endpoint específico (IP ou domínio), checando resposta HTTP/HTTPS/TCP dentro de um intervalo e limite de falhas configurados.
• Calculated health check: combina o resultado de outros health checks (ex: "considere saudável só se pelo menos 2 dos 3 endpoints de uma região estiverem saudáveis") — útil para lógica de saúde agregada de um conjunto de recursos.
• CloudWatch alarm health check: baseia a saúde no estado de um alarme do CloudWatch, permitindo monitorar métricas que não são simples "responde ou não responde" (ex: uma métrica de negócio, uma fila muito cheia).

---

7. TTLs e propagação

• TTL (Time To Live): por quanto tempo um resolver pode guardar em cache a resposta de uma consulta DNS antes de perguntar de novo.
• TTL curto reduz o tempo até uma mudança (ou um failover) ser refletida para os usuários, mas aumenta o volume de consultas — e, consequentemente, custo e carga nos resolvers.
• TTL longo reduz custo e carga, mas atrasa a propagação de qualquer mudança.
• Alguns resolvers de terceiros (fora do seu controle) podem ignorar TTLs muito baixos e manter cache por mais tempo do que o configurado — um risco a considerar em SLAs de failover crítico.

---

8. Boas práticas

• Use Alias Records, não CNAME, para apontar para recursos AWS — especialmente no apex do domínio.
• Use latency routing para usuários globais quando aplicações estiverem em múltiplas regiões.
• Combine health checks com failover para alta disponibilidade automática.
• Configure TTLs balanceando velocidade de failover e volume/custo de consultas.
• Use calculated health checks quando a saúde de um serviço depende de múltiplos componentes agregados.
• Use private hosted zones para nomes internos que não devem ser resolvíveis publicamente.

---

9. Como cai na certificação

• Cenário "apontar domínio raiz (sem www.) para um ALB/CloudFront/S3" → Alias Record, nunca CNAME.
• Cenário "distribuir tráfego por peso, teste canary/A-B" → Weighted.
• Cenário "menor latência de rede para o usuário" → Latency, não Geolocation (que é sobre localização, não velocidade).
• Cenário "primário e backup com troca automática" → Failover + health check.
• Cenário "requisito legal/regulatório de servir usuários de um país/região específica" → Geolocation.
• Cenário "redistribuir tráfego gradualmente entre regiões sem mover infraestrutura" → Geoproximity + Traffic Flow (bias).
• Cenário "retornar múltiplas opções de IP saudáveis para o cliente escolher, sem um load balancer completo" → Multivalue Answer.
• Cenário "saúde calculada com base em múltiplos health checks combinados" → Calculated health check.
• Cenário "nomes DNS internos, não resolvíveis fora da VPC" → Private hosted zone.

---

10. Exercícios práticos conceituais

1. Projete uma configuração de DNS com failover entre duas regiões usando health checks.
2. Compare Weighted vs Latency routing e cite quando usar cada um.
3. Avalie o impacto de reduzir TTL de 300s para 30s em um serviço crítico.
4. Explique quando utilizar Geolocation routing para conformidade/regulação.
5. Explique por que um CNAME não pode ser usado no domínio raiz e como o Alias Record resolve esse problema, sem custo extra de consulta.
6. Desenhe um cenário onde Multivalue Answer é suficiente, e outro onde seria necessário um ALB de verdade em vez dele.

---

11. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Laboratório Prático

Objetivo: configurar uma hosted zone com um Alias Record apontando para um ALB, e um failover básico com health check.

Pré-requisitos: um domínio já registrado (pode ser um domínio de teste) e um Application Load Balancer já criado.

Tempo estimado: 20 minutos

Possíveis custos: hosted zone tem cobrança mensal fixa baixa; health checks têm custo pequeno por check ativo — lembre-se de limpar ao final se for ambiente de teste.

Passos:

1. Crie uma public hosted zone para o domínio de teste.
2. Crie um registro do tipo Alias, apontando o domínio raiz para o DNS do ALB criado previamente.
3. Acesse o domínio no navegador e confirme que o tráfego chega ao ALB.
4. Crie um health check de endpoint apontando para o mesmo ALB, monitorando o caminho /health.
5. Crie um segundo registro (ex: um segundo ALB de teste, ou uma instância simples) como endpoint de backup.
6. Configure uma política de Failover: o registro do ALB principal como primário (associado ao health check), o segundo como secundário.
7. Simule uma falha (ex: pare temporariamente o serviço por trás do ALB principal, ou ajuste o health check para falhar propositalmente) e observe, após o TTL expirar, o tráfego passando a resolver para o endpoint secundário.

Resultado esperado: o domínio raiz resolve corretamente via Alias sem custo extra, e o failover automático troca o destino quando o health check detecta falha no primário.

Limpeza dos recursos: delete os registros criados, o health check, e a hosted zone (se for um domínio de teste que não precisa mais do Route 53).

---

Referências:

• Route 53 Developer Guide: https://docs.aws.amazon.com/Route53/
• Políticas de roteamento: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
• Alias Records: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
• Health Checks: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html