Amazon ANS-C01: DNS e Route 53 — Guia de estudos

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Faz parte do AWS Advanced Networking Specialty ANS-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Conceito principal

O DNS é a cola entre nomes amigáveis para humanos e endpoints distribuídos, mas na AWS ele se torna um plano de controle ativo para roteamento baseado em latência, failover ciente do estado de saúde e resolução de nomes privados entre contas. O Amazon Route 53 suporta DNS público autoritativo por meio de zonas hospedadas públicas e DNS privado para resolução no escopo da VPC por meio de zonas hospedadas privadas. As zonas hospedadas privadas são associadas a uma ou mais VPCs e retornam respostas apenas para consultas originadas dessas VPCs ou por meio de endpoints de entrada (inbound) do Route 53 Resolver. Esse comportamento de split-horizon — ter respostas diferentes para o mesmo nome dependendo da origem — permite que você exponha um endpoint público para clientes da internet enquanto resolve o mesmo nome para IPs privados dentro de suas VPCs.

O Route 53 também integra lógica de decisão de roteamento e verificações de saúde (health checks) ativas ao DNS. As políticas de roteamento incluem Simples, Ponderada (Weighted), Latência, Failover (primário/secundário), Geolocalização e Resposta com Múltiplos Valores (Multi-Value Answer), e Fluxo de Tráfego (Traffic Flow) (geoproximidade e fluxos complexos). As verificações de saúde criadas com CreateHealthCheck permitem que o Route 53 remova endpoints não saudáveis das respostas DNS ou acione conjuntos de registros de failover; as verificações de saúde são configuráveis com campos de HealthCheckConfig como Type, FullyQualifiedDomainName, IPAddress, Port, ResourcePath, RequestInterval e FailureThreshold. Como o DNS é armazenado em cache por resolvedores e clientes, o TTL do Route 53 e a sondagem frequente das verificações de saúde (mínimo de 10 segundos em configurações específicas) devem ser balanceados com o comportamento de propagação de DNS para alterações de failover e roteamento ponderado.

Principais serviços e configuração

Ao expor recursos da AWS, use registros do tipo Alias para apontar o DNS diretamente para os recursos da AWS onde for suportado, evitando saltos (hops) adicionais ou CNAMEs. Registros do tipo Alias usam um AliasTarget que referencia o ID da zona hospedada e o nome DNS do recurso da AWS (por exemplo, um Elastic Load Balancer, um domínio personalizado do API Gateway, uma distribuição do CloudFront ou um endpoint de site do S3). A criação ou alteração de registros é feita por meio da API ChangeResourceRecordSets; para fluxos de trabalho programáticos, use ChangeBatch com ações UPSERT/DELETE e SetIdentifier para identificação da política de roteamento. Para failover, você cria dois registros com o mesmo nome e com o campo Failover definido como PRIMARY e SECONDARY, cada um referenciando uma verificação de saúde por meio do HealthCheckId que você cria com CreateHealthCheck.

Para resolução de DNS entre contas e híbrida, o Route 53 Resolver fornece endpoints de entrada (inbound) e de saída (outbound) criados com CreateResolverEndpoint. Um endpoint de entrada permite que resolvedores on-premises encaminhem consultas para dentro das VPCs (útil para resolver zonas hospedadas privadas), enquanto um endpoint de saída permite que recursos da VPC encaminhem consultas para servidores DNS on-premises ou outros resolvedores. As regras do Resolver (CreateResolverRule) permitem encaminhar consultas para domínios específicos para endereços IP, e você associa as regras às VPCs usando AssociateResolverRule. Para uma arquitetura de DNS centralizada, você pode criar regras de encaminhamento em uma conta central e usar AssociateResolverRule com VPCs em outras contas, opcionalmente usando o AWS Resource Access Manager (RAM) e PutResolverRulePolicy para controlar as associações.

