Le Blog Amazon Web Services

Simplifier la gestion DNS dans un environnement multi-account ou Hybride avec Amazon Route 53 resolver

Dans un post précédent , nous vous avons présenté une solution permettant de mettre en œuvre une gestion centralisée des DNS permettant de réduire le nombre de serveurs et de redirections nécessaires pour les résolutions en environnements multi-comptes ou depuis vos sites vers AWS.
Avec l’introduction de Amazon route 53 Resolver, vous avez accès désormais à un redirecteur conditionnel natif qui va vous permettre de simplifier encore plus les résolutions DNS dans les environnements hybrides.

Dans ce post , nous vous montrerons une solution moderne pour centraliser la gestion des DNS en environnements multi-comptes en utilisant Amazon résolveur Route 53. Cette solution vous permettra de résoudre des domaines DNS dans un environnement multi-compte et entre des charges de travail sur AWS et celles sur site, sans la nécessité d’utiliser un contrôleur de domaine chez AWS.

Aperçu de la solution

Notre solution permet d’adresser notamment trois cas d’usages pour la résolution de domaine:

  • Résoudre les domaines présents sur sites depuis des charges de travails s’exécutant dans vos VPCs.
  • Résoudre des domaines privés de votre environnement AWS depuis des charges de travails sur vos sites.
  • Résoudre des noms de domaines privées entre des charges de travails aux différents comptes AWS.

Le schéma ci dessous décrit à haut niveau de l’architecture:

Schéma d’architecture de la solution

Figure 1: Schéma d’architecture de la solution

Dans cette architecture sont représentés:

  1. Il s’agit du serveur DNS par défaut fourni par Amazon pour le VPC “DNC-VPC”, que nous appellerons DNS-VPC. Il correspond à la 2nd adresse IP in le block CIDR du VPC (dans le schéma, il s’agit de l’adresse IP 172.27.0.2). Ce serveur DNS par défaut sera le résolveur de domaine principale pour toutes les charges de travails situés dans les comptes AWS.
  2. Il s’agit du Amazon Route 53 Resolver.Le point de terminaison entrant recevra les requêtes transmises depuis les serveurs DNS sur sites et celles des charges de travail s’exécutant dans les comptes AWS . Le point de terminaison sortant sera utilisé pour transmettre les requêtes DNS depuis AWS vers les serveurs DNS sur sites.
  3. Il s’agit des règles de ré-acheminement. Pour cette architecture, nous avons besoin de deux règles, une pour rediriger les requêtes pour le zone onprem.private vers le serveurs DNS sur sites au travers du point de terminaison sortant, et une seconde règle pour rediriger les requêtes pour la zone awscloud.private vers le point de terminaison entrant.
  4. Ceci indique que les deux règles de ré-acheminement sont partagées avec tous les autres comptes au travers AWS Resource Access Manager et sont associées avec tous les VPC de ces comptes.
  5. Ceci correspond à la zone hébergée privée créée dans chaque compte avec un unique sous-domaine awscloud.private.
  6. Ceci correspond au serveur DNS sur site avec des règles de ré-acheminement configurées pour transmettre les requêtes DNS de la zone awscloud.private vers les adresses IP du point de terminaison entrant.

Note: Cette solution ne requiert pas de VPC-peering ou de connectivité entre les VPCs source/destination et le VPC DNS-VPC.

Description du fonctionnement

Maintenant, nous allons décrire les échanges de résolution DNS pour les trois cas d’usage que nous avons présentés plus haut.

Premier cas d’usage

Cas d’usage de la résolution de domaines sur site depuis des charges de travails sur AWS.

Figure 2: Cas d’usage de la résolution de domaines sur site depuis des charges de travails sur AWS.

Premièrement, nous allons regarder la résolution de domaines sur site depuis des charge de travail sur AWS. Si le serveur avec le domaine privé host1.acc1.awscloud.private essaie de résoudre l’adresse host1.onprem.private, voici ce qu’il se passe:

  1. La requête DNS sera routé vers le serveur DNS par défaut du VPC qui héberge l’hôte host1.acc1.awscloud.private.
  2. Parce que le VPC est associé à la règle de ré-acheminement partagé depuis le compte central DNS, ces régles seront évaluées par le serveur DNS par défaut fourni par Amazon et associé au VPC.
  3. Dans cet exemple, une des règles indique que les requêtes pour onprem.private doivent être transmises au serveur DNS sur site. Par cette règle, la requête est donc transmise au serveur DNS sur site.
  4. La règle de ré-acheminement est associée avec le point de terminaison sortant du résolveur. La requête est donc transmise au travers de ce point de terminaison vers le serveur DNS sur site.

