Aller au contenu

AWS Mis à jour le 2026-07-04

Vérifications de l'état Route 53 et bascule DNS : un montage qui fonctionne quand une région tombe

Comment configurer les vérifications de l'état et le routage de bascule Route 53 pour que le trafic bouge vraiment quand le point de terminaison primaire meurt — incluant les détails de TTL et d'alias qui décident si ça marche.

La bascule DNS sur Route 53, c’est trois pièces qui travaillent ensemble : une vérification de l’état qui surveille le point de terminaison primaire depuis l’extérieur, une paire d’enregistrements avec la politique de routage de bascule (primaire et secondaire), et des TTL assez bas pour que les résolveurs remarquent le changement. Manquez une des trois et vous obtenez l’échec classique : la vérification passe au rouge, l’enregistrement bascule, et le trafic continue de marteler le primaire mort pendant une heure parce que le TTL était à 3600.

Ce qui se passe

Les vérificateurs de Route 53 tournent depuis de nombreux emplacements dans le monde, hors de votre infrastructure. Chaque vérificateur sonde votre point de terminaison à son propre rythme — toutes les 30 secondes à l’intervalle standard, toutes les 10 à l’intervalle rapide, qui coûte plus cher — et le point de terminaison est considéré sain tant que plus de 18 % des vérificateurs rapportent un succès. Cette conception distribuée fait qu’un chemin de transit capricieux ne vous bascule pas, mais elle exige aussi que les vérificateurs puissent atteindre le point de terminaison : une vérification contre une IP privée ou un groupe de sécurité qui n’admet pas les plages d’IP des vérificateurs Route 53 restera malsaine pour toujours.

Trois types de vérifications existent. Les vérifications de point de terminaison sondent une IP ou un nom d’hôte en HTTP, HTTPS ou TCP, avec en option la recherche d’une chaîne dans les 5 120 premiers octets du corps de la réponse. Les vérifications calculées combinent d’autres vérifications avec de la logique booléenne. Les vérifications par alarme CloudWatch suivent l’état d’une alarme — la porte de sortie pour les ressources privées : les vérificateurs ne touchent jamais au point de terminaison, ils regardent la métrique.

Pour les enregistrements alias, un quatrième mécanisme remplace souvent complètement la vérification explicite : Evaluate target health. Un alias vers un ALB avec ce drapeau hérite de l’état des cibles du répartiteur : si toutes les cibles derrière l’ALB échouent, Route 53 traite l’enregistrement comme malsain sans vérificateur séparé.

La politique de routage de bascule fait ensuite quelque chose de simple : répondre avec l’enregistrement primaire tant qu’il est sain, répondre avec le secondaire quand il ne l’est plus. Le secondaire peut être une autre région, une page de maintenance statique sur S3/CloudFront, ou une réserve à capacité réduite.

Quoi vérifier en premier

  • Les vérificateurs peuvent-ils atteindre le point de terminaison? Il doit être joignable publiquement, et tout pare-feu doit admettre les plages d’IP publiées des vérificateurs Route 53.
  • La vérification est-elle attachée à l’enregistrement? Une vérification qui existe mais n’est pas associée à l’enregistrement primaire de bascule ne change rien.
  • Quel est le TTL? La vitesse de bascule = temps de détection plus TTL. Soixante secondes est le choix habituel pour les enregistrements de bascule.
  • Le secondaire fonctionne-t-il vraiment? Une réserve que personne n’a testée est une deuxième panne qui attend derrière la première.

Comment vérifier

Créez les pièces, puis interrogez-les :

# Statut de la vérification vu par chaque emplacement de vérification
aws route53 get-health-check-status --health-check-id 11111111-2222-3333-4444-555555555555

# Ce que Route 53 répondra maintenant pour l'enregistrement de bascule
aws route53 test-dns-answer --hosted-zone-id Z0123456789ABC \
  --record-name app.example.com --record-type A

Dans la console, Route 53 > Health checks montre le statut et un onglet Monitoring avec le pourcentage de santé dans le temps; la métrique HealthCheckStatus atterrit aussi dans CloudWatch (us-east-1, peu importe où tourne votre charge de travail), donc vous pouvez créer une alarme dessus — branchez-la sur le même chemin de notification que le reste de votre base d’alarmes CloudWatch.

