O blog da AWS

Gerenciamento de DNS centralizado da nuvem híbrida com o Amazon Route 53 e o AWS Transit Gateway

Uma estratégia de rede híbrida bem-sucedida vai além da conectividade com a rede privada. Normalmente é necessário lidar com zonas de DNS distintas na Amazon Virtual Private Cloud (Amazon VPC) e on-premises. Essa estratégia necessita de resolução de nomes (DNS) que abranja toda a rede. Normalmente, isso é gerenciado com o fornecimento de servidores DNS no mesmo local em que os recursos e workloads estão localizados. Por exemplo, a infraestrutura de DNS on-premises  resolve a consultas a recursos on-premises, e o DNS da VPC resolve consultas a recursos na Nuvem AWS. Para obter uma visão unificada do DNS de toda essa rede híbrida que seus aplicativos exigem, você pode precisar configurar o encaminhamento de consultas bidirecional. Assim é possível consultar zonas de DNS internas on-premises a partir das Amazon VPCs, bem como consultar zonas privadas de DNS via Route53 Resolver a partir de data centers on-premises.

A AWS lançou o Amazon Route 53 Resolver para nuvens híbridas em novembro de 2018. Ele facilita a migração para arquiteturas híbridas e de nuvem, resolvendo muitos desafios de DNS. Talvez esses desafios não fiquem evidentes ao planejar pela primeira vez sua jornada na nuvem, mas eles surgem com frequência no meio de uma migração e podem atrasar seus desenvolvedores.

Muitos de vocês têm sua infraestrutura distribuída em várias contas e VPCs, sendo que cada VPC possui vários domínios e zonas privadas de DNS. A integração do DNS entre contas AWS e servidores DNS on-premises pode se tornar complexa. Você precisará de um gerenciamento simples de DNS recursivo nas contas das várias VPCs por meio de um conjunto unificado de regras e um único Route 53 Resolver. Atualmente isso é possível ao centralizar o gerenciamento de DNS para todos as VPCs e domínios on-premises.

Este blog analisará as melhores práticas e trade-offs a considerar ao projetar o DNS gerenciado de forma central. De maneira geral, descreveremos a abordagem recomendada para o gerenciamento de DNS para várias Amazon VPCs interconectadas.

Visão única do DNS para redes on-premises e Amazon VPCs

Nessa situação, você tem uma infraestrutura existente de servidores DNS on-premises que são autoritativos para resolver nomes de domínio locais. Você também tem várias VPCs em várias contas na AWS com domínios e zonas privadas de DNS associadas a essas VPCs. As Amazon VPCs são interconectadas usando a topologia de hub e spoke por meio do Transit Gateway.

Para simplificar o DNS em todo esse ambiente híbrido, você pode implementar um DNS gerenciado centralmente que pode resolver nomes de DNS entre seu data center on-premises e as VPCs.

As regras de encaminhamento e os endpoints do Route 53 Resolver são projetados principalmente para oferecer DNS integrado para redes híbridas em que o encaminhamento em tempo real de consultas de DNS muitas vezes é inevitável. Esses novos recursos permitem que o  Route 53 Resolver e seus servidores de DNS on-premises resolvam os domínios hospedados pelo outro, encaminhando as consultas entre si em tempo real.

Compartilhando endpoints de PrivateLink entre Amazon VPCs

Nesta configuração, você está usando o AWS PrivateLink para acessar com segurança os serviços da AWS através de conexão privada de VPCs e servidores on-premises. Você precisa de endpoints de interface que sirvam como pontos de entrada para o tráfego destinado aos serviços da AWS com tecnologia AWS PrivateLink. Você pode configurar os endpoints de interface em cada VPC para acessar os serviços da AWS, mas será cobrado por cada hora em que seu endpoint permanecer provisionado em cada zona de disponibilidade. Para reduzir custos e simplificar a sobrecarga administrativa do gerenciamento de endpoints da interface em cada VPC, você pode criar os endpoints do PrivateLink em uma VPC de serviços compartilhados e compartilhá-los com outras VPCs. Analisaremos os detalhes de como projetar a melhor resolução de DNS em VPCs para o PrivateLink centralizado.

Com a introdução do serviço Route 53 Resolver, você pode atingir as seguintes metas de arquitetura:

  1. Você pode usar um serviço totalmente gerenciado, no qual a AWS faz o trabalho pesado e indiferenciado de disponibilidade e confiabilidade.
  2. O serviço preserva o isolamento das Zona de disponibilidade e respostas locais por Zona de Disponibilidade.
  3. Os endpoints de entrada e saída suportam 10 mil consultas por segundo por endereço IP em um endpoint. Você precisa somente consultar os endpoints para o tráfego encaminhado.
  4. O serviço fornece métricas de volume de consulta no Amazon CloudWatch, que permite definir alarmes.