Dans cet échange, la requête DNS a été initiée depuis l’un des comptes participants et a été transmise au serveur DNS centralisé qui , en retour, la transmise au serveur DNS sur site.

Deuxième cas d’usage

Ensuite, nous allons voir comment les charges de travail sur site seront capables de résoudre les domaines privés de l’environnement AWS.

Cas d’usage décrivant comment les charges de travail sur site sont capable de résoudre les domaines privés dans votre environnement AWS.

Figure 3: Cas d’usage décrivant comment les charges de travail sur site sont capable de résoudre les domaines privés dans votre environnement AWS.

Dans ce cas, la requête pour host1.acc1.awscloud.private est initiée depuis un hôte sur site. Voici ce qu’il se passe ensuite::

  1. La requête de domaine est transmise vers le serveur DNS sur site.
  2. La requête est alors transmise vers le point de terminaison entrant via une règle de ré-acheminement du serveur DNS sur site.
  3. La requête atteint le serveur DNS par défaut du VPC DNS-VPC.
  4. Parce que le VPC DNS-VPC est associé à la zone hébergée privée acc1.awscloud.private, le serveur DNS par défaut sera en mesure de résoudre ce domaine.

Dans ce cas, la requête DNS a été initiée depuis le site client et transmises vers le DNS centralisé coté AWS au travers d’un point de terminaison entrant.

Troisième cas d’usage

Enfin, vous pourriez avoir besoin de résoudre les domaines de différents comptes AWS. Voici comment vous pouvez réaliser ceci:

Cas d’usage de la résolution de domaines au travers de plusieurs compte AWS.

Figure 4: Cas d’usage de la résolution de domaines au travers de plusieurs compte AWS.

Supposons que le host 1 host1.acc1.awscloud.private essaie de résoudre le domaine host2.acc2.awscloud.private. Voici les étapes suivies:

  1. La requête de domaine est envoyée au serveur DNS par défaut du VPC qui héberge cette machine (host1).
  2. Comme le VPC est associé avec les règles de ré-acheminement partagé, celles ci sont donc évaluées.
  3. Une règle de ré-acheminement indique que les requêtes pour la zone awscloud.private doivent être transmises au point de terminaison entrant du VPC DNS-VPC (en utilisant les adresses IP de celui ci). Celui ci utilise alors le serveur DNS par défaut fourni par Amazon pour résoudre la requête.
  4. Parce que le VPC DNS-VPC est associé avec la zone hébergée privée acc2.awscloud.private , le serveur DNS par défaut utilisera les règles auto-définies pour résoudre le domaine.

Ce cas d’usage AWS vers AWS correspond au cas où la requête DNS a été initiée depuis un compte AWS participant et transmise au DNS centralisé afin de résoudre les domaines d’un autre compte AWS.
Regardons maintenant comment mettre en oeuvre cette solution dans votre environnement.

Comment déployer la solution

Nous allons décrire comment configurer cette solution en quatre étapes:

  1. Configurer un compte DNS centralisé.
  2. Configurer les comptes AWS participant.
  3. Créer les zone hébergées privées et les associations Route 53.
  4. Configurer les re-directeurs DNS sur site.

Etape 1: Configurer un compte DNS centralisé

Dans cet étape, vous allez configurer des ressources dans le compte DNS centralisé. Ceci comprend le VPC DNC-VPC, les points de terminaisons des résolveurs ainsi que les règles de ré-acheminement.

  1. Créer un VPC ayant pour rôle celui du VPC DNS-VPC et qui soit adapté à votre contexte au travers de la console ou depuis le Quick Start AWS. Vous pouvez revoir les scénarios usuels dans le Guide de l’utilisateur Amazon VPC; un scénario très courant est le VPC avec des sous réseaux publics et privés.
  2. Créer un point de terminaison résolveur route. Vous avez besoin de créer un point de terminaison sortant pour transmettre les requêtes DNS vers les DNS sur sites et d’un point de terminaison entrant pour recevoir les requêtes DNS transmises depuis les charges de travail sur site ou appartenant aux autres comptes AWS.
  3. Créer deux règles de ré-acheminement. La première règle consiste à rediriger les requêtes DNS pour la zone onprem.private vers les addresses IP des serveurs DNS sur site, et la seconde règle consiste à rediriger les requêtes DNS pour la zone awscloud.private vers les adresses IP du point de terminaison entrant.
  4. Après avoir créé ces règles, associer les avec le VPC DNS-VPC créé à l’étape #1. Cela permettra au Route 53 résolveur de commencer à transmettre les requêtes de domaine de façon adéquate.
  5. Enfin, vous avez besoin de partager les deux régles de réacheminement avec les comptes AWS participants. Pour cela, vous utiliserez AWS Resource Access Manager et vous pourrez partager les régles avec l’ensemble de votre organisation AWS ou seulement les comptes AWS que vous spécifiez.

