Roteamento de failover e por geolocalização

O roteamento Failover implementa uma configuração ativa-passiva: um registro é designado como Primary e outro como Secondary. O Route 53 sempre retorna o registro Primary enquanto sua verificação de integridade for bem-sucedida. Se o Primary ficar sem integridade, o Route 53 mudará automaticamente para o retorno do registro Secondary.

O roteamento Failover é o padrão ideal para cenários de recuperação de desastres nos quais existe um ambiente de produção (primário) e um ambiente de espera (secundário), que só deve receber tráfego quando o primário estiver indisponível.

Para configurar o roteamento Failover, crie dois registros com o mesmo nome DNS: um com Failover=PRIMARY e outro com Failover=SECONDARY. Anexe uma verificação de integridade ao registro Primary. O registro Secondary também deve ter uma verificação de integridade se apontar para um recurso que possa falhar de forma independente.

O registro Secondary atua como um fallback estático: pode apontar para um site estático do S3, uma página de manutenção ou um ambiente de espera reduzido. Mesmo que o Secondary não tenha uma verificação de integridade, o Route 53 sempre recorrerá a ele quando o Primary falhar.

O roteamento Failover cria uma configuração ativa-passiva: apenas o Primary atende ao tráfego durante a operação normal; o Secondary permanece ocioso, aguardando para assumir. Isso minimiza o custo do ambiente de espera, mas resulta em um tempo de recuperação um pouco maior (o tempo necessário para o TTL do DNS expirar e o Route 53 alternar).

Para configurações ativas-ativas (nas quais ambos os recursos atendem ao tráfego simultaneamente), use o roteamento ponderado (com pesos iguais) ou o roteamento por latência. Se um recurso falhar, sua verificação de integridade falhará e o Route 53 o removerá automaticamente das respostas DNS — obtendo uma configuração ativa-ativa com Failover integrado.

O roteamento por geolocalização roteia consultas DNS com base na localização geográfica do resolvedor DNS (normalmente o resolvedor do ISP do usuário ou o Route 53 Resolver da AWS). Você cria registros para continentes, países ou estados específicos dos US, e o Route 53 retorna o registro cuja localização corresponda de forma mais específica à origem da consulta.

Se nenhum registro de localização específica corresponder, o Route 53 retornará um registro padrão (se estiver configurado). Sem um registro padrão, as consultas de locais sem correspondência receberão NODATA. Sempre crie um registro padrão para atender aos usuários de locais que não foram configurados explicitamente.

Principais casos de uso do roteamento por geolocalização:

• Conteúdo específico por idioma: encaminhar falantes de francês para uma origem de CDN em francês e falantes de alemão para uma origem em alemão
• Conformidade regulatória: garantir que os dados de usuários da EU permaneçam em Regiões da EU (GDPR) ou bloquear o acesso de países específicos
• Preços ou disponibilidade localizados: exibir preços específicos por região ou restringir serviços a territórios compatíveis
• Bloqueio geográfico: retornar uma página de bloqueio ou uma resposta vazia para usuários de locais restritos, apontando o registro de geolocalização deles para um endpoint de manutenção

O Route 53 corresponde à geolocalização mais específica: um registro no nível de estado tem precedência sobre um registro no nível de país, que tem precedência sobre um registro no nível de continente, que tem precedência sobre o padrão. A geolocalização no nível de estado dos US está disponível apenas para os Estados Unidos.

Se você não incluir um registro padrão e a localização de um usuário não corresponder a nenhum registro configurado, o Route 53 retornará NXDOMAIN ou NODATA — interrompendo silenciosamente o acesso de usuários em regiões não configuradas. Sempre adicione um registro padrão de geolocalização como captura geral para evitar falhas silenciosas.

O roteamento por geoproximidade roteia o tráfego com base na distância geográfica física entre usuários e recursos, com um viés opcional para expandir ou reduzir o raio efetivo de roteamento de cada recurso. Um viés positivo expande a área geográfica atendida por um recurso; um viés negativo a reduz.

A geoproximidade só está disponível por meio do Traffic Flow (o editor visual de políticas de roteamento do Route 53) e é compatível tanto com Regiões da AWS (cujas coordenadas o Route 53 conhece automaticamente) quanto com locais de recursos personalizados, para os quais você fornece latitude e longitude.

O Route 53 Traffic Flow é um editor visual de políticas que permite criar lógicas de roteamento complexas combinando várias políticas de roteamento em um diagrama semelhante a uma árvore. Por exemplo, você pode primeiro aplicar a geolocalização para separar o tráfego da EU, depois aplicar a latência dentro da EU para escolher a Região com melhor desempenho e, por fim, usar o roteamento ponderado dentro de cada Região para implantações azul-verde.

As políticas do Traffic Flow são versionadas, permitindo testar alterações com segurança. Você associa uma política do Traffic Flow a um ou mais nomes DNS, e as atualizações da política são propagadas instantaneamente, sem recriar registros individuais.

O roteamento Failover pode ser aninhado em outras políticas. Um padrão comum é usar o roteamento por latência para escolher a Região mais próxima, mas usar um registro Failover dentro de cada Região para que, se o endpoint primário dessa Região falhar, o tráfego seja automaticamente transferido para um endpoint secundário na mesma Região.

Outro padrão é o ativo-passivo em várias Regiões, usando o roteamento por latência para o endpoint primário. Se a verificação de integridade da Região primária falhar, o Route 53 passará para a próxima Região íntegra com menor latência — combinando, na prática, a otimização de latência com o Failover de DR.

Para que o roteamento Failover funcione corretamente, o registro Primary deve** ter uma verificação de integridade anexada. Sem uma verificação de integridade, o Route 53 considera o Primary sempre íntegro e nunca alterna para o Secondary. O registro Secondary pode opcionalmente ter sua própria verificação de integridade; se o Secondary também falhar, o Route 53 retornará mesmo assim o endereço do Secondary (ele é o último recurso).

Tipos de verificação de integridade que você pode usar com Failover: verificações de endpoints HTTP/HTTPS, verificações TCP e verificações de alarmes do CloudWatch (úteis para sinais compostos de integridade da aplicação que combinam várias métricas).

Essa distinção aparece com frequência no exame SAA-C03:

• Geolocalização: roteia de acordo com o local geográfico do usuário — sempre retorna o mesmo endpoint para determinado país/continente, independentemente do desempenho; usada para localização de conteúdo e conformidade
• Latência: roteia de acordo com o desempenho da rede para o usuário — pode encaminhar um usuário na Europa para us-east-1 se, naquele momento, for mais rápido que eu-west-1; usada para otimização do desempenho

Palavras-chave nas questões do exame: 'cumprir os requisitos de residência de dados', 'conteúdo específico por país', 'bloquear usuários de determinadas regiões' → Geolocalização. 'Região mais próxima', 'menor latência', 'melhor desempenho para usuários globais' → Latência.

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

Nesta lição, você aprendeu: o roteamento de failover cria HA ativo-passivo ao alternar para o Secundário quando a verificação de integridade do Primário falha; o roteamento por geolocalização direciona os usuários com base na origem geográfica para atender a requisitos de conformidade e localização; e o roteamento por proximidade geográfica usa a distância física com um viés configurável por meio do Traffic Flow. Sempre adicione um registro de geolocalização padrão para lidar com localizações não correspondentes. A seguir, exploraremos em profundidade as verificações de integridade e o failover de DNS.