Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Sélection d'une stratégie de routage Lorsque vous créez un enregistrement, vous choisissez une stratégie de routage, qui détermine la façon dont Amazon Route 53 répond aux requêtes : + **Simple routing policy (Stratégie de routage simple)** : utilisez une stratégie de routage simple quand vous disposez d'une seule ressource qui exécute une fonction donnée pour votre domaine, comme, par exemple, un serveur web qui diffuse le contenu du site web example.com. Vous pouvez utiliser le routage simple pour créer des enregistrements dans une zone hébergée privée. + **Failover routing policy (Stratégie de routage par basculement)** : utilisez une stratégie de routage par basculement pour configurer le basculement actif-passif. Vous pouvez utiliser le routage par basculement pour créer des enregistrements dans une zone hébergée privée. + **Stratégie de routage de géolocalisation** : utilisez la stratégie de routage de géolocalisation lorsque vous souhaitez acheminer le trafic en fonction de l'emplacement de vos utilisateurs. Vous pouvez utiliser le routage de géolocalisation pour créer des enregistrements dans une zone hébergée privée. + **Stratégie de routage par proximité géographique** : utilisez cette stratégie lorsque vous souhaitez acheminer du trafic en fonction de l'emplacement de vos ressources et, éventuellement, détourner le trafic de vos ressources à un emplacement donné vers les ressources d'un autre emplacement. Vous pouvez utiliser le routage de géoproximité pour créer des enregistrements dans une zone hébergée privée. + **Politique de routage par latence** : à utiliser lorsque vous disposez de plusieurs ressources Régions AWS et que vous souhaitez acheminer le trafic vers la région offrant la meilleure latence. Vous pouvez utiliser le routage avec latence pour créer des enregistrements dans une zone hébergée privée. + **IP-based routing policy** (Politique de routage basée sur IP) – utilisez la politique de routage basée sur IP lorsque vous voulez acheminer le trafic en fonction de l'emplacement de vos utilisateurs, et que vous disposez des adresses IP d'où provient le trafic. + **Multivalue answer routing policy (Stratégie de routage de réponse multivaleur)** : utilisez la stratégie de routage de réponse multivaleur lorsque vous souhaitez que Route 53 réponde aux requêtes DNS avec jusqu'à huit enregistrements sains sélectionnés de manière aléatoire. Vous pouvez utiliser le routage de réponses à plusieurs valeurs pour créer des enregistrements dans une zone hébergée privée. + **Weighted routing policy (Stratégie de routage pondéré)** : utilisez la stratégie de routage pondéré pour acheminer le trafic vers plusieurs ressources selon les proportions que vous spécifiez. Vous pouvez utiliser le routage pondéré pour créer des enregistrements dans une zone hébergée privée. **Topics** + [Routage simple](routing-policy-simple.md) + [Routage par basculement](routing-policy-failover.md) + [Routage de géolocalisation](routing-policy-geo.md) + [Routage par géoproximité](routing-policy-geoproximity.md) + [Routage basé sur la latence](routing-policy-latency.md) + [Routage basé sur IP](routing-policy-ipbased.md) + [Multivalue answer routing (Routage de réponse multivaleur)](routing-policy-multivalue.md) + [Weighted routing (Routage pondéré)](routing-policy-weighted.md) + [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md) # Routage simple Le routage simple vous permet de configurer des enregistrements DNS standard sans routage Route 53 spécial, comme un routage pondéré ou de latence. Avec le routage simple, vous acheminez généralement le trafic vers une seule ressource, par exemple, un serveur web pour votre site web. Vous pouvez utiliser la stratégie de routage simple pour créer des enregistrements dans une zone hébergée privée. Si vous choisissez la stratégie de routage simple dans la console Route 53, vous ne pouvez pas créer plusieurs enregistrements ayant le même nom et le même type, mais vous pouvez spécifier plusieurs valeurs dans le même enregistrement, par exemple plusieurs adresses IP. (Si vous choisissez la politique de routage simple pour un enregistrement d'alias, vous ne pouvez spécifier qu'une seule AWS ressource ou un seul enregistrement dans la zone hébergée actuelle.) Si vous spécifiez plusieurs valeurs dans un enregistrement, Route 53 renvoie toutes les valeurs au résolveur récursif dans un ordre aléatoire, puis le résolveur renvoie les valeurs au client (comme un navigateur web) qui a envoyé la requête DNS. Le client sélectionne ensuite une valeur et renvoie la requête. Avec une politique de routage simple, même si vous pouvez spécifier plusieurs adresses IP, aucune surveillance de l'état n'a lieu pour ces adresses IP. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage simple pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements simples](resource-record-sets-values-basic.md) + [Valeurs spécifiques aux enregistrements d'alias simples](resource-record-sets-values-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) # Routage par basculement Le routage par basculement vous permet d'acheminer le trafic vers une ressource lorsqu'elle est saine ou vers une autre ressource si la première ressource n'est pas saine. L'enregistrement principal et l'enregistrement secondaire peuvent acheminer le trafic de différents types d'éléments, d'un compartiment Amazon S3 configuré comme site web à une arborescence complexe d'enregistrements. Pour de plus amples informations, veuillez consulter [Basculement actif-passif](dns-failover-types.md#dns-failover-types-active-passive). Vous pouvez utiliser la stratégie de routage de basculement pour créer des enregistrements dans une zone hébergée privée. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de basculement pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements de basculement](resource-record-sets-values-failover.md) + [Valeurs spécifiques aux enregistrements d'alias de basculement](resource-record-sets-values-failover-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) # Routage de géolocalisation Le routage de géolocalisation vous permet de choisir les ressources qui servent le trafic en fonction de la localisation géographique de vos utilisateurs, c'est-à-dire de l'emplacement d'où proviennent les requêtes DNS. Par exemple, vous souhaitez peut-être que toutes les requêtes d'Europe soient acheminées vers l'équilibreur de charge Elastic Load Balancing dans la région de Francfort. Quand vous utilisez le routage de géolocalisation, vous pouvez localiser votre contenu et présenter tout ou partie de votre site web dans la langue de vos utilisateurs. Vous pouvez aussi utiliser le routage de géolocalisation pour limiter la distribution de contenu aux seuls emplacements dans lesquels vous avez des droits de distribution. Une autre utilisation possible consiste à équilibrer la charge entre les points de terminaison de easy-to-manage manière prévisible, afin que chaque emplacement utilisateur soit systématiquement acheminé vers le même point de terminaison. Vous pouvez spécifier des emplacements géographiques par continent, par pays ou par état des États-Unis. Si vous créez des enregistrements distincts pour des régions géographiques qui se chevauchent (par exemple, un pour l'Amérique du Nord et un autre pour le Canada), la région géographique la plus petite est prioritaire. Cela vous permet d'acheminer des requêtes concernant un continent vers une ressource et celles concernant des pays sélectionnés sur ce continent vers une autre ressource. (Pour obtenir la liste des pays de chaque continent, consultez [Location](resource-record-sets-values-geo.md#rrsets-values-geo-location).) La géolocalisation se base sur le mappage d'adresses IP à des emplacements. Cependant, certaines adresses IP ne sont pas mappées à des emplacements géographiques. Ainsi, même si vous créez des enregistrements de géolocalisation couvrant les sept continents, Amazon Route 53 recevra des requêtes DNS à partir d'emplacements qu'il n'est pas en mesure d'identifier. Vous pouvez créer un enregistrement par défaut pour gérer les requêtes provenant d'adresses IP qui ne sont mappées à aucun emplacement et les requêtes issues d'emplacements pour lesquels vous n'avez pas créé d'enregistrements de géolocalisation. Si vous ne créez pas d'enregistrement par défaut, Route 53 renvoie un message « aucune réponse » pour les requêtes provenant de ces emplacements. Vous pouvez utiliser le routage de géolocalisation pour des enregistrements dans les zones hébergées publiques et privées. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md). Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de géolocalisation pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements de géolocalisation](resource-record-sets-values-geo.md) + [Valeurs spécifiques aux enregistrements d'alias de géolocalisation](resource-record-sets-values-geo-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) # Routage de géolocalisation dans des zones hébergées privées Pour les zones hébergées privées, Route 53 répond aux requêtes DNS en fonction Région AWS du VPC d'où provient la requête. Pour en obtenir la liste Régions AWS, consultez [Régions et zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) dans le guide de l'*utilisateur Amazon EC2*. Si la requête DNS provient d'une partie sur site d'un réseau hybride, elle sera considérée comme provenant de la Région AWS dans laquelle se trouve le VPC. Si vous incluez des surveillances de l'état, vous pouvez créer des enregistrements par défaut pour : + Les adresses IP qui ne sont pas mappées à des emplacements géographiques. + Les requêtes DNS qui proviennent d'emplacements pour lesquels vous n'avez pas créé d'enregistrement de géolocalisation. Si l'enregistrement de géolocalisation pour la région de la requête DNS est défectueux, l'enregistrement par défaut sera renvoyé (s'il est sain). Dans l'exemple de configuration illustré dans la figure suivante, les requêtes DNS provenant d'un Région AWS us-east-1 (Virginie) seront acheminées vers le point de terminaison 1.1.1.1. ![\[Une capture d'écran qui montre un enregistrement de géolocalisation pour une zone hébergée privée.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/geolocation-phz.png) # Routage par géoproximité Avec le routage par proximité géographique, Amazon Route 53 achemine le trafic vers vos ressources en fonction de l'emplacement géographique de vos utilisateurs et ressources. Il achemine le trafic vers la ressource disponible la plus proche. Vous pouvez également, si vous le souhaitez, choisir d'acheminer davantage ou moins de trafic vers une ressource donnée en spécifiant une valeur, appelée *écart*. Un écart augmente ou réduit la taille de la région géographique à partir de laquelle le trafic est acheminé vers une ressource. Vous créez des règles de proximité géographique pour vos ressources et spécifiez l'une des valeurs suivantes pour chaque règle : + Si vous utilisez AWS des ressources, spécifiez le Région AWS ou le groupe de zones local dans lequel vous avez créé la ressource. + Si vous n'utilisez pas de AWS ressources, spécifiez la latitude et la longitude de la ressource. Pour utiliser AWS les Zones Locales, vous devez d'abord les activer. Pour plus d'informations, consultez [Premiers pas avec les zones locales](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) dans le *Guide de l'utilisateur des zones locales AWS *. Pour en savoir plus sur la différence entre les zones Régions AWS et les zones locales, consultez [Régions et zones](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) dans le guide de l'*utilisateur Amazon EC2*. (Facultatif) Pour modifier la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez la valeur d'écart applicable : + Pour étendre la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez un nombre entier positif compris entre 1 et 99 en tant que valeur d'écart. Route 53 diminue la taille des régions adjacentes. + Pour réduire la taille de la région géographique à partir de laquelle Route 53 achemine le trafic vers une ressource, spécifiez une valeur d'écart négative comprise entre -1 et -99. La route 53 augmente la taille des régions adjacentes. **Note** Nous mettons à jour la console Traffic Flow pour Route 53. Pendant la période de transition, vous pouvez continuer à utiliser l'ancienne console. Choisissez l'onglet correspondant à la console que vous utilisez. + [Nouvelle console](#traffic-flow-geoprox-routing-map-new) + [Ancienne console](#traffic-flow-geoprox-routing-map-old) ------ #### [ New console ] La carte suivante en montre quatre Régions AWS (numérotées de 1 à 5) : 1. USA Ouest (Oregon) 1. Europe (Francfort) 1. Asie-Pacifique (Tokyo) 1. Afrique (Le Cap) 1. Middle East (Bahrain) **Note** Les cartes ne sont disponibles qu'avec Traffic Flow. ![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous disposez d'enregistrements de géoproximité pour des ressources situées Régions AWS dans l'ouest des États-Unis (Oregon), en Europe (Francfort), en Asie-Pacifique (Tokyo), en Afrique (Le Cap) et au Moyen-Orient (Bahreïn).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png) La carte suivante montre ce qui se passe si vous ajoutez un biais de \$125 pour la région USA Ouest (Oregon) (numéro **1** sur la carte). Le trafic est acheminé vers la ressource dans cette région à partir d'une plus grande partie de l'Amérique du Nord et de toute l'Amérique du Sud qu'auparavant. ![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de +25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png) La carte suivante montre ce qui se passe si vous modifiez le biais à -25 pour la région de l'ouest des États-Unis (Oregon). **Le trafic est acheminé vers la ressource de cette région depuis de plus petites parties de l'Amérique du Nord et du Sud qu'auparavant, et une plus grande partie du trafic est acheminée vers les ressources des régions adjacentes **2**, **3** et 4.** ![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous ajoutez un biais de -25 dans la région USA Ouest (Oregon).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png) ------ #### [ Old console ] La carte suivante en montre quatre Régions AWS (numérotées de 1 à 4) et un emplacement à Johannesburg, en Afrique du Sud, indiqué par la latitude et la longitude (5). **Note** Les cartes ne sont disponibles qu'avec Traffic Flow. ![\[Une carte du monde qui montre comment le trafic est acheminé lorsque vous avez des enregistrements de géoproximité pour des ressources situées Régions AWS dans l'ouest des États-Unis (Oregon), dans l'est des États-Unis (Virginie du Nord), en Europe (Paris) et dans l'Asie-Pacifique (Tokyo), et que vous avez un enregistrement pour une ressource non liée à une AWS ressource à Johannesburg, en Afrique du Sud.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png) La carte suivante montre ce qui se produit si vous ajoutez un écart de \$125 pour la région USA Est (Virginie du Nord) (numéro **2** sur la carte). Le trafic est acheminé vers la ressource dans cette région à partir d'une plus grande partie de l'Amérique du Nord que précédemment, et à partir de l'ensemble de l'Amérique du Sud. ![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de +25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png) La carte suivante montre ce qui se produit si vous modifiez l'écart à -25 pour la région USA Est (Virginie du Nord). Le trafic est acheminé vers la ressource dans cette région à partir de plus petites parties d'Amérique du Nord et du Sud que précédemment, et davantage de trafic est acheminé vers les ressources dans les régions adjacentes **1**, **3** et **5**. ![\[Une carte du monde qui illustre la façon dont le trafic est acheminé lorsque vous ajoutez un écart de -25 dans la région USA Est (Virginie du Nord).\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png) ------ L'impact de la valeur d'écart de vos ressources dépend d'un certain nombre de facteurs, dont les éléments suivants : + Le nombre de ressources dont vous disposez. + La proximité des ressources les unes par rapport aux autres. + Le nombre de vos utilisateurs se trouvant à proximité de la zone frontalière entre les régions géographiques. Supposons, par exemple, que vous disposiez de ressources dans l'est des Régions AWS États-Unis (Virginie du Nord) et dans l'ouest des États-Unis (Oregon), et que vous ayez de nombreux utilisateurs à Dallas, Austin et San Antonio, au Texas, aux États-Unis. Ces villes étant approximativement à égale distance entre vos ressources, un léger changement de biais pourrait entraîner une importante variation du trafic entre les ressources. Région AWS Nous vous recommandons de modifier la valeur d'écart par petits incréments afin d'éviter de surcharger vos ressources en raison d'un basculement inattendu du trafic. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md). ## Comment Amazon Route 53 utilise une valeur d'écart pour acheminer le trafic Voici la formule utilisée par Amazon Route 53 pour déterminer la manière d'acheminer le trafic : **Écart** `Biased distance = actual distance * [1 - (bias/100)]` Lorsque la valeur du biais est positive, Route 53 traite la source d'une requête DNS et la ressource que vous spécifiez dans un enregistrement de géoproximité (telle qu'une instance EC2 dans un Région AWS) comme si elles étaient plus proches l'une de l'autre qu'elles ne le sont réellement. Supposons par exemple que vous disposez des enregistrements de proximité géographique suivants : + Un enregistrement pour un serveur Web A, qui possède une valeur d'écart positive de 50 + Un enregistrement pour un serveur Web B qui ne possède aucune valeur d'écart Lorsqu'un enregistrement de proximité géographique possède une valeur d'écart positive de 50, Route 53 divise par deux la distance entre la source d'une requête et la ressource correspondant à cet enregistrement. Route 53 détermine ensuite par des calculs la ressource la plus proche de la source de la requête. Supposons qu'un serveur Web A se trouve à 150 kilomètres de la source d'une requête et que le serveur Web B se trouve à 100 kilomètres de la source de la requête. Si aucun enregistrement n'avait eu de valeur d'écart, Route 53 aurait acheminé la requête vers le serveur Web B, en raison de sa proximité. Cependant, puisque l'enregistrement pour le serveur Web A s'accompagne d'une valeur d'écart positive de 50, Route 53 considère que le serveur Web A se trouve à 75 kilomètres de la source de la requête. Route 53 va donc acheminer la requête vers le serveur Web A. Voici le calcul pour une valeur d'écart positive de 50 : ``` Bias = 50 Biased distance = actual distance * [1 - (bias/100)] Biased distance = 150 kilometers * [1 - (50/100)] Biased distance = 150 kilometers * (1 - .50) Biased distance = 150 kilometers * (.50) Biased distance = 75 kilometers ``` # Routage basé sur la latence Si votre application est hébergée sur plusieurs sites Régions AWS, vous pouvez améliorer les performances de vos utilisateurs en traitant leurs demandes à partir de la solution Région AWS offrant la latence la plus faible. **Note** Les données relatives à la latence entre les utilisateurs et vos ressources sont entièrement basées sur le trafic entre les utilisateurs et les centres de données AWS . Si vous n'utilisez pas de ressources dans un Région AWS, la latence réelle entre vos utilisateurs et vos ressources peut varier considérablement en fonction des données de AWS latence. Cela est vrai même si vos ressources sont situées dans la même ville qu'une Région AWS. Pour utiliser le routage basé sur la latence, vous créez des enregistrements pour vos ressources dans plusieurs Régions AWS. Lorsque Route 53 reçoit une requête DNS pour votre domaine ou un sous-domaine (exemple.com ou acme.exemple.com), il détermine les Régions AWS pour lesquelles vous avez créé des enregistrements de latence, les régions offrant aux utilisateurs la latence la plus faible, puis sélectionne un enregistrement de latence pour cette région. Route 53 répond avec la valeur de l'enregistrement sélectionné, telle que l'adresse IP d'un serveur Web. Par exemple, si vous disposez d'équilibreurs de charge Elastic Load Balancing dans la région USA Ouest (Oregon) et la région Asie-Pacifique (Singapour). Vous avez créé un enregistrement de latence pour chaque équilibreur de charge. Voici ce qui se produit quand un utilisateur basé à Londres entre le nom de votre domaine dans un navigateur : 1. DNS achemine la requête vers un serveur de noms Route 53. 1. Route 53 se réfère à ses données relatives à la latence entre Londres et la région Singapour, et entre Londres et la région Oregon. 1. Si la latence est inférieure entre les régions de Londres et de l'Oregon, Route 53 répond à la requête avec l'adresse IP de l'équilibreur de charge de l'Oregon. Si la latence est inférieure entre les régions de Londres et de Singapour, Route 53 répond avec l'adresse IP de l'équilibreur de charge de Singapour. La latence entre les hôtes sur Internet peut évoluer au fil du temps, suite à des modifications de connectivité réseau et de routage. Le routage basé sur la latence s'appuie sur des mesures de latence réalisées sur une période donnée. Ces mesures reflètent ces évolutions. Une demande acheminée vers la région de l'Oregon une semaine peut être acheminée vers la région de Singapour la semaine suivante. **Note** Lorsqu'un navigateur ou un autre utilisateur utilise un résolveur DNS qui prend en charge l' edns-client-subnetextension de EDNS0, le résolveur DNS envoie à Route 53 une version tronquée de l'adresse IP de l'utilisateur. Si vous configurez le routage en fonction de la latence, Route 53 tient compte de cette valeur lors de l'acheminement du trafic vers vos ressources. Pour de plus amples informations, veuillez consulter [Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur](routing-policy-edns0.md). Vous pouvez utiliser la stratégie de routage de latence pour des enregistrements dans une zone hébergée privée. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage de latence pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements de latence](resource-record-sets-values-latency.md) + [Valeurs spécifiques aux enregistrements d'alias de latence](resource-record-sets-values-latency-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) # Routage basé sur la latence dans les zones hébergées privées Pour les zones hébergées privées, Route 53 répond aux requêtes DNS avec un point de terminaison Région AWS situé au même endroit ou le plus proche Région AWS du VPC d'où provient la requête. **Note** Si un point de terminaison sortant est transféré vers un point de terminaison entrant, l'enregistrement sera résolu en fonction de l'emplacement du point de terminaison entrant, et non du point de terminaison sortant. Si vous incluez des surveillances de l'état et que l'enregistrement avec la latence la plus faible par rapport à l'origine de la requête est défectueux, un point de terminaison sain avec la latence la plus faible est renvoyé. Dans l'exemple de configuration illustré dans la figure suivante, les requêtes DNS provenant d'un Région AWS us-east-1, ou du plus proche de celui-ci, seront acheminées vers le point de terminaison 1.1.1.1. Les requêtes DNS provenant de la région us-west-2, ou la plus proche de celle-ci, seront acheminées vers le point de terminaison 2.2.2.2. ![\[Une capture d'écran qui montre deux enregistrements de latence pour une zone hébergée privée.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/latency-phz.png) # Routage basé sur IP Avec le routage basé sur IP dans Amazon Route 53, vous pouvez affiner votre routage DNS en utilisant votre compréhension de votre réseau, de vos applications, et de vos clients pour prendre les meilleures décisions de routage DNS pour vos utilisateurs finaux. Le routage basé sur IP vous donne un contrôle granulaire pour optimiser les performances ou réduire les coûts du réseau en téléchargeant vos données sur Route 53 sous forme de mappages. user-IP-to-endpoint Le routage basé sur la géolocalisation et la latence s'appuie sur les données que Route 53 collecte et tient à jour. Cette approche fonctionne bien pour la majorité des clients, mais le routage basé sur IP vous offre la possibilité supplémentaire d'optimiser le routage en fonction de la connaissance spécifique de votre clientèle. Par exemple, un fournisseur mondial de contenu vidéo peut vouloir acheminer les utilisateurs finaux à partir d'un fournisseur de services Internet (FSI) particulier. Voici quelques cas d'utilisation courants du routage basé sur IP : + Vous souhaitez acheminer les utilisateurs finaux de certains points de terminaison ISPs vers des points de terminaison spécifiques afin d'optimiser les coûts ou les performances du réseau. + Vous voulez ajouter des surcharges aux types de routage Route 53 existants, comme le routage de géolocalisation, en fonction de votre connaissance des emplacements physiques de vos clients. **Gérer les plages d'adresses IP et les associer à un ensemble d'enregistrements de ressources (RRSet)** Pour IPv4, vous pouvez utiliser des blocs CIDR d'une longueur comprise entre 1 et 24 bits inclus, tandis que pourIPv6, vous pouvez utiliser des blocs d'adresse CIDR d'une longueur comprise entre 1 et 48 bits inclus. Pour définir un bloc d'adresse CIDR zéro bit (0.0.0.0/0 or ::/0), utilisez l'emplacement par défaut (« \$1 »). Pour les requêtes DNS dont le CIDR est plus long que celui spécifié dans la collection d'adresses CIDR, Route 53 les met en correspondance avec le CIDR le plus court. Par exemple, si vous spécifiez 2001:0 DB8 : :/32 comme bloc CIDR dans votre collection CIDR et qu'une requête provient de 2001:0 DB8 : 0000:1234 : :/48, elle correspondra. Si, par contre, vous spécifiez 2001:0 DB8 : 0000:1234 : :/48 dans votre collection CIDR et qu'une requête provient de 2001:0 DB8 : :/32, cela ne correspondra pas et Route 53 répondra avec l'enregistrement correspondant à l'emplacement par défaut (« \$1 »). Vous pouvez regrouper des jeux de blocs CIDR (ou plages IP) en emplacements CIDR, qui sont à leur tour regroupés en entités réutilisables appelées collections CIDR : **Bloc d'adresse CIDR** Une plage d'adresses IP en notation CIDR, par exemple 192.0.2.0/24 ou 2001 : : :/32. DB8 **Emplacement CIDR** Une liste nommée de blocs CIDR. Par exemple, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001 : : :/32]. DB8 Les blocs d'une liste d'emplacements CIDR ne doivent pas nécessairement être adjacents ou appartenir à la même plage. Un même emplacement peut avoir les deux IPv6 blocs IPv4 et cet emplacement peut être associé à la fois aux ensembles d'enregistrements A et AAAA, respectivement. Le nom de l'emplacement est souvent un emplacement par convention, mais peut être n'importe quelle chaîne, par exemple *Entreprise-A*. **Collection CIDR** Une collection d'emplacements nommée. Par exemple, mycollection = [example-isp-seattle, example-isp-tokyo]. Les jeux d'enregistrements de ressources de routage basé sur IP font référence à un emplacement dans une collection, et tous les jeux d'enregistrements de ressources pour le même nom et type de jeu d'enregistrements doivent faire référence à la même collection. Par exemple, si vous créez des sites Web dans deux régions et que vous voulez diriger les requêtes DNS de deux emplacements CIDR différents vers un site Web spécifique en fonction des adresses IP d'origine, ces deux emplacements doivent être répertoriés dans la même collection CIDR. Vous ne pouvez pas utiliser la politique de routage basée sur IP pour les enregistrements dans une zone hébergée privée. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la politique de routage basée sur IP pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements basés sur IP](resource-record-sets-values-ipbased.md) + [Valeurs spécifiques aux enregistrements d'alias basés sur IP](resource-record-sets-values-ipbased-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) **Topics** + [Création d'une collection CIDR avec des emplacements et des blocs CIDR](resource-record-sets-creating-cidr-collection.md) + [Utilisation des emplacements et des blocs CIDR](resource-record-sets-working-with-cidr-locations.md) + [Suppression d'une collection CIDR](resource-record-sets-delete-cidr-collection.md) + [Déplacement d'un routage par géolocalisation vers un routage basé sur IP](resource-record-sets-move-geolocation-to-cidr.md) # Création d'une collection CIDR avec des emplacements et des blocs CIDR Pour commencer, créez une collection CIDR et ajoutez-y des blocs et des emplacements CIDR. **Pour créer une collection CIDR à l'aide de la console Route 53** 1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), puis **CIDR collections** (Collections CIDR). 1. Sélectionnez **Create CIDR collection** (Créer une collection CIDR). 1. Dans le panneau **Create CIDR collection** (Créer une collection CIDR), sous **Details** (Détails), saisissez un nom pour la collection. 1. Choisissez **Create collection** (Créer une collection) pour créer une collection vide. - ou - Dans la section **Créer des emplacements CIDR**, saisissez le nom de l'emplacement CIDR dans le champ **Emplacement CIDR**. Le nom de l'emplacement peut être n'importe quelle chaîne d'identification, par exemple **company 1** ou **Seattle**. Il ne doit pas nécessairement s'agir d'un emplacement géographique réel. **Important** Le nom de l'emplacement CIDR a une longueur maximale de 16 caractères. Saisissez les blocs d'adresse CIDR dans le champ **Blocs CIDR**, un par ligne. Il peut s'agir IPv4 d' IPv6 adresses comprises entre /0 et /24 pour IPv4 et /0 à /48 pour. IPv6 1. Après avoir saisi les blocs CIDR, choisissez **Create CIDR collection** (Créer une collection CIDR), ou **Add another location** (Ajouter un autre emplacement) pour continuer à saisir des emplacements et un bloc CIDR. Vous pouvez saisir plusieurs emplacements CIDR par collection. 1. Après avoir saisi les emplacements CIDR, choisissez **Create CIDR collection** (Créer une collection CIDR). # Utilisation des emplacements et des blocs CIDR **Pour travailler avec des emplacements CIDR en utilisant la console Route 53** 1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), **CIDR collections** (Collections CIDR), puis, dans la section **CIDR collections** (Collections CIDR), cliquez sur un lien vers une collection CIDR dans la liste **Collection name** (Nom de la collection). Sur la page **CIDR locations** (Emplacements CIDR), vous pouvez créer un emplacement CIDR, le supprimer ou modifier un emplacement et ses blocs. + Pour créer un emplacement, choisissez **Create CIDR location** (Créer un emplacement CIDR). + Dans le panneau **Create CIDR location** (Créer un emplacement CIDR), saisissez un nom pour l'emplacement, les blocs CIDR associés à l'emplacement, puis cliquez sur **Create** (Créer). + Pour afficher un emplacement CIDR et les blocs qu'il contient, choisissez la case d'option en regard d'un emplacement pour afficher son nom et ses blocs CIDR dans le panneau d'emplacement. Dans ce panneau, vous pouvez également choisir **Modifier** pour mettre à jour le nom de l'emplacement ou de ses blocs CIDR. Choisissez **Save** (Enregistrer) lorsque vous avez terminé la modification. + Pour supprimer un emplacement CIDR et les blocs qu'il contient, sélectionnez la case d'option en regard de l'emplacement que vous voulez supprimer, puis cliquez sur **Delete** (Supprimer). Pour confirmer la suppression, saisissez le nom de l'emplacement dans la zone de saisie de texte et sélectionnez à nouveau **Delete** (Supprimer). **Important** La suppression d'un emplacement CIDR ne peut pas être annulée. Si vous avez des enregistrements DNS associés à l'emplacement, votre domaine peut devenir inaccessible. # Suppression d'une collection CIDR **Pour supprimer une collection CIDR, ses emplacements et blocs en utilisant la console Route 53** 1. Connectez-vous à la console Route 53 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/). 1. Dans le panneau de navigation, choisissez **IP-based routing** (Routage basé sur IP), puis **CIDR collections** (Collections CIDR). 1. Dans la section **CIDR collections** (Collections CIDR), cliquez sur le nom lié de la collection que vous voulez supprimer. 1. Sur la page **CIDR locations** (Emplacements CIDR), sélectionnez chaque emplacement un par un, choisissez **Delete** (Supprimer), saisissez son nom dans la boîte de dialogue, puis choisissez **Delete** (Supprimer). Vous devez supprimer chaque emplacement associé à une collection CIDR avant de pouvoir supprimer la collection. 1. Une fois la suppression de chaque emplacement CIDR terminée, sur la page **CIDR locations** (Emplacements CIDR), choisissez le bouton radio en regard de la collection que vous voulez supprimer, puis choisissez **Delete** (Supprimer). # Déplacement d'un routage par géolocalisation vers un routage basé sur IP Si vous utilisez des politiques de routage par géolocalisation ou par géoproximité et que vous constatez régulièrement que des clients spécifiques sont acheminés vers un point de terminaison qui n'est pas optimal en fonction de leur emplacement physique ou de la topologie du réseau, vous pouvez mieux cibler les plages IP publiques de ces clients en utilisant le routage par IP. Le tableau suivant contient un exemple de configuration de géolocalisation pour un routage de géolocalisation existant que nous allons acheminer avec précision pour les plages IP de Californie. | Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application | | --- | --- | --- | | example.com | Routage par géolocalisation (US) | `198.51.100.1` | | example.com | Routage par géolocalisation (UE) | `198.51.100.2` | Pour remplacer les plages IP de Californie par un nouveau point de terminaison d'application, recréez d'abord le routage de géolocalisation sous un nouveau nom de jeu d'enregistrements. | Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application | | --- | --- | --- | | geo.example.com | Routage par géolocalisation (US) | `198.51.100.1` | | geo.example.com | Routage par géolocalisation (UE) | `198.51.100.2` | Créez ensuite des enregistrements de routage basés sur IP et un enregistrement par défaut qui pointe vers votre jeu d'enregistrements de routage de géolocalisation récemment recréé. | Nom du jeu d'enregistrements | Politique et origine du routage | Adresse IP du point de terminaison de l'application | | --- | --- | --- | | example.com | Routage basé sur IP (par défaut) | Enregistrement d'alias vers le point de terminaison de l'application geo.example.com que vous voulez être le point par défaut. Par exemple, `198.51.100.1`. | | example.com | Routage basé sur IP (plages IP de Californie) | `198.51.100.3` | # Multivalue answer routing (Routage de réponse multivaleur) Le routage de réponse multivaleur vous permet de configurer Amazon Route 53 pour renvoyer plusieurs valeurs, comme des adresses IP pour vos serveurs web, en réponse aux requêtes DNS. Vous pouvez spécifier plusieurs valeurs pour la plupart des enregistrements, mais le routage de réponse multivaleur vous permet également de vérifier l'intégrité de chaque ressource. Route 53 renvoie donc uniquement les valeurs des ressources saines. Il ne constitue pas de substitut pour un équilibreur de charge, mais la capacité de retourner plusieurs adresses IP dont l'intégrité est vérifiable permet d'utiliser DNS pour améliorer la disponibilité et l'équilibrage de charge. Pour acheminer le trafic approximativement de manière aléatoire vers plusieurs ressources, comme des serveurs web, vous créez un enregistrement de réponse multivaleur pour chaque ressource et, facultativement, vous associez une surveillance de l'état Route 53 à chaque enregistrement. Route 53 répond aux requêtes DNS par jusqu'à huit enregistrements et fournit des réponses distinctes aux différents résolveurs DNS. Si un serveur web devient indisponible après qu'un résolveur met une réponse en cache, le logiciel client peut essayer une autre adresse IP dans la réponse. Notez ce qui suit : + Si vous associez une surveillance de l'état à un enregistrement de réponse multivaleur, Route 53 répond aux requêtes DNS avec l'adresse IP correspondante uniquement lorsque la surveillance de l'état est saine. + Si vous n'associez pas de surveillance de l'état à un enregistrement de réponse multivaleur, Route 53 considère toujours l'enregistrement comme sain. + Si vous disposez de huit enregistrements sains ou moins, Route 53 répond à toutes les requêtes DNS par tous les enregistrements sains. + Lorsque tous les registres sont non sains, Route 53 répond à toutes les requêtes DNS par jusqu'à huit registres non sains. Vous pouvez utiliser la stratégie de routage de réponse multivaleur pour des enregistrements dans une zone hébergée privée. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la politique de routage de réponse multivaleur pour créer des enregistrements, veuillez consulter [Valeurs spécifiques pour les enregistrements de réponses multivaleur](resource-record-sets-values-multivalue.md) et [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md). # Weighted routing (Routage pondéré) Le routage pondéré vous permet d'associer plusieurs ressources à un nom de domaine unique (par exemple, example.com) ou à un nom de sous-domaine (par exemple, acme.example.com) et de choisir le volume de trafic acheminé vers chaque ressource. Cela peut vous être utile pour de nombreuses actions, notamment l'équilibrage de charge et le test de nouvelles versions de logiciels. Pour configurer un acheminement pondéré, créez des enregistrements avec les mêmes valeurs pour les champs Nom et Type que celles de vos ressources. Vous attribuez à chaque enregistrement une pondération relative correspondant au volume de trafic à envoyer à chaque ressource. Amazon Route 53 retourne le trafic vers une ressource en fonction de la pondération attribuée à l'enregistrement par rapport au poids total des enregistrements dans le groupe : ![\[Formule pour le calcul de la quantité de trafic acheminée vers une ressource donnée : poids d'un enregistrement spécifié/somme des poids de tous les enregistrements.\]](http://docs.aws.amazon.com/fr_fr/Route53/latest/DeveloperGuide/images/WRR_calculation.png) Par exemple, si vous souhaitez envoyer une petite partie de votre trafic vers une ressource et que le reste soit acheminé vers une autre ressource, vous pouvez spécifier des pondérations de 1 à 255. La ressource ayant une pondération de 1 obtient 1/256e du trafic (1/(1\$1255)) et l'autre ressource obtient 255/256e (255/(1\$1255)). Vous pouvez progressivement modifier l'équilibre en changeant les pondérations. Si vous arrêtez d'envoyer du trafic vers une ressource, vous pouvez passer la pondération de cette ressource à 0. Pour plus d'informations sur les valeurs que vous spécifiez lorsque vous utilisez la stratégie de routage pondéré pour créer des enregistrements, consultez les rubriques suivantes : + [Valeurs spécifiques aux enregistrements pondérés](resource-record-sets-values-weighted.md) + [Valeurs spécifiques aux enregistrements d'alias pondérés](resource-record-sets-values-weighted-alias.md) + [Valeurs communes à toutes les politiques de routage](resource-record-sets-values-shared.md) + [Valeurs communes aux enregistrements d'alias pour toutes les politiques de routage](resource-record-sets-values-alias-common.md) Vous pouvez utiliser la stratégie de routage pondéré pour des enregistrements dans une zone hébergée privée. ## Surveillance de l'état et routage pondéré Si vous ajoutez les surveillances de l'état à tous les enregistrements d'un groupe d'enregistrements pondérés, mais que vous attribuez des pondérations différentes de zéro à certains enregistrements et des pondérations égales à zéro pour d'autres, les surveillances de l'état fonctionnent de la même manière que lorsque tous les enregistrements ont des pondérations différentes de zéro, avec les exceptions suivantes : + Initialement, Route 53 prend uniquement en compte les enregistrements pondérés dont la pondération est différente de zéro, s'il y en a. + Si tous les enregistrements ayant une pondération supérieure à 0 ne sont pas sains, Route 53 prend en compte les enregistrements dont la pondération est égale à zéro. Le tableau suivant détaille le comportement lorsque l'enregistrement à pondération nulle inclut une surveillance de l'état : | | Enregistrement 1 | Enregistrement 2 | Enregistrement 3 | | --- |--- |--- |--- | | Pondération | 1 | 1 | 0 | | Comprend la surveillance de l'état ? | Oui | Oui | Oui | | | | --- | | Statut de la surveillance de l'état | Non sain | Non sain | Sain | | Requête DNS répondue ? | Non | Non | Oui | | | | --- | | Statut de la surveillance de l'état | Non sain | Non sain | Non sain | | Requête DNS répondue ? | Oui | Oui | Non | | | | --- | | Statut de la surveillance de l'état | Non sain | Sain | Non sain | | Requête DNS répondue ? | Non | Oui | Non | | | | --- | | Statut de la surveillance de l'état | Sain | Sain | Non sain | | Requête DNS répondue ? | Oui | Oui | Non | | | | --- | | Statut de la surveillance de l'état | Sain | Sain | Sain | | Requête DNS répondue ? | Oui | Oui | Non | Le tableau suivant détaille le comportement lorsque l'enregistrement à pondération nulle n'inclut pas une surveillance de l'état : | | Enregistrement 1 | Enregistrement 2 | Enregistrement 3 | | --- |--- |--- |--- | | Pondération | 1 | 1 | 0 | | Comprend la surveillance de l'état ? | Oui | Oui | Non | | | | --- | | Statut de la surveillance de l'état | Sain | Sain | N/A | | Requête DNS répondue ? | Oui | Oui | Non | | | | --- | | Statut de la surveillance de l'état | Non sain | Non sain | N/A | | Requête DNS répondue ? | Non | Non | Oui | | | | --- | | Statut de la surveillance de l'état | Non sain | Sain | N/A | | Requête DNS répondue ? | Non | Oui | Non | # Utilisation d'Amazon Route 53 EDNS0 pour estimer la position d'un utilisateur Pour améliorer la précision de la géolocalisation, de la géoproximité, du routage basé sur IP et du routage par latence, Amazon Route 53 prend en charge l'extension de. edns-client-subnet EDNS0 (EDNS0 ajoute plusieurs extensions facultatives au protocole DNS.) Route 53 ne peut être utilisée edns-client-subnet que lorsque les résolveurs DNS la prennent en charge : + Lorsqu'un navigateur ou un autre lecteur utilise un résolveur DNS non compatible edns-client-subnet, Route 53 utilise l'adresse IP source du résolveur DNS pour localiser approximativement l'utilisateur et répond aux requêtes de géolocalisation avec l'enregistrement DNS correspondant à l'emplacement du résolveur. + Lorsqu'un navigateur ou un autre utilisateur utilise un résolveur DNS compatible edns-client-subnet, le résolveur DNS envoie à Route 53 une version tronquée de l'adresse IP de l'utilisateur. Route 53 détermine l'emplacement de l'utilisateur en fonction de l'adresse IP tronquée plutôt que de l'adresse IP source du résolveur DNS ; cela fournit généralement une estimation plus précise de l'emplacement de l'utilisateur. Route 53 répond ensuite aux requêtes de géolocalisation avec l'enregistrement DNS correspondant à l'emplacement de l'utilisateur. + EDNS0 ne s'applique pas aux zones hébergées privées. Pour les zones hébergées privées, Route 53 utilise les données des résolveurs VPC dans lesquels se trouve la Région AWS zone hébergée privée pour prendre des décisions de géolocalisation et de routage par latence. Pour plus d'informations edns-client-subnet, consultez la RFC relative au sous-réseau du client EDNS, sous-réseau [client dans les demandes](https://www.rfc-editor.org/rfc/rfc7871) DNS.