Verificações de integridade e failover do DNS

As verificações de integridade do Route 53 monitoram continuamente a integridade dos seus endpoints — servidores Web, balanceadores de carga ou qualquer endpoint HTTP/HTTPS/TCP acessível pela Internet. Com base nos resultados das verificações de integridade, o Route 53 pode atualizar automaticamente o roteamento de DNS para evitar o envio de tráfego para recursos não íntegros.

As verificações de integridade são cobradas por verificação, mensalmente. Os verificadores globais de integridade do Route 53 (localizados em várias Regiões) sondam seu endpoint simultaneamente, proporcionando redundância no próprio processo de verificação. Um endpoint só é considerado não íntegro quando um número limite de verificadores concorda que ele falhou.

As verificações de integridade de endpoints monitoram um endereço IP ou nome de domínio específico usando o protocolo escolhido (HTTP, HTTPS ou TCP), a porta e um caminho opcional. Para verificações HTTP/HTTPS, o Route 53 confirma que o endpoint retorna um código de status HTTP 2xx ou 3xx dentro do período de tempo limite. Para verificações HTTPS, ele também pode validar o certificado TLS.

Principais opções de configuração: intervalo entre solicitações (10 ou 30 segundos — 10 segundos permitem uma detecção mais rápida, mas custam mais), limite de falhas (1 a 10 falhas consecutivas antes de marcar o endpoint como não íntegro) e correspondência de texto (opcionalmente, verifica se o corpo da resposta contém um texto específico).

As verificações de integridade calculadas combinam os resultados de várias verificações de integridade filhas usando lógica booleana (AND, OR, NOT). Elas permitem definir a integridade de uma aplicação com base em vários sinais, sem criar cadeias complexas de roteamento.

Exemplo: uma aplicação Web só está íntegra se tanto a verificação do servidor de API quanto a verificação do banco de dados forem aprovadas. Crie uma verificação de integridade calculada com o tipo AND que faça referência às duas verificações de endpoint. Se qualquer uma falhar, a verificação de integridade calculada falhará, e o Route 53 removerá dos resultados o registro de DNS associado.

As verificações de integridade baseadas em alarmes do CloudWatch vinculam uma verificação de integridade do Route 53 ao estado de um alarme do CloudWatch. Se o alarme estiver no estado ALARM, a verificação de integridade será marcada como não íntegra; se estiver em OK ou INSUFFICIENT_DATA, será marcada como íntegra.

Esse padrão é poderoso para endpoints dentro de uma VPC (que não podem ser acessados pelos verificadores externos de integridade do Route 53). Em vez de sondar o endpoint privado, você cria métricas e alarmes do CloudWatch para ele e, então, baseia a verificação de integridade do Route 53 no estado do alarme. Isso também permite verificar a integridade com base em métricas de negócio, como taxa de erros ou profundidade da fila.

Os verificadores de integridade do Route 53 são servidores gerenciados pela AWS, localizados fora da sua VPC, que acessam endpoints pela Internet pública. Os recursos em sub-redes privadas não podem ser alcançados pelas verificações padrão de integridade de endpoints. Para endpoints privados, use uma destas abordagens:

• Publique uma métrica personalizada do CloudWatch de dentro da VPC (por exemplo, um sinal de sucesso ou falha da aplicação), crie um alarme e use uma verificação de integridade baseada em alarme do CloudWatch
• Use um alarme composto do CloudWatch que agregue métricas do ELB, do RDS ou da aplicação dentro da VPC

Esse padrão é essencial para bancos de dados em sub-redes privadas, balanceadores de carga internos e serviços de backend.

Você pode visualizar o status das verificações de integridade no console do Route 53, em Health Checks, ou consultá-lo por meio da API. O Route 53 publica métricas das verificações de integridade no CloudWatch, no namespace AWS/Route53, incluindo HealthCheckStatus (1 = íntegro, 0 = não íntegro) e HealthCheckPercentageHealthy (porcentagem de verificadores do Route 53 que informam que o endpoint está íntegro).

Configure alarmes do CloudWatch em HealthCheckStatus para receber notificações do SNS quando um endpoint deixar de estar íntegro. Assim, você terá visibilidade antes que sua equipe de plantão perceba que o failover de DNS já ocorreu.