Note: Pour être capable de transmettre les requêtes de domaine vers vos serveurs DNS sur site, vous avez besoin d’établir la connectivité entre votre centre de données et le VPC DNS-VPC au travers soit de VPN site à site ou de liaison AWS Direct Connect.

Etape 2: configurer les comptes AWS participants

Pour chaque compte participant, vous avez besoin de configurer vos VPCs afin d’utiliser les règles de ré-acheminement partagées . Vous avez également besoin de créer une zone hébergée privée pour chacun des comptes.

  • Accepter les régles partagées depuis la console AWS Resource Access Manager. Cette étape n’est pas requise si les règles ont été partagées au sein de l’organisation AWS. Ensuite, associer les régles de ré-acheminement aux VPCs qui contiennent les charges de travail de chacun de vos comptes. Une fois cette association réalisée, le résolveur commencera à transmettre les requêtes DNS en suivant les règles de ré-acheminement..

Au terme de cette étape, vous devriez être capable de résoudre les domaines DNS de vos sites depuis des charges de travails s’exécutant dans n’importe quel VPC associé avec les règles de ré-acheminement partagées. Pour créer des domaines DNS privés au sein d’AWS, vous avez besoin de créer des zone DNS privées hébergées.

Etape 3: Créer des zones DNS hébergées privées

Dans cette étape, vous allez créer une zone privée hébergée dans chacun des comptes du sous-domaine awscloud.private. Veillez à utiliser des noms uniques pour chacune des zones privées hébergées afin d’éviter des conflits de domaine dans votre environnement (par exemple, acc1.awscloud.private ou dev.awscloud.private).

  1. Créer une zone hebergée privée dans chaque compte participant avec un sous-domaine awscloud.private et associer la avec les VPCs actifs de ce compte.
  2. Associer la zone privée hébergée avec le VPC DNS-VPC. Cela permet au VPC centralisé DNS-VPC de résoudre les domaines dans la zone privée hébergée et d’agir comme un résolveur DNS entre les comptes AWS.

Parce que les zone privées hébergées et le VPC DNS-VPC sont dans des comptes différents, vous avez besoin d’associer les zone privées hébergées avec le VPC DNS-VPC. Pour cela vous avez besoin de créer une authorisation depuis le compte qui possède la zone privée hébergée et d’accepter cette autorisation depuis le compte qui possède le VPC DNS-VPC. Vous pouvez faire cela au travers du CLI AWS:

1. Dans chacun compte participant, créer l’autorisation en utilisant les identifiants des zones privées hébergées , la région, et l’identifiant du VPC que vous voulez associer (ici le VPC DNS-VPC).

 aws route53 create-vpc-association-authorization --hosted-zone-id <hosted-zone-id>  --vpc VPCRegion=<region> ,VPCId=<vpc-id>

2. Depuis le compte DNS centralisé , associer le VPC DNS-VPC avec la zone privée hébergée de chacun des comptes participants.

 aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <hosted-zone-id> --vpc VPCRegion=<region>,VPCId=<vpc-id>

Etape 4: Configurer les re-directeurs DNS sur site

Pour pouvoir résoudre les sous-domaines à l’intérieur du domaine awscloud.private depuis des charges de travail sur site, vous devez configurer des règles conditionnelles de redirection pour transmettre les requêtes de domaine aux deux adresses IP des points de terminaison entrants du résolveur (qui ont étaient créés dans le compte centralisé DNS). Notez que cela nécessite une connectivité entre votre centre de donnée et le VPC DNS-VPC, ce qui peut être fournie par un VPN site à site ou une liaison AWS Direct Connect.

Remarques additionnelles et limitations