O Route 53 Resolver DNS Firewall oferece filtragem e registro de logs baseados em domínio. Você cria listas de domínios com CreateFirewallDomainList, grupos de regras com CreateFirewallRuleGroup e, em seguida, associa o grupo de regras às VPCs com AssociateFirewallRuleGroup para aplicar as regras. As regras de firewall podem ter ações de BLOCK, ALLOW ou OVERWRITE (sobrescrever) as respostas, e você pode registrar as avaliações no CloudWatch Logs ou no S3. Use CreateFirewallRule e PutFirewallRuleGroupPolicy para gerenciamento e para aplicar regras priorizadas, especialmente para limitar a exfiltração de dados via DNS ou para bloquear domínios maliciosos de recursos anexados à VPC.

Padrões de design e trade-offs

Para serviços de alta disponibilidade e distribuídos globalmente, use roteamento baseado em latência ou geográfico para direcionar os clientes ao endpoint saudável mais próximo, combinado com verificações de saúde para remover endpoints regionais não saudáveis. O roteamento por latência depende das tabelas de latência regionais do Route 53 e é adequado para projetos ativo-ativo multirregionais; o roteamento de failover é melhor para recuperação de desastres (disaster recovery) ativo-passivo, onde apenas uma região deve receber tráfego por vez. O roteamento ponderado (weighted) suporta desvios graduais de tráfego (deployments blue-green ou canary), atribuindo valores de peso aos registros e alterando-os com ChangeResourceRecordSets. O roteamento de resposta com múltiplos valores pode retornar múltiplos IPs para distribuição de carga do lado do cliente e requer verificações de saúde para garantir que apenas IPs saudáveis sejam retornados.

Zonas hospedadas privadas e endpoints do resolver são os padrões canônicos para resolução de nomes entre múltiplas contas e múltiplas VPCs. Para muitas unidades de negócio, uma VPC central de serviços compartilhados que hospeda zonas hospedadas privadas ou endpoints do resolver simplifica o gerenciamento: crie uma zona hospedada privada e use AssociateVPCWithHostedZone para anexar as VPCs de serviço, ou execute endpoints de saída/entrada do Route 53 Resolver e regras de encaminhamento para que cada conta mantenha seu isolamento de VPC enquanto depende de uma política de DNS central. O trade-off é que zonas hospedadas privadas associadas a muitas VPCs complicam o IAM e o controle de alterações, e as associações entre contas exigem uma etapa de autorização. O encaminhamento do Resolver introduz uma sobrecarga operacional central, mas escala bem porque você não precisa associar cada VPC diretamente a cada zona hospedada; em vez disso, você associa regras do resolver.

Ao impor caminhos de acesso estritos — como exigir que o tráfego flua apenas pelo Global Accelerator — você deve projetar os security groups e os controles de rede para corresponder ao DNS. O Route 53 pode apontar para o Global Accelerator criando registros do tipo A com os endereços IP estáticos do acelerador ou usando CNAMEs para um domínio gerenciado pelo acelerador, mas a aplicação da regra é feita na camada do security group do ALB e da network ACL. O security group do ALB deve permitir tráfego de entrada (ingress) apenas dos endereços IP estáticos do Global Accelerator; o Global Accelerator garante que esses IPs estáticos serão a origem do tráfego de entrada, portanto, limitar o tráfego de entrada preserva o requisito de acesso exclusivo pelo acelerador.

Armadilhas comuns e critérios de decisão

Uma armadilha comum é presumir que as verificações de saúde (health checks) do Route 53 removem endpoints instantaneamente; o cache de DNS (TTL) e o comportamento do resolver do cliente significam que o failover não é instantâneo. Mantenha TTLs baixos para nomes de failover críticos, mas lembre-se de que TTLs mais baixos aumentam o volume de consultas e o custo. Outro erro comum é duplicar nomes entre zonas hospedadas (hosted zones) públicas e privadas sem entender as associações de VPC: uma zona hospedada privada com o mesmo nome de uma zona hospedada pública irá sobrepor as respostas públicas para consultas originadas nas VPCs associadas, o que geralmente é desejável para split-horizon, mas pode ser surpreendente se não for documentado.