Quando o Route 53 detecta que a verificação de integridade de um registro Primário falhou, ele remove o Primário das respostas de DNS e retorna o endereço do Secundário. Isso é chamado de failover de DNS. A alternância ocorre dentro do período de avaliação (número de falhas dos verificadores de integridade × intervalo entre solicitações), somado ao TTL do registro.

Exemplo: intervalo entre solicitações = 30 s, limite de falhas = 3, TTL = 60 s. O tempo máximo de failover é aproximadamente 3 × 30 + 60 = 150 segundos. Definir um TTL menor (por exemplo, 10 segundos) e um intervalo de verificação de integridade mais rápido (10 s) pode reduzir esse tempo para 3 × 10 + 10 = 40 segundos.

As verificações de integridade também podem ser associadas a registros ponderados e de latência, não apenas a registros de failover. Quando a verificação de integridade de um registro ponderado falha, o Route 53 redistribui proporcionalmente o peso do tráfego desse registro entre os registros ponderados íntegros. Quando a verificação de integridade de um registro de latência falha, o Route 53 direciona as consultas para o próximo registro íntegro com menor latência.

Isso torna as políticas de roteamento ponderado e de latência resilientes a falhas de endpoints, sem exigir registros de failover explícitos. Este é um padrão comum do SAA-C03: o roteamento por latência entre Regiões, com verificações de integridade, oferece otimização de desempenho e recuperação automática de desastres.

Um padrão resiliente ativo-ativo em várias Regiões usando o Route 53:

1. Crie registros de latência para cada Região (us-east-1, eu-west-1, ap-southeast-1), cada um com uma verificação de integridade
2. Quando todas as Regiões estiverem íntegras, os usuários serão direcionados para a Região com menor latência
3. Se a verificação de integridade de uma Região falhar (a aplicação estiver indisponível ou não responder), o Route 53 a removerá automaticamente das respostas de DNS e direcionará as consultas para a próxima Região íntegra mais adequada
4. Quando a Região com falha se recuperar, a verificação de integridade será aprovada e o Route 53 a reincluirá na rotação

Isso proporciona failover global automático com otimização de desempenho, sem necessidade de intervenção manual.

Os verificadores de integridade do Route 53 se originam de um conjunto de intervalos de IP publicados na seção ROUTE53_HEALTHCHECKS do arquivo JSON de intervalos de IP da AWS. Se o seu endpoint estiver protegido por um firewall ou grupo de segurança que restrinja o acesso de entrada, você deverá permitir tráfego proveniente desses intervalos de IP para que as verificações de integridade sejam bem-sucedidas.

Como alternativa, use um endpoint público que funcione como proxy para o seu backend privado (como um ALB) durante a verificação de integridade. O grupo de segurança do ALB só precisa permitir os intervalos de IP do Route 53, enquanto o grupo de segurança do backend permite apenas o grupo de segurança do ALB, mantendo uma abordagem de defesa em profundidade.

Práticas recomendadas para verificações de integridade do Route 53:

• Crie um endpoint /health dedicado que verifique todas as dependências críticas (conectividade com o banco de dados e acessibilidade do cache) e retorne 200 somente quando estiver totalmente operacional
• Use um intervalo entre solicitações de 10 segundos para endpoints críticos de produção, a fim de detectar falhas mais rapidamente
• Monitore HealthCheckPercentageHealthy no CloudWatch — uma falha parcial (quando alguns, mas não todos, os verificadores do Route 53 falham) pode indicar um problema de rede regional ou intermitente
• Para recursos privados da VPC, use verificações de integridade baseadas em alarmes do CloudWatch, fundamentadas em métricas da aplicação
• Teste o failover em ambientes que não sejam de produção antes de confiar nele em produção

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) abordados nesta lição.

Nesta lição, você aprendeu: as verificações de integridade de endpoints sondam HTTP/HTTPS/TCP a partir de verificadores externos do Route 53; as verificações de integridade baseadas em alarmes do CloudWatch permitem monitorar recursos privados da VPC; e as verificações de integridade calculadas combinam vários sinais usando lógica booleana. A velocidade do failover de DNS depende do intervalo da verificação de integridade, do limite de falhas e do TTL. A seguir, exploraremos as distribuições e as origens do CloudFront.