Grace à la flexibilité de Route 53 resolver et des règles conditionnelles de ré-acheminement, vous pouvez contrôler quelles requêtes envoyer vers le serveur DNS centralisé et celles à résoudre localement dans le même compte.
Ceci est particulièrement important lorsque vous planifiez d’utiliser certains services AWS tel que AWS PrivateLink ou Amazon Elastic File System (EFS) parce que les noms de domaines associés avec ces services ont besoin d’être résolu localement au compte qui les possèdent.

Nous vous recommandons de résoudre les domaines locaux de vos compte lorsque cela est possible ; par exemple, les domaines privés dans les zone d’hébergement privée du même compte. Pour cela, vous pouvez créer des règles conditionnelles locales au compte, utiliser le type de règle “system” et associer ces règles avec vos VPCs.

Note concernant les limites du Résolveur Route 53: il y a une limite de 10,000 requête par seconde et par adresse IP sur un point de terminaison. Si vous avez une charge de travail qui requiert des limites plus haute, il faut alors envisager de transférer ces requêtes vers un serveur DNS local s’exécutant sur une instance EC2. Vous trouverez ici plus d’information sur les limites du service résolveur Route 53.

Dans cette section, nous allons considérer deux cas d’usages qui nécessitent une attention particulière.

1. Points de terminaison d’un VPC d’interface (AWS PrivateLink)

Lorsque vous créez un point de terminaison d’un VPC d’interface (AWS PrivateLink) un point de terminaison d’un VPC d’interface (AWS PrivateLink), AWS génère des noms DNS d’hôtes de terminaisons spécifiques que vous pouvez utiliser pour communiquer avec le service. Pour les services AWS et ceux des partenaires du Marketplace AWS, vous pouvez optionnellement activer des points de terminaisons DNS privés. Cette option associe une zone hébergée privée avec votre VPC. Cette zone hébergée contient un ensemble d’enregistrement pour le nom par défaut du service DNS (par exemple, ec2.us-east-1.amazonaws.com) qui sont résolus vers les adresses IP privées des interfaces réseau du point de terminaison dans votre VPC. Ceci vous permet de faire des requêtes vers ce service en utilisant les noms d’hôtes DNS par défaut au lieu des noms DNS d’hôtes de terminaisons spécifiques.

Si vous utilisez les DNS privés pour votre point de terminaison , vous devez résoudre les requêtes DNS vers le point de terminaison local à votre compte et utiliser le service DNS par défaut fourni par AWS. Aussi, dans ce cas nous vous recommandons de résoudre les requêtes pour le domaine amazonaws.com localement et de ne pas transmettre ces requêtes vers le DNS centralisé.

2. Montage des systèmes de fichiers EFS avec un nom DNS

Vous pouvez monter un système de fichier Amazon EFS sur une instance EC2 en utilisant les noms DNS. Le nom DNS du système de fichier est automatiquement résolu vers l’adresse IP cible de montage dans la zone de disponibilité de l’instance EC2 qui se connecte. Pour cela , le VPC doit utiliser le service DNS par défaut fourni par amazon pour résoudre les noms DNS du service EFS.

Si vous planifiez d’utiliser EFS dans votre environnement , nous vous recommandons de résoudre les noms DNS EFS localement et d’éviter d’envoyer les requêtes vers le service central DNS car dans ce cas les clients peuvent ne pas recevoir des réponses optimisées pour leur zone de disponibilité , ce qui peut entrainer des latences plus importantes lors d’opération et diminuer la durabilité.

En Résumé

Dans ce post, nous avons introduit une solution simplifié pour mettre en oeuvre une résolution DNS centralisé pour un environnement multi comptes ou hybride. Cette solution utilise le résolveur AWS Route 53, AWS Resource Access Manager, et les capacités natives de Route 53 afin de réduire la complexité et l’effort opérationnel en nécessitant plus des serveurs ou des relais DNS au sein de l’environnement AWS.

Si vous avez des commentaires sur ce billet de blog, vous pouvez mettre des commentaires dans la section Commentaires ci-dessous. Si vous avez des questions sur cet article de blog, lancez un nouveau fil de discussion sur les forums AWS. Vous voulez plus de contenu pratique, d’actualités et d’annonces de fonctionnalités sur AWS Security? Suivez-nous sur Twitter.

 

Cet article a été écrit par Mahmoud Matouk (Source), world wide public sector Solutions Architects qui aide les clients du secteur éducatif à construire des solutions innovantes, sécurisées et hautement disponible avec les services AWS et traduit en français par Renaud Vaneeckhoutte , Solutions architect chez AWS.