Agora vamos conhecer algumas das melhores práticas para o Route 53 Resolver:

  1. Recomendamos que instâncias do Amazon EC2 usem .2 para a resolução de DNS, o que dá a cada instância EC2 um máximo de 1.024 pacotes por segundo (pps) por interface de rede e preserva o isolamento da Zona de disponibilidade.
  2. É preciso garantir que os servidores de DNS nas opções de DHCP apontem para o AmazonProvidedDNS em vez de apontar para os endpoints do resolvedor. Use as regras de encaminhamento para garantir que o AmazonProvidedDNS tenha a visão do DNS que necessite.
  3. Os endpoints do resolvedor são projetados para integrar o Route 53 Resolver com o DNS on-premises.
  4. A resolução de DNS é crítica para quase todas as aplicações, assim, recomendamos sempre projetar buscando confiabilidade. O encaminhamento de consultas acrescenta complexidade adicional à resolução de DNS em tempo real, portanto, a melhor prática é usá-lo somente quando necessário.
  5. Embora seja possível usar regras de encaminhamento para resolver zonas privadas em outras VPCs, não é recomendável. A abordagem mais confiável, eficiente e de baixo custo é compartilhar e associar as zonas privadas do Route53 diretamente com todas as VPCs que precisam delas.

Vamos nos aprofundar em alguns exemplos de configuração e definição de design para DNS gerenciados centralmente usando o Route 53 Resolver.

 

Visão única do DNS para redes on-premises e Amazon VPCs

Nesta configuração, você deseja que recursos on-premises resolvam nomes das zonas privada do Route 53 em várias contas. Nesta configuração de arquitetura, você usará uma VPC de serviços compartilhados para fazer isso. Ao mesmo tempo, você também deseja encaminhar condicionalmente consultas das VPCs para domínios on-premises para o servidor de DNS on-premises. Essas VPCs são interconectadas usando uma topologia de hub e spoke. Cada um dos VPCs spoke pertence a uma conta diferente e são gerenciados por suas respectivas contas.

Quando for necessário resolver uma zona privada do Route 53 em várias VPCs e contas da AWS, como descrito anteriormente, o padrão mais confiável é compartilhar a zona hospedada privada entre as contas e associá-la a cada VPC que precisar dela. Embora seja possível usar o encaminhamento do Resolvedor do Route 53 para solucionar esse caso de uso, isso gera custos adicionais, complexidade e possíveis dependências da zona de inter-disponibilidade, algo que a associação direta evita.

O diagrama a seguir mostra a arquitetura desta configuração.

Para criar esta configuração, siga essas etapas gerais.

  1. Estabeleça a conectividade de rede.

2. Configure os endpoints do Route 53 Resolver.

  • Crie um endpoint de entrada. Recomendamos que você configure os endereços IP em pelo menos duas Zonas de disponibilidade para alta disponibilidade na VPC de serviços compartilhados.
  • Crie um endpoint de saída. Recomendamos que você configure os endereços IP em pelo menos duas Zonas de disponibilidade para alta disponibilidade no VPC de serviços compartilhados.

3. Crie as zonas privadas de DNS.

  • Crie e associe as zonas privadas do Route 53 na VPC de serviços compartilhados. Além disso, preencha a associação entre contas VPC – zona privada das VPCs spoke, pois as VPCs spoke estão em contas diferentes. Todas as VPCs precisam associar suas zonas privadas a todos as outras VPCs, se necessário.

4. Crie as regras de encaminhamento.

  • Crie as regras de encaminhamento condicional que especificam os nomes de domínio on-premises das consultas DNS que você deseja encaminhar para os servidores de DNS on-premises.Exemplo: uma regra com nome de domínio “onprem.mydc.com” encaminhará todas as consultas por onprem.mydc.com e seus subdomínios.
  • Ao configurar a regra de tráfego de saída, defina as VPCs que usarão essa regra como serviço compartilhado.
  • Se as VPCs spoke estiverem na mesma conta que a VPC de serviços compartilhados, você poderá escolher várias VPCs como as VPCs que usam essa regra no momento da criação da regra de saída ou ao associar as VPCs à regra após a criação.

5. Compartilhe as regras de encaminhamento com outras contas AWS e use regras compartilhadas.

  • Nessa configuração em que as VPCs spoke estão em contas diferentes, você pode compartilhar as regras de encaminhamento com as VPCs de outras contas da AWS usando as regras compartilhadas por meio do AWS Resource Access Manager (AWS RAM). A captura de tela a seguir mostra as regras do resolvedor de encaminhamento compartilhadas com VPCs para várias contas usando o AWS RAM:

 

Compartilhando endpoints de PrivateLink entre VPCs

A configuração a seguir é geralmente complementar à visão única de DNS descrita anteriormente. Nesta configuração, você deseja centralizar o PrivateLink para acessar com segurança os serviços da AWS nos serviços compartilhados de VPC. Você deseja se conectar aos endpoints do PrivateLink na VPC de serviços compartilhados de outras VPCs spoke e de servidores on-premises e, portanto, precisa da resolução DNS para funcionar completamente.

