Configurer des contrôles de santé personnalisés pour le DNS basculement d'une passerelle API API

Vous pouvez utiliser les contrôles de santé d'Amazon Route 53 pour contrôler le DNS basculement entre une API passerelle située API dans une région principale Région AWS et une passerelle située dans une région secondaire. Cela peut aider à atténuer les impacts en cas de problème régional. Si vous utilisez un domaine personnalisé, vous pouvez effectuer un basculement sans obliger les clients à changer de point de API terminaison.

Lorsque vous choisissez Evaluate Target Health comme enregistrement d'alias, ces enregistrements échouent uniquement lorsque le service API Gateway n'est pas disponible dans la région. Dans certains cas, votre propre API passerelle APIs peut être interrompue avant cette date. Pour contrôler directement le DNS basculement, configurez des contrôles de santé Route 53 personnalisés pour votre API passerelleAPIs. Dans cet exemple, vous utilisez une CloudWatch alarme qui aide les opérateurs à contrôler le DNS basculement. Pour plus d'exemples et d'autres considérations lors de la configuration du basculement, consultez les sections Création de mécanismes de reprise après sinistre à l'aide de Route 53 et Réalisation de contrôles de santé de Route 53 sur des ressources privées dans un VPC with AWS Lambda et CloudWatch.

Prérequis

Pour effectuer cette procédure, vous devez créer et configurer les ressources suivantes :

• Nom de domaine qui vous appartient.

• Un ACM certificat pour ce nom de domaine en deux Régions AWS. Pour plus d'informations, consultez Prérequis .

• Zone hébergée Route 53 pour votre nom de domaine. Pour obtenir plus d'informations, consultez Working with hosted zones (Utiliser des zones hébergées) dans le Guide du développeur Amazon Route 53.

Pour plus d'informations sur la création d'DNSenregistrements de basculement Route 53 pour les noms de domaine, consultez Choisir une politique de routage dans le manuel Amazon Route 53 Developer Guide. Pour plus d'informations sur la surveillance d'une CloudWatch alarme, consultez la section Surveillance CloudWatch d'une alarme dans le manuel Amazon Route 53 Developer Guide.

Étape 1 : Configurer les ressources

Dans cet exemple, vous créez les ressources suivantes pour configurer le DNS basculement pour votre nom de domaine :

• APIPasserelle APIs en deux Régions AWS

• APINoms de domaine personnalisés Gateway portant le même nom en deux Régions AWS

• APIAPIMappages de passerelle qui connectent votre API passerelle APIs aux noms de domaine personnalisés

• Router 53 DNS enregistrements de basculement pour les noms de domaine

• Une CloudWatch alarme dans la région secondaire

• Un bilan de santé de la Route 53 basé sur l' CloudWatch alarme de la région secondaire

Tout d'abord, vérifiez que vous disposez de toutes les ressources nécessaires dans les régions principale et secondaire. La région secondaire doit contenir l'alarme et la surveillance de l'état. De cette façon, vous ne dépendez pas de la région principale pour effectuer le basculement. Pour des exemples AWS CloudFormation de modèles qui créent ces ressources, voir primary.yamlet secondary.yaml.

Important

Avant le basculement vers la région secondaire, vérifiiez que toutes les ressources nécessaires sont disponibles. Dans le cas contraire, vous API ne serez pas prêt à recevoir du trafic dans la région secondaire.

Étape 2 : Initier le basculement vers la région secondaire

Dans l'exemple suivant, la région de secours reçoit une CloudWatch métrique et initie le basculement. Nous utilisons une métrique personnalisée qui nécessite l'intervention de l'opérateur pour déclencher le basculement.

aws cloudwatch put-metric-data \
    --metric-name Failover \
    --namespace HealthCheck \
    --unit Count \
    --value 1 \
    --region us-west-1

Remplacez les données métriques par les données correspondantes pour l' CloudWatch alarme que vous avez configurée.

Étape 3 : Test du basculement

Invoquez votre API et vérifiez que vous obtenez une réponse de la région secondaire. Si vous avez utilisé les modèles d'exemple à l'étape 1, la réponse passe de {"message": "Hello from the primary Region!"} à {"message": "Hello from the secondary Region!"} après le basculement.

curl https://my-api.example.com

{"message": "Hello from the secondary Region!"}   

Étape 4 : Retour à la région principale

Pour revenir à la région principale, envoyez une CloudWatch métrique qui permet de valider le bilan de santé.

aws cloudwatch put-metric-data \
    --metric-name Failover \
    --namespace HealthCheck \
    --unit Count \
    --value 0 \
    --region us-west-1

Remplacez les données métriques par les données correspondantes pour l' CloudWatch alarme que vous avez configurée.

Invoquez votre API et vérifiez que vous obtenez une réponse de la part de la région principale. Si vous avez utilisé les modèles d'exemple à l'étape 1, la réponse passe de {"message": "Hello from the secondary Region!"} à {"message": "Hello from the primary Region!"}.

curl https://my-api.example.com

{"message": "Hello from the primary Region!"}

Prochaines étapes : personnalisez et testez régulièrement

Cet exemple montre une méthode de configuration du DNS basculement. Vous pouvez utiliser divers CloudWatch indicateurs ou HTTP points de terminaison pour les bilans de santé qui gèrent le basculement. Testez régulièrement vos mécanismes de basculement pour vous assurer qu'ils fonctionnent comme prévu et que les opérateurs sont familiarisés avec vos procédures de basculement.