Résumé

  • Lorsque les enregistrements principal et secondaire possèdent chacun un contrôle de santé et sont tous deux déclarés défaillants, Route 53 répond avec le principal.
  • AWS conserve ainsi une possibilité de connexion malgré un contrôle erroné ou une cascade de surcharge. La décision d’accepter une opération métier reste à concevoir chez le client.

La case que la démonstration oublie

Le scénario de présentation est impeccable : on coupe le site principal, le secondaire prend la relève et la réunion se termine. Le dispositif a prouvé qu’il savait choisir un survivant. Il reste une question moins photogénique : que choisit-il lorsque les deux candidats portent une étiquette rouge ?

Pour une configuration de basculement dont les deux enregistrements ont un contrôle de santé, la documentation de Route 53 donne une réponse précise. Principal sain : principal. Principal défaillant, secondaire sain : secondaire. Les deux défaillants : principal. Le premier candidat revient au guichet sans avoir réussi son examen de santé. Règles de sélection des enregistrements

L’adresse revient dans la réponse DNS ; l’état de santé ne bénéficie d’aucune amnistie. Une application joignable à cette adresse devra encore traiter la requête. C’est exactement à cet endroit que se séparent deux engagements souvent achetés ensemble : trouver une destination et obtenir un résultat utile.

Le mot « secours » encourage une image confortable, celle d’une porte qui ne s’ouvre que sur une pièce habitable. Route 53 organise un choix entre des réponses. Son comportement de dernier recours exprime une préférence pour une tentative supplémentaire, même lorsque les observations sont défavorables.

La bonne raison de ne pas condamner toutes les portes

AWS explique ce choix sans mystère. Un contrôle mal configuré peut juger malade une application qui sert encore ses utilisateurs. Supprimer toutes les réponses transformerait alors une erreur de mesure en interruption imposée. Le service conserve une réponse plutôt que de faire disparaître toute destination. Explication du dernier recours

Le fournisseur propose aussi un exemple de surcharge. Un premier point de terminaison sur trois échoue ; les deux autres absorbent davantage de travail et échouent à leur tour. Répartir de nouveau les demandes entre les trois peut laisser plus de chances que leur exclusion collective. Il s’agit du raisonnement documenté par AWS, pas du récit d’une panne mesurée chez un client.

Cette logique mérite d’être prise au sérieux. Un capteur n’est pas un oracle. Lui donner un droit de fermeture absolu revient à rendre la disponibilité dépendante de sa propre exactitude. Maintenir une adresse peut sauver une consultation que le contrôle aurait condamnée à tort.

L’acheteur doit cependant choisir la valeur de cette chance. Un lecteur qui recharge une documentation et un client qui confirme une opération irréversible n’exposent pas l’entreprise au même coût. L’application doit savoir quelles actions elle accepte dans son état dégradé. Cette règle appartient au produit vendu aux utilisateurs, même si l’incident commence sur un tableau de bord d’infrastructure.

Ce que le contrôle sait vraiment

Les contrôles d’extrémité de Route 53 s’exécutent à intervalles de dix ou trente secondes, avec des vérificateurs indépendants. Ils ne recommencent pas un examen complet à chaque question DNS. Leur travail produit une observation périodique dont le routage se sert. Critères de santé

Le client configure notamment le protocole et le seuil d’échecs consécutifs. Un succès avant d’atteindre ce seuil remet le compteur d’échecs à zéro. Les notifications, éventuellement organisées avec CloudWatch et SNS, signalent un état ; la sélection des enregistrements obéit à ses propres règles. Fonctionnement des contrôles

Un résultat HTTP acceptable peut être utile sans raconter l’histoire entière d’une commande, d’une écriture ou d’une consultation authentifiée. La documentation précise même que les contrôles HTTPS ne valident pas les certificats SSL/TLS. L’étiquette « sain » résume donc une épreuve définie, avec ses limites concrètes.

La configuration du secondaire compte tout autant. Un enregistrement sans contrôle est considéré comme sain. Si seul le principal est contrôlé et devient défaillant, Route 53 peut retourner le secondaire même si celui-ci rencontre réellement un problème. L’absence d’observation rend le candidat admissible ; elle ne répare aucun serveur.

Ces détails ont une conséquence commerciale. Deux destinations, deux sondes et deux chaînes capables d’achever le travail constituent trois achats différents. Une entreprise peut posséder les deux premiers et découvrir trop tard qu’une dépendance commune empêche le troisième.

Le véritable procès-verbal de réception

La réception d’un dispositif de secours doit contenir la case « tous deux défaillants ». Dans un environnement de test maîtrisé, l’équipe peut confronter l’état des contrôles, les réponses DNS reçues et les actions que l’application laisse terminer. Le résultat recherché est une conduite métier définie, pas une jolie couleur.

Les informations de la console — état, adresse du vérificateur, motif et heure du dernier échec pour les contrôles concernés — fournissent des pièces utiles à cette comparaison. Les contrôles calculés ont leurs exceptions. Consultation des états

Il faut également conserver le point d’observation. AWS avertit qu’une partition du réseau peut donner aux emplacements de Route 53 des vues de santé différentes, y compris différentes de celle de CloudWatch. La capture d’un écran central ne suffit donc pas à raconter toutes les réponses vues ailleurs.

Les documents officiels ne donnent pas le taux de réussite d’un client particulier dans cet état ; une analyse d’incident demanderait ses réponses DNS et ses résultats applicatifs au même moment.

Pour l’achat, la leçon est déjà exploitable. AWS expose son choix de dernier recours. Le client doit exposer le sien. Une réponse DNS livre une adresse ; seule l’entreprise peut décider si le service qui attend derrière est encore autorisé à prendre un engagement.