Todas as VPCs spoke pertencem a contas diferentes e são gerenciadas pelos respectivos proprietários das contas.

DNS privado do endpoint de interface

Na criação de um endpoint de interface, você recebe um nome de host DNS regional específico do endpoint que inclui um identificador de endpoint exclusivo, um identificador de serviço, a região e o vpce.amazonaws.com em seu nome. Por exemplo, vpce-12345678-abcdefg.sqs.us-east-1.vpce.amazonaws.com. Este nome resolve para o endereço de IP do endpoint na VPC de serviços compartilhados. O nome de host DNS padrão para esse serviço é sqs.us-east-1.amazonaws.com. A resolução desse nome de host DNS resulta em um endereço IP público.

Habilitar o DNS privado para o endpoint da interface cria uma zona privada de modo que o nome padrão (sqs.us-east-1.amazonaws.com) é resolvido para os endereços IP do endpoint. No entanto, atualmente isso só funciona na VPC onde reside o endpoint. Outras VPCs continuam a resolver o endereço IP público. As etapas a seguir descrevem como garantir que todas as VPCs e servidores on-premises resolvam os endereços IP do endpoint privado.

O diagrama a seguir mostra a arquitetura dessa configuração, onde ilustramos endpoints do PrivateLink para acessar alguns dos serviços da AWS, como o Amazon ECS, o Amazon SNS e o Amazon SQS. Isso pode ser ampliado para outros serviços da AWS compatíveis com o PrivateLink.

 

Para criar esta configuração, siga essas etapas.

  1. Estabeleça a conectividade de rede.

2. Configure os endpoints do Route 53 Resolver.

  • Crie um endpoint de entrada. Recomendamos que você especifique os endereços IP em pelo menos duas Zonas de disponibilidade para alta disponibilidade no VPC de serviços compartilhados.

3. Crie um endpoint PrivateLink.

4. Crie as zonas hospedadas privadas.

  • Se você quiser acessar o endpoint de interface sqs.us-east-1.amazonaws.com no VPC de serviços compartilhados para as VPCs spoke e servidores on-premises, faça o seguinte:

a. Crie uma zona privada de DNS do Route 53 chamada sqs.us-east-1.amazonaws.com e associada à VPC de serviços compartilhados.

b. Crie um registro de alias chamado sqs.us-east-1.amazonaws.com direcionado ao nome de host DNS regional específico do endpoint (vpce-12345678-abcdefg.sqs.us-east-1.vpce.amazonaws.com).

  • Conclua a associação da VPC de zona hospedada privada entre contas com os VPCs spoke.

Considerações importantes

A configuração acima fornece uma solução para centralizar o gerenciamento de DNS para o PrivateLink, mas não necessariamente resolve os problemas para serviços da AWS, como o mazon Elastic File System (Amazon EFS), que conta com respostas específicas da zona de disponibilidade e não oferece atualmente a capacidade de criar um registro ALIAS.

Embora você possa criar regras de encaminhamento para nomes de domínio do Amazon EFS nas contas por meio de endpoints de saída, os clientes não receberão respostas otimizadas para sua zona de disponibilidade. Isso pode resultar em cobranças de rede da zona de disponibilidade cruzada, maiores latências de operação e menor durabilidade. Recomendamos apenas o encaminhamento de nomes de domínio EFS específicos da zona de disponibilidade usando essa técnica, tomando um cuidado especial com cada cliente para montar o EFS usando a entrada de DNS específica para sua zona de disponibilidade.

Se você estiver montando várias contas, saiba que o nome da zona de disponibilidade (por exemplo,
us-east-1a) pode não ser o mesmo de uma conta para outra. Pode ser necessário mapear os nomes da zona de disponibilidade para as IDs da zona de disponibilidade. Este é um identificador exclusivo e consistente para uma zona de disponibilidade que garante que as conexões corretas são feitas. Por exemplo, use1-az1 é uma ID da zona de disponibilidade para a região us-east-1 e tem o mesmo local em todas as contas da AWS. Os endpoints do Resolvedor do Route 53 são projetados especificamente para a configuração do DNS híbrido e não são criados para o caso de uso do tipo Amazon EFS.

Conclusão

Nesta postagem do blog, mostrei algumas das configurações que você pode usar no desenho do DNS gerenciado centralmente para a nuvem híbrida. Você pode usar o Amazon Route 53 e o AWS Transit Gateway para obter resolução nos VPCs para várias contas e domínios locais por meio de um conjunto unificado de regras e do Route 53 Resolver. Envie-nos suas dúvidas ou comentários.

 


Sobre o autor

Bhavin Desai é arquiteto sênior de soluções na AWS. Ele gosta de fornecer orientação técnica aos clientes e ajudá-los a arquitetar e criar soluções para adotar a arte do possível na AWS.