Le Blog Amazon Web Services
Gestion centralisée du DNS dans un environnement cloud hybride avec Amazon Route 53 et AWS Transit Gateway
Une stratégie de connectivité hybride efficace nécessite d’aller plus loin que la simple connectivité entre réseaux privés. Cela requiert souvent de travailler notamment avec des zones internes indépendantes, à la fois dans un Amazon Virtual Private Cloud (Amazon VPC) et sur site. Une telle stratégie nécessite un schéma de nommage DNS (Domain Name System) qui couvre tout le réseau. Pour se faire, il est nécessaire de fournir des services de résolution de nom là où les ressources et les applications sont déployées. Par exemple, on aura besoin d’une infrastructure DNS on-premises pour les ressources on-premises et de Amazon Route 53 Private DNS Resolver qui répondra aux requêtes pour les ressources dans le cloud AWS. Pour avoir une vue unifiée du DNS dont vos applications ont besoin dans un contexte de réseau hybride, vous avez peut être besoin de mettre en place une redirection DNS bi-directionnelle. Cela vous donne en effet la capacité à requêter des zones DNS on-premises depuis vos Amazon VPCs, aussi bien qu’un Résolveur Route 53 depuis vos datacenters on-premises.
AWS offre la fonctionnalité Amazon Route 53 Resolver for Hybrid Cloud depuis Novembre 2018. Elle permet de simplifier la migration vers le cloud ainsi que les architectures hybrides en apportant une solution à plusieurs défis liés au DNS. Ces défis peuvent ne pas paraître évidents quand vous commencez à planifier votre migration vers le cloud, mais ils apparaissent fréquemment au milieu d’un projet, et ils peuvent alors ralentir vos développements et votre capacité d’innovation.
La plupart de nos clients ont des infrastructures réparties sur de multiples comptes et Amazon VPCs où chaque VPC au sein d’un compte héberge plusieurs domaines et zones hébergées privées. L’intégration du DNS dans ces conditions peut être complexe. Il est alors nécessaire de pouvoir utiliser une gestion simple des comportements récursifs du DNS au travers de ces multiples comptes et VPCs, par le biais d’un ensemble de règles uniformes et d’un Résolveur Route 53 unique. Vous pouvez obtenir ce résultat en centralisant la gestion du DNS pour tous vos domaines on-premises ou dans un Amazon VPC.
Point d’entrée unique DNS pour les réseaux on-premises et les Amazon VPCs
Dans cette situation, illustrée par le schéma suivant, vous avez une infrastructure existante se composant de résolveurs DNS on-premises qui font autorité pour la résolution des noms de domaines locaux. Vous avez aussi plusieurs VPCs dans plusieurs comptes AWS et des domaines et zones hébergées privées associés à ces VPCs. Ces Amazon VPCs sont interconnectés via la Transit Gateway dans une topologie pivot satellites. Pour simplifier la gestion du DNS dans cet environnement hybride, vous pouvez mettre en œuvre une gestion centralisée du DNS qui pourra résoudre les noms DNS entre votre centre de données sur site et vos VPCs.
Les points de terminaison du Résolveur Route 53 et les règles de réacheminement sont justement conçus pour offrir une gestion intégrée du DNS dans les topologies réseaux hybrides où le réacheminement en temps-réel des requêtes DNS est souvent indispensable. Ces fonctionnalités permettent au Résolveur Route 53 ainsi qu’à vos résolveurs DNS on-premises de pouvoir chacun répondre aux requêtes pour les domaines gérés par l’autre en réacheminant celles-ci en temps réel.
Partager des points de terminaison PrivateLink entre VPCs
Dans cette configuration, vous utilisez AWS PrivateLink pour accéder de manière sécurisée aux services AWS au travers d’une connectivité privée depuis vos VPCs et vos serveurs on-premises. Vous aurez besoin pour cela de points de terminaison de VPC d’interface qui servent de point d’entrée pour le trafic destiné aux services AWS supportés par AWS PrivateLink. Vous pouvez configurer des points de terminaison de VPC d’interface dans chaque VPC devant accéder aux services AWS mais il faut cependant préciser que vous serez alors facturé pour chacun de ces points de terminaison, et pour chaque heure où celui-ci reste provisionné. Pour réduire les coûts et alléger la charge opérationnelle liée à la gestion de points de terminaison dans chaque VPC, une bonne pratique consiste à monter vos points de terminaison PrivateLink dans un VPC de services partagés et le partager ensuite avec d’autres VPCs. Nous verrons dans la suite comment concevoir au mieux la résolution DNS au travers des VPCs via la centralisation des points de terminaison PrivateLink.
Grâce au service Résolveur Route 53, vous obtiendrez les avantages suivants en terme de conception :
- Vous utilisez un service entièrement géré, où AWS gère les travaux non-différenciant liés à la disponibilité et la fiabilité,
- Le service préserve l’isolation via les Zones de disponibilité, et les réponses locales aux requêtes au sein d’une Zone de disponibilité,
- Les points de terminaison entrants et sortants supportent 10000 requêtes par seconde et par adresse IP dans un point de terminaison. Vous avez seulement à effectuer votre requête vers ce dernier pour réacheminer le trafic automatiquement,
- Le service fournit des métriques relatives au volume de requêtes dans Amazon CloudWatch ce qui vous permettra de configurer des alarmes.
Voyons maintenant quelques-unes des bonnes pratiques pour la mise en œuvre d’un Résolveur Route 53 :
- Nous recommandons l’utilisation de l’adresse .2 pour la résolution DNS depuis les instances EC2, ce qui offre à chaque instance un maximum de 1024 paquets par seconde (pps) et par interface réseau et préserve l’isolation des Zones de disponibilité,
- Vous devez vous assurer que les serveurs DNS dans vos jeux d’options DHCP pointent vers AmazonProvidedDNS plutôt que vers le point de terminaison d’un Résolveur. Utilisez des règles de réacheminement pour vous assurer que AmazonProvidedDNS a une vue de tous les DNS requis,
- Utilisez les points de terminaison des Résolveurs pour intégrer le Résolveur Route 53 avec des DNS on-premises,
- La résolution DNS est critique pour la plupart des applications, nous recommandons donc de concevoir une solution fiable. Le réacheminement des requêtes ajoute de la complexité à la résolution DNS en temps réel, la bonne pratique est donc de l’utiliser uniquement lorsque c’est nécessaire,
- Bien qu’il soit possible d’utiliser des règles de réacheminement pour résoudre des zones hébergées privées depuis d’autres VPCs, cela n’est pas recommandé. La méthode la plus fiable, performante et économique consiste à partager et associer les zones hébergées privées directement à tous les VPCs qui en ont besoin.
Voyons plus en détail maintenant des exemples de conception et de configuration pour la gestion centralisée du DNS via le Résolveur Route 53.
Exemple 1 – Point d’entrée unique DNS pour les réseaux on-premises et les Amazon VPC
Dans cette configuration, vous voulez pouvoir requêter les zones DNS privées Route 53 dans plusieurs comptes et VPCs depuis vos ressources on-premises. Ce modèle de conception s’appuie sur un VPC pour les service partagés. Dans le même temps, vous voulez aussi transférer les requêtes pour les domaines on-premises effectuées depuis les VPCs vers les résolveurs DNS sur site. Ces VPCs sont interconnectés via une topologie “Hub & Spoke” (ie Pivot – Satellites). Chacun des VPCs satellites appartient à un compte différent et est géré par son compte respectif.
Quand une zone hébérgée privée Route 53 a besoin d’être résolue dans de multiples VPCs et comptes AWS comme décrit précédemment, le modèle le plus fiable est de partager la zone hébergée privée entre les comptes et de l’associer avec chaque VPC qui le nécessite. Bien qu’il soit possible d’utiliser les règles de réacheminement du Résolveur Route 53 pour résoudre ce cas d’usage, cela introduit des coûts additionnels, de possible dépendances entre zones de disponibilité, et une certaine complexité que l’on peut éviter en associant directement les zones aux VPCs.
Le diagramme suivant permet d’illustrer l’architecture retenue pour cette configuration :
Pour créer cette configuration, suivez ces étapes générales :
- Mettez en place la connectivité réseau IP
- Établissez la connectivité réseau depuis les VPCs satellites vers le VPC des service partagés en utilisant AWS Transit Gateway,
- Établissez la connectivité vers les serveurs sur site en utilisant AWS Direct Connect ou bien AWS Site-to-Site VPN,
- Configurez les points de terminaison pour le Résolveur Route 53
- Créez un point de terminaison entrant. Nous recommandons d’utiliser des adresses IP dans au moins deux zones de disponibilité pour assurer la haute disponibilité au sein du VPC des services partagés,
- Créez un point de terminaison sortant. Nous recommandons d’utiliser des adresses IP dans au moins deux zones de disponibilité pour assurer la haute disponibilité au sein du VPC des services partagés,
- Créez les zones hébergées privées
- Créez les zones hebergées privées Route 53 dans le VPC des service partagés et associez les. En complément, finalisez l’association de la zone hébergée privée-VPC avec les VPCs satellites puisque ceux ci sont dans des comptes différents. Tous les VPCs devront associer leurs zones hébergées privées aux autres VPCs si cela est nécessaire,
- Créez les règles de réacheminement
- Créez des règles de réacheminement conditionnelles qui spécifie les noms de domaines DNS pour lesquels vous souhaitez réacheminer les requêtes vers les résolveurs DNS on-premises.
Exemple: Une règle avec le nom de domaine “onprem.mydc.com” aura pour conséquence de réacheminer toutes les requêtes pour ce domaine et ses enfants. - Quand vous configurez des règles pour le trafic sortant, sélectionnez le VPC des services partagés dans « VPC qui utilisent cette règle » (option VPCs that use this rule).
- Si les VPCs satellites sont dans le même compte que le VPC des services partagés, alors vous pourrez choisir plusieurs VPCs dans « VPC qui utilisent cette règl »e (option VPCs that use this rule).
- Créez des règles de réacheminement conditionnelles qui spécifie les noms de domaines DNS pour lesquels vous souhaitez réacheminer les requêtes vers les résolveurs DNS on-premises.
- Partagez les règles de réacheminement avec d’autres comptes AWS et utilisez les règles partagées
- Dans cette configuration, les VPCs satellites sont répartis sur différents comptes. Vous pouvez partager les règles de réacheminement avec les VPCs dans d’autres comptes en utilisant les règles partagées via AWS Resource Access Manager (AWS RAM). La copie écran suivante montre comment partager des règles de réacheminement avec plusieurs VPCs via AWS RAM :
- Dans cette configuration, les VPCs satellites sont répartis sur différents comptes. Vous pouvez partager les règles de réacheminement avec les VPCs dans d’autres comptes en utilisant les règles partagées via AWS Resource Access Manager (AWS RAM). La copie écran suivante montre comment partager des règles de réacheminement avec plusieurs VPCs via AWS RAM :
Exemple 2 – Partager des points de terminaison PrivateLink entre VPCs
Cette configuration est souvent complémentaire de la précédente, et permet de centraliser les PrivateLink pour accéder de manière sécurisée aux services dans le VPC des services partagés. Le but est donc de se connecter aux points de terminaison PrivateLink dans le VPC des services partagés depuis les VPCs satellites et les serveurs sur site et donc d’avoir une résolution DNS qui fonctionne entre tous ces éléments.
Chacun des VPC satellites appartient à un compte différent et est géré par son compte respectif.
DNS privé pour les points de terminaison d’interface
A la création d’un point de terminaison d’interface, vous recevez un nom DNS régional spécifique à ce point de terminaison qui inclue un identifiant unique de point de terminaison, un identifiant de service, la région, avec vpce.amazonaws.com dans son nom. Par exemple, vpce-12345678-abcdefg.sqs.eu-west-3.vpce.amazonaws.com. Ce nom est résolu vers les adresses IP du point de terminaison dans le VPC des services partagés. Le nom d’hôte DNS par défaut pour ce service est sqs.us-east-1.amazonaws.com. La résolution de ce nom d’hôte résulte en une adresse IP publique.
L’activation du DNS Privé pour le point de terminaison d’interface créé une zone hébergée privée de manière à ce que le nom par défaut (sqs.us-east-1.amazonaws.com) soit résolu vers l’adresse IP privée du point de terminaison. Cependant, à ce jour, cela ne fonctionne qu’au sein du VPC où le point de terminaison réside. Les autres VPCs continuent de résoudre l’adresse IP publique.
Le diagramme suivant montre l’architecture cible pour cette configuration où les point de terminaison PrivateLink sont illustrés par des exemples d’accès à certains services AWS comme Amazon ECS, Amazon SNS et Amazon SQS. Cela peut bien sûr être étendu à n’importe quel service AWS qui supporte PrivateLink.
Points d’attention
La configuration ci-dessus fournit une solution pour la gestion du DNS centralisée pour PrivateLink, mais n’est pas nécessairement une solution pour d’autres services AWS comme par exemple Amazon Elastic File System (Amazon EFS), qui s’appuie sur des réponses DNS spécifiques à la zone de disponibilité et n’offre pas encore la possibilité de créer des enregistrements d’alias.
Bien que vous puissiez créer des règles de réacheminement pour les noms de domaine Amazon EFS à travers plusieurs comptes via les points de terminaisons sortants, les clients ne recevront pas une réponse optimisée pour leur Zone de disponibilité. Cela pourrait avoir comme conséquence des coûts supplémentaires liés au trafic réseau entre Zones de disponibilité, des latences opérationnelles plus importantes ainsi qu’une diminution de la durabilité. Nous recommandons donc uniquement le réacheminement des noms de domaine EFS spécifiques aux Zones de disponibilité via cette configuration, en prenant particulièrement soin pour les clients de monter le service EFS en utilisant l’entrée DNS spécifique à leurs zones de disponibilité.
Si vous montez des partages entre comptes, prenez garde aussi au fait que les noms des Zones de disponibilité (par exemple, eu-west-3a) peuvent être différents d’un compte à l’autre. Vous aurez besoin d’associer le nom de la Zone de disponibilité à l’identifiant de la Zone de disponibilité (Availability Zone ID) qui est lui un identifiant unique et consistant pour une Zone de disponibilité. Par exemple, euw3-az1 est un identifiant de Zone de disponibilité pour la région eu-west-3, et correspond à la même zone dans tous les comptes AWS.
Les étapes suivantes décrivent comment s’assurer que tous les VPCs et les serveurs sur site pourront résoudre l’adresse IP privée du point de terminaison.
- Mettez en place la connectivité réseau IP
- Etablissez la connectivité réseau depuis les VPCs satellites vers le VPC des service partagés en utilisant AWS Transit Gateway
- Etablissez la connectivité vers les serveurs sur site en utilisant AWS Direct Connect ou bien AWS Site-to-Site VPN.
- Configurez les points de terminaison pour le Resolveur Route 53
- Créez un point de terminaison entrant. Nous recommandons d’utiliser des adresses IP dans au moins deux zones de disponibilité pour assurer la haute disponibilité au sein du VPC des services partagés.
- Créez un point de terminaison PrivateLink
- Créez un point de terminaison d’interface pour le service AWS souhaité ET ne cochez pas Activer le nom de DNS privé (Enable DNS name)
- Créez les zones hébergées privées
- Par exemple, si vous souhaitez accéder au point de terminaison d’interface sqs.eu-west-3.amazonaws.com situé dans le VPC des services partagés, depuis les VPCs satellites et les serveurs sur site, opérez de la manière suivante:
- Créez une zone privée hébergée Route 53 sqs.eu-west-3.amazonaws.com associée au VPC des services partagés
- Créez un enregistrement d’alias sqs.eu-west-3.amazonaws.com qui pointe vers le nom d’hôte DNS régional spécifique au point de terminaison (vpce-12345678-abcdefg.sqs.eu-west-3.vpce.amazonaws.com)
- Finalisez l’association de la zone hébergée privée-VPC avec les VPCs satellites.
- Par exemple, si vous souhaitez accéder au point de terminaison d’interface sqs.eu-west-3.amazonaws.com situé dans le VPC des services partagés, depuis les VPCs satellites et les serveurs sur site, opérez de la manière suivante:
Conclusion
Dans cet article, nous vous avons montré quelques-unes des configurations que vous pouvez utiliser pour construire une solution de gestion du DNS centralisée pour un déploiement cloud hybride. Vous pouvez utiliser Amazon Route 53 et AWS Transit Gateway pour la résolution à travers les VPCs dans un environnement multi-comptes et les domaines sur site, par le biais d’un ensemble de règles uniformes et d’un Résolveur Route 53.
Article original par Bhavin Desai, Senior Solutions Architect chez AWS. Article traduit par Stephen Roux, Solution Architect chez AWS, France région Sud-Est, LinkedIn.