Politiques de routage Route 53 décodées : pondéré, latence, géolocalisation, bascule

Route 53 offre le routage simple, pondéré, par latence, de bascule, par géolocalisation, par géoproximité, à réponses multiples et par IP — et le conseil honnête, c’est que la plupart des charges de travail en production en ont besoin d’exactement deux : simple (ou un alias, qui se comporte comme simple) pour tout ce qui a une seule cible, et pondéré ou bascule quand une deuxième cible apparaît. Latence et géolocalisation ne gagnent leur place que lorsque vous exploitez réellement le même service dans plusieurs régions. Choisir la politique, c’est en réalité choisir pourquoi deux réponses existent pour un même nom.

Ce que vous décidez

Chaque politique de routage répond différemment à la même question : quand un résolveur demande app.example.com, quel enregistrement Route 53 retourne-t-il?

Simple — l’unique enregistrement, toujours. Aucune conscience de l’état : si la cible est à terre, Route 53 répond quand même avec elle.
Pondéré — vous assignez à chaque enregistrement un poids de 0 à 255 et Route 53 les retourne en proportion. C’est la politique de partage de trafic : un canari sur une nouvelle pile à 5 %, une migration de fournisseur 10 % à la fois, ou un enregistrement stationné à poids 0 pour le garder configuré mais inactif. Des vérifications de l’état peuvent être attachées pour qu’un enregistrement malsain sorte de la rotation.
Latence — Route 53 répond avec l’enregistrement de la région ayant la plus faible latence réseau mesurée depuis le réseau du résolveur. Notez ce que ce n’est pas : ce n’est ni la distance géographique ni une promesse; c’est basé sur les mesures de latence d’AWS entre réseaux et régions, et les usagers sur un RPV ou derrière un résolveur d’entreprise lointain reçoivent la réponse qui convient au résolveur, pas à la personne.
Bascule — le primaire tant qu’il est sain, le secondaire sinon. Couvert en profondeur dans le guide des vérifications de l’état et de la bascule DNS.
Géolocalisation — répond selon la provenance de la requête (continent, pays ou État américain), avec un enregistrement par défaut pour tous les non-appariés. C’est la politique de conformité et de droits de contenu : les usagers de l’UE vers la pile UE, tous les autres vers le défaut. Créez toujours l’enregistrement par défaut — sinon, les requêtes des emplacements non appariés ne reçoivent aucune réponse du tout.
Géoproximité — route selon la distance géographique vers vos ressources, avec un biais réglable pour déplacer la frontière. Niché; la plupart des équipes qui s’en emparent voulaient en fait latence ou géolocalisation.
Réponses multiples — retourne jusqu’à huit enregistrements sains, et le client choisit. Un répartiteur de charge du pauvre : utile pour des flottes sans état sans LB, pas un remplacement.
Par IP — associe des blocs CIDR du résolveur à des enregistrements. Pour diriger des réseaux connus (ce FAI ou cette plage de bureau vers là). Rare par conception.

La vraie décision a une forme : pourquoi plus d’une réponse existe-t-elle? Si la deuxième cible est une réserve, c’est la bascule. Si c’est une expérience en pourcentage ou une migration, le pondéré. Si les deux cibles sont vivantes en permanence dans des régions différentes pour la performance, la latence. Si la loi ou les licences dictent qui va où, la géolocalisation — parce que le routage par latence enverra joyeusement un usager allemand vers us-east-1 si le chemin est plus rapide, ce qui est un gain de performance et un incident de conformité.

Quoi vérifier en premier

Combien de cibles vivantes existent, vraiment? Une seule cible signifie simple/alias, et toute politique plus sophistiquée est de la dette de configuration.
Le partage relève-t-il de la performance ou des règles? La performance dit latence; les règles disent géolocalisation. Elles divergent aux marges, et les marges, c’est là que vivent les avocats.
Les enregistrements ont-ils des vérifications de l’état? Pondéré, latence et géolocalisation les supportent sans les exiger — sans vérification, Route 53 continue de répondre avec une cible morte.
Y a-t-il un enregistrement par défaut? La géolocalisation sans défaut envoie silencieusement les pays non appariés dans un trou noir.

Comment vérifier

Inspectez ce qui existe et ce que Route 53 répondrait :