Escolha cuidadosamente entre registros Alias e CNAME: registros Alias para ELB e CloudFront são preferíveis porque evitam buscas (lookups) de DNS extras e são suportados pela lógica de propagação de alterações do Route 53, mas estão vinculados aos IDs de zona hospedada (hosted zone IDs) de recursos da AWS e não podem ser usados para endpoints externos arbitrários. Ao projetar DNS entre contas (cross-account), prefira regras de resolver (resolver rules) e endpoints em vez de associar diretamente muitas VPCs a uma única zona hospedada privada quando a escala ou os limites administrativos são uma preocupação; as regras de resolver oferecem um controle mais granular e são mais fáceis de auditar com o CloudTrail.

Problema Prático: Cenário de Caso de Uso

Empresa: NimbusPay — desafio: Fornecer serviços gRPC seguros e de baixa latência sobre TLS com TLS mútuo para um backend EKS, impor o acesso ao front-end da web apenas via Global Accelerator e permitir que VPCs de várias unidades de negócio em diferentes contas consumam serviços de dados compartilhados com controles de DNS centralizados.

Para o serviço gRPC que exige TLS de ponta a ponta (end-to-end) com autenticação mútua e milhares de conexões simultâneas, implante um Network Load Balancer (NLB) com listeners TCP na porta 443 usando o tipo de destino (target type) ip para que os IPs dos pods sejam registrados diretamente. Configure as anotações (annotations) do AWS Load Balancer Controller service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" e defina o protocolo do grupo de destino (target group) como TCP; não termine o TLS no NLB (sem listener TLS) para que o TLS mútuo seja repassado (passed through) para os contêineres dos pods, onde os certificados do servidor e a verificação do certificado do cliente são aplicados. Use registros A (Alias) do Route 53 apontando para o NLB via ChangeResourceRecordSets; prefira TTLs baixos apenas se precisar de failover rápido, caso contrário, mantenha um TTL conservador para a estabilidade do DNS.
Para garantir que o ALB do front-end da web aceite tráfego apenas do Global Accelerator, provisione um acelerador e atribua seus dois endereços IP estáticos à NimbusPay. Configure registros públicos do Route 53 para resolver o nome público para os IPs do acelerador (registros A com os IPs estáticos). No ALB, defina as regras de entrada (ingress rules) do security group para permitir apenas esses endereços IP estáticos e feche o acesso de 0.0.0.0/0. Isso garante que apenas o tráfego vindo dos IPs estáticos do acelerador possa alcançar o ALB. Use o CloudWatch Logs e o VPC Flow Logs para validar os IPs de origem e auditar que o tráfego que não vem do acelerador está sendo bloqueado.
Para várias VPCs de unidades de negócio em diferentes contas que precisam de acesso a serviços compartilhados, implante um par de endpoints de saída/entrada (outbound/inbound) do Route 53 Resolver na conta de serviços compartilhados usando CreateResolverEndpoint e posicione os endpoints em sub-redes privadas. Crie regras de encaminhamento (forwarding rules) (CreateResolverRule) na conta compartilhada para os domínios de serviço compartilhado e compartilhe (Share) as regras usando o AWS RAM ou use PutResolverRulePolicy para permitir associações. Cada unidade de negócio associa a regra do resolver às suas VPCs (AssociateResolverRule), permitindo a resolução de nomes sem anexar diretamente todas as VPCs às zonas hospedadas privadas. Para controles sensíveis, anexe grupos de regras do Route 53 Resolver DNS Firewall (CreateFirewallRuleGroup e AssociateFirewallRuleGroup) à VPC compartilhada para bloquear exfiltração indesejada de dados ou para impor listas de permissão de domínios (domain allowlists). A justificativa: O passthrough TCP do NLB preserva o TLS mútuo e escala para muitas conexões simultâneas, restringir a entrada (ingress) do ALB aos IPs estáticos do Global Accelerator impõe o acesso exclusivo via acelerador, e os endpoints de resolver com regras gerenciadas centralmente escalam a resolução de DNS entre contas, preservando os limites de IAM e a auditoria por conta.