Puis faites le seul test qui compte, en fenêtre de maintenance : tuez le primaire (arrêtez le service, ou bloquez la plage des vérificateurs au pare-feu) et chronométrez jusqu’à ce que dig +short app.example.com @8.8.8.8 retourne la réponse du secondaire. Ce chiffre — détection plus TTL — est votre vrai temps de bascule.

Le runbook

  1. Créez la vérification contre le primaire. Type HTTPS, le vrai nom d’hôte dans le champ Host name pour que SNI et les hôtes virtuels fonctionnent, un chemin comme /healthz qui exerce l’application plutôt que juste le port TCP, et une correspondance de chaîne sur un jeton connu du corps si le point de terminaison peut retourner un 200 avec une page d’erreur.
  2. Pointez-la vers quelque chose de significatif. Une vérification sur / qui retourne 200 depuis un cache CDN pendant que l’origine est à terre ne vous dit rien. Vérifiez la couche que vous comptez basculer.
  3. Créez l’enregistrement primaire. Alias vers l’ALB ou la distribution CloudFront primaire, politique de routage Failover, type de bascule Primary, et soit l’ID de vérification attaché, soit Evaluate target health activé — un des deux, choisi délibérément.
  4. Créez l’enregistrement secondaire. Même nom et même type, type de bascule Secondary. Aucune vérification n’est requise sur le secondaire, mais en ajouter une vous fait découvrir que la réserve est cassée avant le jour où vous en avez besoin.
  5. Réglez les TTL pour la bascule, pas pour l’efficacité du cache. Soixante secondes sur les enregistrements de bascule non-alias. Les alias héritent du TTL de la cible, déjà court pour les cibles ALB et CloudFront.
  6. Testez la bascule dans les deux sens. Basculez, vérifiez, revenez. Route 53 retourne automatiquement au primaire dès que sa vérification récupère — assurez-vous que l’application tolère ce battement, ou encadrez le retour derrière un seuil d’échec plus long.

Quand c’est la mauvaise approche

La bascule DNS est le bon outil pour une panne de région ou de site, et le mauvais outil pour tout ce qui doit aller plus vite. Les résolveurs et les systèmes d’exploitation gardent les réponses en cache au-delà de votre TTL plus souvent que les standards le prétendent : planifiez des minutes de drainage, pas des secondes. Si vous avez besoin d’une bascule au niveau connexion dans une même région, c’est le travail du répartiteur de charge, pas du DNS. Si c’est la base de données qui bascule, le DNS n’est que la dernière étape — la décision de la couche de données vient d’abord, et c’est une question de conception Multi-AZ contre multi-région. Et pour une charge de travail qui ne tolère aucune vérification manuelle avant le retour, un montage actif-actif pondéré convient peut-être mieux que primaire/secondaire.

Erreurs fréquentes

  • Vérifier directement un point de terminaison privé au lieu d’utiliser une vérification par alarme CloudWatch, puis faire confiance à une vérification qui ne peut jamais réussir — ni jamais échouer.
  • Laisser le TTL par défaut sur l’enregistrement de bascule, ce qui transforme une détection de 90 secondes en panne d’une heure.
  • Pointer la vérification vers une page statique qui reste debout pendant que l’application derrière est à terre.
  • Ne jamais répéter la bascule : le secondaire a une configuration périmée, des secrets manquants ou un certificat expiré quand il reçoit enfin du trafic.

Prévention

  • Créez une alarme sur la métrique HealthCheckStatus de la vérification elle-même, pour qu’une vérification au rouge alerte un humain même quand la bascule fonctionne.
  • Répétez la bascule chaque trimestre et notez le temps mesuré de bout en bout.
  • Déployez le secondaire depuis le même pipeline que le primaire pour qu’il ne dérive pas.
  • Revérifiez l’accessibilité des vérificateurs après tout changement de pare-feu ou de WAF — bloquer les vérificateurs est une bascule auto-infligée.
  • Documentez la décision de retour : automatique à la récupération de la vérification, ou manuelle après validation.

La tarification des vérifications est par vérification par mois, avec l’intervalle rapide, le HTTPS et la correspondance de chaîne facturés comme options — les détails sont dans la documentation Route 53. 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.