# Voir chaque enregistrement et sa configuration de routage
aws route53 list-resource-record-sets --hosted-zone-id Z0123456789ABC \
  --query "ResourceRecordSets[?Name=='app.example.com.'].[Type,SetIdentifier,Weight,Region,GeoLocation,Failover,HealthCheckId]" \
  --output table

# Demander à Route 53 ce qu'il répondrait pour un emplacement de résolveur donné
aws route53 test-dns-answer --hosted-zone-id Z0123456789ABC \
  --record-name app.example.com --record-type A \
  --edns0-client-subnet-ip 203.0.113.0 --edns0-client-subnet-mask 24

Le drapeau --edns0-client-subnet-ip est le bijou sous-utilisé ici : il simule une requête depuis un réseau précis, la seule façon sensée de tester les réponses de géolocalisation et de latence sans une collection de RPV. Dans la console, la politique de chaque enregistrement s’affiche dans Route 53 > Hosted zones > example.com sous la colonne Routing policy; les enregistrements partageant nom et type doivent chacun porter un Record ID (identifiant d’ensemble) unique.

L’approche

Commencez avec simple ou alias et restez-y jusqu’à ce qu’une deuxième cible vivante existe. Ajouter une politique plus tard est facile; démonter un montage géoproximité spéculatif ne l’est pas.
Utilisez le pondéré pour tout ce qui est graduel. Déploiements canari, bascule bleu/vert à la couche DNS, migrations de fournisseur. Passez 5 → 25 → 50 → 100 en surveillant les taux d’erreur entre les étapes. Le poids 0 garde l’ancienne cible à une modification de sa restauration.
Ajoutez des vérifications de l’état à chaque enregistrement non simple. Les politiques distribuent les réponses; seules les vérifications retirent les mortes. Une paire pondérée sans vérifications fait échouer 50 % de vos usagers quand un côté meurt.
Ne prenez la latence qu’avec du vrai multi-région. Deux piles complètes, données répliquées, testées indépendamment. Le routage par latence par-dessus une base de données mono-région est une décoration — le travail de fond de la reprise après sinistre inter-régions vient d’abord.
Utilisez la géolocalisation quand l’exigence est légale, pas technique. Et écrivez l’enregistrement par défaut dans le même lot de changements que la première règle de pays, pas dans un billet de suivi.
Combinez les politiques par chaînage d’alias quand ça se complexifie. Un ensemble d’enregistrements par latence peut pointer en alias vers des paires de bascule par région — la latence choisit la région, la bascule survit à l’intérieur. Dessinez l’arbre sur papier avant de le bâtir dans la zone.

Quand c’est la mauvaise approche

Les politiques de routage DNS dirigent des résolveurs, pas des usagers, et elles les dirigent lentement. Si vous avez besoin d’un contrôle par requête — sessions persistantes, routage par en-tête, déploiement graduel avec retour instantané — ça appartient à la couche répartiteur de charge ou CDN, pas au DNS. Le routage par latence est aussi le mauvais instrument pour diriger les coûts, puisque vous ne pouvez ni voir ni plafonner quelle région gagne. Et les réponses multiples ne sont pas de la répartition de charge : pas de drainage de connexions, aucune garantie de distribution égale, un comportement de réessai côté client que vous ne contrôlez pas.

Erreurs fréquentes

La géolocalisation sans enregistrement par défaut, découverte quand un pays auquel personne n’avait pensé rapporte que le site n’existe pas.
Des enregistrements pondérés sans vérifications de l’état : le canari continue de recevoir ses 5 % pendant qu’il brûle.
S’attendre à ce que le routage par latence respecte la résidence des données — il optimise le temps d’aller-retour et rien d’autre.
Oublier que les poids sont des proportions, pas des pourcentages : deux enregistrements à 10 et 30 partagent 25/75, pas 10/30.

Garder le contrôle

Documentez, pour chaque nom à enregistrements multiples, une phrase : pourquoi plus d’une réponse existe.
Créez des alarmes sur les vérifications de l’état qui soutiennent les enregistrements routés, pas seulement sur les points de terminaison.
Testez les réponses de géolocalisation et de latence avec test-dns-answer et la simulation de sous-réseau client après chaque changement.
Passez la zone en revue chaque trimestre pour les restes à poids 0 et les identifiants d’ensemble dont personne ne se souvient.

La référence complète des politiques vit dans la documentation Route 53, et elle mérite une lecture avant la réunion d’architecture plutôt que pendant l’incident. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.