Vérifications de l’état et basculement DNS

Les contrôles d’intégrité de Route 53 surveillent en continu l’état de vos points de terminaison : serveurs web, équilibreurs de charge ou tout point de terminaison HTTP/HTTPS/TCP accessible sur Internet. Selon les résultats des contrôles d’intégrité, Route 53 peut mettre automatiquement à jour le routage DNS afin d’éviter d’envoyer du trafic vers des ressources défaillantes.

Les contrôles d’intégrité sont facturés pour chaque contrôle et chaque mois. Les vérificateurs d’intégrité mondiaux de Route 53, situés dans plusieurs Regions, testent votre point de terminaison simultanément, ce qui assure une redondance du contrôle d’intégrité lui-même. Un point de terminaison est considéré comme défaillant uniquement lorsqu’un nombre seuil de vérificateurs confirme sa défaillance.

Les contrôles d’intégrité des points de terminaison surveillent une adresse IP ou un nom de domaine précis avec le protocole de votre choix (HTTP, HTTPS ou TCP), un port et éventuellement un chemin. Pour les contrôles HTTP/HTTPS, Route 53 vérifie que le point de terminaison renvoie un code d’état HTTP 2xx ou 3xx dans le délai d’expiration. Pour les contrôles HTTPS, il peut également valider le certificat TLS.

Principales options de configuration : intervalle de requête (10 ou 30 secondes : 10 secondes permettent une détection plus rapide, mais coûtent davantage), seuil d’échec (1 à 10 échecs consécutifs avant de marquer le point de terminaison comme défaillant) et correspondance de chaîne (vérification facultative de la présence d’une chaîne précise dans le corps de la réponse).

Les contrôles d’intégrité calculés combinent les résultats de plusieurs contrôles d’intégrité enfants à l’aide de la logique booléenne (AND, OR, NOT). Ils vous permettent de définir l’état d’une application à partir de plusieurs signaux sans créer de chaînes de routage complexes.

Exemple : une application web est saine uniquement si le contrôle du serveur d’API ET celui de la base de données réussissent. Créez un contrôle d’intégrité calculé avec le type AND qui fait référence aux deux contrôles de points de terminaison. Si l’un des deux échoue, le contrôle d’intégrité calculé échoue et Route 53 supprime l’enregistrement DNS associé des réponses.

Les contrôles d’intégrité fondés sur les alarmes CloudWatch associent un contrôle d’intégrité Route 53 à l’état d’une alarme CloudWatch. Si l’alarme est à l’état ALARM, le contrôle d’intégrité est marqué comme défaillant ; si elle est à l’état OK ou INSUFFICIENT_DATA, il est marqué comme sain.

Ce modèle est particulièrement utile pour les points de terminaison situés dans un VPC, que les vérificateurs d’intégrité externes de Route 53 ne peuvent pas atteindre. Au lieu de tester le point de terminaison privé, vous créez des métriques et des alarmes CloudWatch correspondantes, puis vous fondez le contrôle d’intégrité Route 53 sur l’état de l’alarme. Cela permet également d’effectuer des contrôles d’intégrité fondés sur des métriques métier, comme le taux d’erreur ou la profondeur d’une file d’attente.

Les vérificateurs d’intégrité Route 53 sont des serveurs gérés par AWS situés à l’extérieur de votre VPC, qui atteignent les points de terminaison via Internet public. Les ressources des sous-réseaux privés sont inaccessibles aux contrôles d’intégrité standard des points de terminaison. Pour les points de terminaison privés, utilisez l’une des approches suivantes :

• Publiez une métrique CloudWatch personnalisée depuis l’intérieur du VPC (par exemple, un signal de réussite ou d’échec provenant de l’application), créez une alarme et utilisez un contrôle d’intégrité fondé sur une alarme CloudWatch
• Utilisez une alarme composite CloudWatch qui agrège les métriques ELB, RDS ou celles de l’application à l’intérieur du VPC

Ce modèle est essentiel pour les bases de données des sous-réseaux privés, les équilibreurs de charge internes et les services principaux.

Vous pouvez consulter l’état d’un contrôle d’intégrité dans la console Route 53, sous Contrôles d’intégrité, ou l’interroger via l’API. Route 53 publie les métriques des contrôles d’intégrité dans CloudWatch, dans l’espace de noms AWS/Route53, notamment HealthCheckStatus (1 = sain, 0 = défaillant) et HealthCheckPercentageHealthy (pourcentage des vérificateurs Route 53 qui signalent que le point de terminaison est sain).

Configurez des alarmes CloudWatch sur HealthCheckStatus afin de recevoir des notifications SNS lorsqu’un point de terminaison devient défaillant. Vous aurez ainsi une visibilité sur le problème avant que votre équipe d’astreinte ne remarque que le basculement DNS a déjà eu lieu.

