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. # Meilleures pratiques pour le changement de région dans ARC Nous recommandons les bonnes pratiques suivantes pour la restauration et la préparation au basculement avec le commutateur de région dans Amazon Application Recovery Controller (ARC). **Rubriques** + [Gardez les informations d' AWS identification spécialement conçues et durables, sécurisées et toujours accessibles ](#RSBestPracticeCredentials) + [Choisissez des valeurs TTL inférieures pour les enregistrements DNS impliqués dans le basculement ](#RSBestPracticeLowerTTL) + [Réservez la capacité requise pour les applications critiques ](#RSBestPracticeCapacity) + [Utilisez les opérations extrêmement fiables de l'API du plan de données pour répertorier et obtenir des informations sur les plans de changement de région ](#RSBestPracticeUseDataPlane) + [Basculement des tests avec ARC ](#RSBestPracticeTestFailover) **Gardez les informations d' AWS identification spécialement conçues et durables, sécurisées et toujours accessibles** Dans un scénario de reprise après sinistre, réduisez au minimum les dépendances du système en utilisant une approche simple pour accéder aux tâches de restauration AWS et les exécuter. Créez des informations d'identification [ IAM à longue durée de vie ](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html) spécifiquement pour les tâches de reprise après sinistre, et conservez-les en toute sécurité dans un coffre-fort physique sur site ou un coffre-fort virtuel, pour y accéder en cas de besoin. Avec IAM, vous pouvez gérer de manière centralisée les informations d'identification de sécurité, telles que les clés d'accès et les autorisations d'accès aux AWS ressources. Pour les tâches non liées à la reprise après sinistre, nous vous recommandons de continuer à utiliser l'accès fédéré, en utilisant AWS des services tels que Single [AWS . Sign-On ](https://aws.amazon.com/single-sign-on/) **Choisissez des valeurs TTL inférieures pour les enregistrements DNS impliqués dans le basculement** Pour les enregistrements DNS que vous pourriez avoir besoin de modifier dans le cadre de votre mécanisme de basculement, en particulier les enregistrements dont l'état de santé est vérifié, il convient d'utiliser des valeurs TTL inférieures. La définition d'une TTL de 60 ou 120 secondes est un choix courant pour ce scénario. Le paramètre DNS TTL (time to live) indique aux résolveurs DNS combien de temps ils doivent mettre en cache un enregistrement avant d'en demander un nouveau. Lorsque vous choisissez un TTL, vous devez trouver un compromis entre latence et fiabilité, et réactivité aux changements. Avec un TTL plus court sur un enregistrement, les résolveurs DNS remarquent les mises à jour de l'enregistrement plus rapidement, car le TTL indique qu'ils doivent effectuer des requêtes plus fréquemment. Pour plus d'informations, consultez la section * Choix des valeurs TTL pour les enregistrements DNS * dans [ Meilleures pratiques pour le DNS ](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html) Amazon Route 53. **Réservez la capacité requise pour les applications critiques** Le commutateur de région inclut des types de blocs d'exécution qui permettent de dimensionner les ressources de calcul dans le cadre de la restauration. Si vous utilisez ces blocs d'exécution dans un plan, le commutateur de région ne garantit pas que la capacité de calcul souhaitée sera atteinte. Si vous avez une application critique et que vous devez garantir l'accès à la capacité, nous vous recommandons de réserver la capacité. Il existe des stratégies que vous pouvez suivre pour réserver de la capacité de calcul dans une région secondaire tout en limitant les coûts. Pour en savoir plus, consultez [ Veiller à capacité réservée : Comment optimiser les coûts de reprise après sinistre à l'aide des réservations On-Demand de capacité](https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/). **Utilisez les opérations extrêmement fiables de l'API du plan de données pour répertorier et obtenir des informations sur les plans de changement de région** Utilisez les opérations de l'API du plan de données pour utiliser et exécuter votre plan de changement de région lors d'un événement. Pour obtenir la liste des opérations du plan de données du commutateur de région, consultez[Opérations de l'API de commutation de région](actions.region-switch.md). La console de commutation de région de chaque région utilise des opérations de plan de données pour exécuter les plans de commutation de région. Vous pouvez également appeler les opérations d'API du plan de données à l'aide du AWS CLI ou en exécutant du code que vous écrivez à l'aide de l'un des AWS kits SDK. ARC offre une fiabilité extrême grâce à l'API dans le plan de données. **Testez la restauration des applications avec ARC** Testez régulièrement la restauration des applications à l'aide du commutateur de région ARC, pour activer une pile d'applications secondaire dans une autre Région AWS, ou pour basculer entre une configuration active et active en exécutant un plan de changement de région pour désactiver l'une des régions. Il est important de vous assurer que les plans de changement de région que vous avez créés correspondent aux ressources appropriées de votre pile et que tout fonctionne comme prévu. Vous devez le tester après avoir configuré le commutateur de région pour votre environnement, et continuer à effectuer des tests régulièrement, afin de vérifier que vos processus de restauration fonctionnent correctement. Effectuez ces tests régulièrement, avant de rencontrer une situation de panne, afin d'éviter toute interruption de service pour vos utilisateurs. **Basculement DNS du commutateur de région ARC par rapport à la restauration accélérée Route 53** La restauration accélérée fournit un RTO cible de 60 minutes pour les API utilisées pour mettre à jour les enregistrements de votre zone hébergée publique qui sont activés pour cette fonctionnalité. Si vous devez garder le contrôle de votre RTO et ne pas attendre AWS la fin de la restauration des API nécessaires, vous devez utiliser le bloc d'exécution du contrôle de santé ARC Routing Control ou le bloc d'exécution du contrôle de santé Route 53 du commutateur de région ARC.