Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Vous pouvez utiliser les surveillances de l’état d’Amazon Route 53 pour contrôler le basculement DNS d’une API API Gateway dans une Région AWS principale vers 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 demander aux clients de changer de point de terminaison d’API.
Lorsque vous choisissez Evaluate Target Health (Évaluer l’intégrité de la cible) pour un enregistrement d’alias, ces enregistrements échouent uniquement lorsque le service API Gateway est indisponible dans la région. Dans certains cas, vos propres API API Gateway peuvent subir une interruption avant cela. Pour contrôler directement le basculement DNS, configurez des surveillances de l’état Route 53 personnalisées pour vos API API Gateway. Pour cet exemple, vous utilisez une alarme CloudWatch qui aide les opérateurs à contrôler le basculement DNS. Pour plus d’exemples et d’autres points à considérer lorsque vous configurez le basculement, consultez Création de mécanismes de reprise après sinistre utilisant Route 53
Rubriques
Prérequis
Pour effectuer cette procédure, vous devez créer et configurer les ressources suivantes :
-
Nom de domaine qui vous appartient.
-
Certificat ACM pour ce nom de domaine dans deux Régions AWS. Pour plus d’informations, consultez Prérequis concernant les noms de domaine personnalisés.
-
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 manière de créer des enregistrements DNS de basculement Route 53 pour les noms de domaine, consultez Choix d’une politique de routage dans le Guide du développeur Amazon Route 53. Pour plus d’informations sur la manière de surveiller une alarme CloudWatch, consultez Surveillance d’une alarme CloudWatch dans le Guide du développeur Amazon Route 53.
Étape 1 : configurer les ressources
Dans cet exemple, vous créez les ressources suivantes pour configurer le basculement DNS pour votre nom de domaine :
-
API API Gateway dans deux Régions AWS
-
Noms de domaine personnalisés d’API Gateway avec le même nom dans deux Régions AWS
-
Mappages d’API API Gateway qui connectent vos API API Gateway aux noms de domaine personnalisés
-
Enregistrements DNS de basculement de Route 53 pour les noms de domaine
-
Alarme CloudWatch dans la région secondaire
-
Surveillance de l’état de Route 53 basée sur l’alarme CloudWatch dans 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 obtenir des exemples de modèles AWS CloudFormation qui créent ces ressources, consultez primary.yaml
et secondary.yaml
.
Important
Avant le basculement vers la région secondaire, vérifiiez que toutes les ressources nécessaires sont disponibles. Sinon, votre API ne sera pas prête pour le 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 métrique CloudWatch et lance 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 de métrique par les données correspondantes pour l’alarme CloudWatch que vous avez configurée.
Étape 3 : tester le basculement
Appelez 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 : retourner à la région principale
Pour revenir à la région principale, envoyez une métrique CloudWatch qui permet de transmettre la surveillance de l’état.
aws cloudwatch put-metric-data \
--metric-name
Failover
\--namespace
HealthCheck
\--unit
Count
\--value
0
\--region
us-west-1
Remplacez les données de métrique par les données correspondantes pour l’alarme CloudWatch que vous avez configurée.
Appelez votre API et vérifiez que vous obtenez une réponse 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 façon de configurer le basculement DNS. Vous pouvez utiliser différentes métriques CloudWatch ou différents points de terminaison HTTP pour les surveillances de l’état 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.