Lorsque Route 53 détecte que le contrôle d’intégrité d’un enregistrement principal a échoué, il retire le principal des réponses DNS et renvoie l’adresse du secondaire. C’est ce que l’on appelle le basculement DNS. Le basculement s’effectue dans le délai d’évaluation (nombre d’échecs des vérificateurs d’intégrité × intervalle de requête), auquel s’ajoute le TTL de l’enregistrement.

Exemple : intervalle de requête = 30 s, seuil d’échec = 3, TTL = 60 s. Le délai de basculement maximal est d’environ 3 × 30 + 60 = 150 secondes. Définir un TTL plus court (par exemple, 10 secondes) et un intervalle de contrôle d’intégrité plus rapide (10 s) peut réduire ce délai à 3 × 10 + 10 = 40 secondes.

Les contrôles d’intégrité peuvent également être associés aux enregistrements pondérés et de latence, et pas uniquement aux enregistrements de basculement. Lorsque le contrôle d’intégrité d’un enregistrement pondéré échoue, Route 53 redistribue proportionnellement le poids du trafic de cet enregistrement entre les enregistrements pondérés sains. Lorsque le contrôle d’intégrité d’un enregistrement de latence échoue, Route 53 achemine les requêtes vers l’enregistrement sain présentant la latence immédiatement supérieure.

Les stratégies de routage pondéré et de latence deviennent ainsi résistantes aux défaillances des points de terminaison sans nécessiter d’enregistrements de basculement explicites. Il s’agit d’un modèle SAA-C03 courant : le routage selon la latence entre plusieurs Regions, associé à des contrôles d’intégrité, assure à la fois l’optimisation des performances et la reprise automatique après sinistre.

Voici un modèle multirégion active-active résilient utilisant Route 53 :

1. Créez des enregistrements de latence pour chaque Region (us-east-1, eu-west-1, ap-southeast-1), chacun associé à un contrôle d’intégrité
2. Lorsque toutes les Regions sont saines, les utilisateurs sont dirigés vers la Region présentant la latence la plus faible
3. Si le contrôle d’intégrité d’une Region échoue (application indisponible ou ne répondant plus), Route 53 la retire automatiquement des réponses DNS et achemine les requêtes vers la meilleure Region saine suivante
4. Lorsque la Region défaillante récupère, le contrôle d’intégrité réussit et Route 53 la réintègre dans la rotation

Cette configuration fournit un basculement mondial automatique avec optimisation des performances, sans intervention manuelle.

Les vérificateurs d’intégrité Route 53 proviennent d’un ensemble de plages d’adresses IP publiées dans la section ROUTE53_HEALTHCHECKS du fichier JSON des plages d’adresses IP AWS. Si votre point de terminaison est protégé par un pare-feu ou un groupe de sécurité qui restreint l’accès entrant, vous devez autoriser le trafic provenant de ces plages d’adresses IP pour que les contrôles d’intégrité réussissent.

Vous pouvez également utiliser un point de terminaison public qui sert de proxy vers votre système principal privé (par exemple, un ALB) pour effectuer le contrôle d’intégrité. Le groupe de sécurité de l’ALB doit uniquement autoriser les plages d’adresses IP de Route 53, tandis que le groupe de sécurité du système principal n’autorise que le groupe de sécurité de l’ALB, ce qui maintient une approche de défense en profondeur.

Bonnes pratiques pour les contrôles d’intégrité Route 53 :

• Créez un point de terminaison /health dédié qui vérifie toutes les dépendances critiques (connectivité à la base de données, accessibilité du cache) et renvoie 200 uniquement lorsque le système fonctionne entièrement
• Utilisez un intervalle de requête de 10 secondes pour les points de terminaison de production critiques afin de détecter plus rapidement les défaillances
• Surveillez HealthCheckPercentageHealthy dans CloudWatch : une défaillance partielle (certains vérificateurs Route 53, mais pas tous, échouent) peut indiquer un problème de réseau régional ou intermittent
• Pour les ressources privées d’un VPC, utilisez des contrôles d’intégrité fondés sur les alarmes CloudWatch et sur les métriques de l’application
• Testez le basculement dans des environnements hors production avant de vous y fier en production

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les contrôles d’intégrité des points de terminaison testent HTTP/HTTPS/TCP depuis des vérificateurs Route 53 externes, que les contrôles d’intégrité fondés sur les alarmes CloudWatch permettent de surveiller les ressources privées d’un VPC, et que les contrôles d’intégrité calculés combinent plusieurs signaux avec la logique booléenne. La rapidité du basculement DNS dépend de l’intervalle du contrôle d’intégrité, du seuil d’échec et du TTL. Ensuite, nous examinerons les distributions et les origines CloudFront.