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.
# Changement de région dans ARC
Vous pouvez utiliser le changement de région dans ARC pour orchestrer des tâches de restauration complexes et à grande échelle pour les ressources de vos applications sur tous les AWS comptes, afin de garantir la continuité des activités et de réduire les frais opérationnels. Le changement de région fournit une solution centralisée et observable que vous pouvez exécuter manuellement ou automatiser à l'aide des déclencheurs CloudWatch d'alarme Amazon. Si un Région AWS est altéré, vous pouvez exécuter les plans que vous créez en utilisant le changement de région pour basculer ou transférer vos ressources vers une autre région. Cela garantit que votre application peut continuer à fonctionner et à fonctionner de manière saine Région AWS.
Le changement de région repose sur le concept d'un *plan*, que vous concevez et configurez en fonction de vos besoins de restauration spécifiques. Chaque plan inclut *des flux* de travail composés d'étapes. Chaque étape exécute un ou plusieurs *blocs d'exécution*, que le commutateur de région exécute en parallèle ou en séquence, pour terminer la restauration d'une application. Chaque bloc d'exécution gère une tâche différente, telle que le transfert de ressources ou la gestion de la redirection du trafic pour votre application. Pour encore plus de flexibilité, vous pouvez créer des forfaits pour parents, en ajoutant des forfaits pour enfants à un plan parental global.
Le changement de région inclut les éléments suivants :
+ Support active/passive et active/active configurations. Vous pouvez effectuer un basculement et un retour en arrière si vous avez une configuration active/passive multirégionale, ou passer à une configuration différente et revenir en arrière si votre application est configurée comme dans plusieurs régions. active/active
+ Support multicompte pour les ressources applicatives que vous incluez dans la restauration de votre application. Vous pouvez également partager des forfaits de changement de région entre plusieurs comptes.
+ Basculement ou basculement automatique, en déclenchant l'exécution du plan en fonction des alarmes Amazon. CloudWatch Vous pouvez également choisir d'exécuter un plan de changement de région manuellement.
+ Des tableaux de bord complets qui vous offrent une visibilité en temps réel sur le processus de restauration.
+ Un plan de données dans chaque région Région AWS, afin que vous puissiez exécuter votre plan de changement de région sans dépendre de la région que vous désactivez.
Le changement de région est entièrement géré par AWS. L'utilisation de Region Switch vous permet de bénéficier de la résilience d'une plate-forme de restauration qui se concentre sur les exigences spécifiques de votre application, au lieu de créer et de gérer des scripts, et de collecter manuellement des données sur les restaurations.
# À propos du changement de région
Avec le changement de région, vous pouvez orchestrer les étapes spécifiques pour changer Région AWS celle dans laquelle s'exécute votre application multirégionale.
Le changement de région repose sur le concept d'un *plan*, que vous concevez et configurez en fonction de vos besoins de restauration spécifiques. Chaque plan inclut *des flux* de travail composés d'étapes. Chaque étape exécute un ou plusieurs *blocs d'exécution*, que le commutateur de région exécute en parallèle ou en séquence, pour terminer la restauration d'une application. Chaque bloc d'exécution gère une tâche différente, telle que le transfert de ressources ou la gestion de la redirection du trafic pour votre application. Pour encore plus de flexibilité, vous pouvez créer des forfaits pour parents en ajoutant des forfaits pour enfants.
Chaque fois que vous créez ou mettez à jour un plan, Region Switch effectue une évaluation du plan afin de s'assurer qu'il n'y a aucun problème lié aux autorisations IAM, à la configuration des ressources ou à la capacité de fonctionnement. Region Switch effectue régulièrement ces évaluations et génère un avertissement en cas de problème détecté.
Le changement de région calcule également une valeur de temps de reprise réelle pour chaque exécution du plan, afin de vous aider à évaluer si le plan répond à vos objectifs. Vous pouvez consulter le temps de reprise et d'autres informations sur l'exécution des plans dans les tableaux de bord des changements de région dans le AWS Management Console. Pour de plus amples informations, veuillez consulter [Tableaux de bord de changement de région](region-switch.dashboarding-and-reports.md).
Pour en savoir plus sur chacun de ces domaines dans Region Switch, consultez les sections suivantes.
## Plans de changement de région
Un plan de changement de région est la ressource de premier niveau du changement de région. Vous devez adapter votre plan à une application multirégionale spécifique. Un plan vous permet de créer des *flux de travail* pour récupérer vos applications en exécutant une série de *blocs d'exécution* de commutateurs régionaux qui activent ou désactivent votre application et ses ressources, y compris les ressources entre comptes, dans le format Région AWS que vous spécifiez.
Un plan est composé d'un ou de plusieurs flux de travail, afin de vous permettre d'activer ou de désactiver un flux spécifique Région AWS. Vous pouvez configurer des blocs d'exécution dans un flux de travail pour qu'ils s'exécutent de manière séquentielle, ou vous pouvez spécifier que certains blocs s'exécutent en parallèle.
Pour un plan que vous configurez pour une approche active/passive multirégionale, vous créez soit un flux de travail qui peut être utilisé pour activer l'une de vos régions, soit deux flux de travail d'activation distincts, un pour chaque région. Pour un plan que vous configurez pour une approche active/active, vous créez un flux de travail pour activer vos régions et un flux de travail pour désactiver vos régions.
Régions AWS sont des emplacements géographiques dans le monde entier où se AWS regroupent des centres de données. Chaque région est conçue pour être complètement isolée des autres régions, ce qui garantit la tolérance aux pannes et la stabilité. Lorsque vous utilisez le changement de région, vous devez prendre en compte les régions dans lesquelles votre application est déployée et les régions que vous souhaitez utiliser pour la restauration.
Le changement de région prend en charge le rétablissement entre les deux régions Régions AWS où le service est disponible. Lorsque vous configurez un plan de changement de région, vous spécifiez les régions dans lesquelles votre application est déployée et l'approche de restauration que vous souhaitez utiliser : active/passive ou active/active.
Par exemple, vous pouvez adopter une approche active/passive multirégionale avec us-east-1 comme région principale et us-west-2 comme région de secours. Pour récupérer votre application suite à un problème opérationnel affectant l'application dans us-east-1, vous pouvez exécuter votre plan de changement de région pour activer us-west-2. Cela entraînerait le passage de l'application des ressources de us-east-1 aux ressources de us-west-2.
Les plans de changement de région s'exécutent à l'aide des autorisations associées au rôle IAM que vous spécifiez lors de la création du plan.
Vous pouvez créer plusieurs plans, un pour chacune de vos applications multirégionales, puis orchestrer la restauration entre ces plans dans l'ordre requis en créant un plan *parent*. Un plan parent est un plan qui utilise les blocs d'exécution du plan de changement de région comme étapes. La hiérarchie des plans est limitée à deux niveaux (parent et enfant), mais vous pouvez inclure plusieurs plans pour enfants dans le même plan parent.
## Flux de travail et blocs d'exécution
Après avoir créé un plan de changement de région, vous devez y ajouter un ou plusieurs flux de travail afin de définir les étapes que le plan doit effectuer pour la restauration de votre application. Pour chaque flux de travail, vous ajoutez des étapes contenant des blocs d'exécution. Chaque bloc d'exécution exécute une action de restauration spécifique, telle que l'augmentation des ressources ou la mise à jour des contrôles de routage pour rediriger le trafic. Les étapes organisent ces blocs d'exécution et déterminent s'ils s'exécutent en parallèle ou en séquence. En créant des forfaits pour parents, vous pouvez également orchestrer l'ordre dans lequel plusieurs applications sont restaurées dans la région que vous activez.
Vous organisez les blocs d'exécution en étapes au sein d'un flux de travail. Chaque étape peut contenir un ou plusieurs blocs d'exécution exécutés en parallèle, et vous pouvez organiser les étapes pour qu'elles s'exécutent de manière séquentielle dans votre flux de travail. De plus, en fonction de la ressource, vous pouvez avoir la possibilité d'exécuter un bloc d'exécution avec une exécution gracieuse (planifiée) ou irrégulière (non planifiée).
+ Exécution harmonieuse : un flux de travail d'exécution planifié. Lorsque votre environnement est sain, vous pouvez utiliser le flux de travail élégant pour exécuter toutes les étapes nécessaires à une exécution ordonnée du plan.
+ Exécution malhonnête : exécution imprévue. Ce mode de flux de travail peu élégant utilise uniquement les étapes et les actions nécessaires. Ce mode modifie le comportement des blocs d'exécution dans un flux de travail ou ignore des blocs d'exécution spécifiques.
+ Exécution après restauration : flux de travail qui s'exécute après une restauration réussie afin de préparer les futurs événements régionaux. Les exécutions après restauration peuvent créer des répliques de lecture, exécuter une logique personnalisée via des fonctions Lambda, ajouter des portes d'approbation manuelles et intégrer des plans enfants pour une orchestration complexe. Ces exécutions nécessitent que les deux régions soient saines et qu'elles fonctionnent dans la région qui était auparavant affaiblie.
Enfin, vous pouvez également configurer des ressources entre comptes pour un bloc d'exécution. Tout d'abord, vous devez configurer les autorisations en suivant les instructions de[Support multicompte lors du changement de région](cross-account-resources-rs.md). Après avoir configuré les rôles IAM requis, vous pouvez ajouter des ressources multicomptes dans les blocs d'exécution des flux de travail de votre plan. Pour ajouter des ressources entre comptes, lorsque vous ajoutez une étape, vous spécifiez un rôle IAM cible autorisé à accéder à la ressource d'un autre. Comptes AWS Vous devez également spécifier l'ID externe que vous avez fourni dans la politique de confiance pour le rôle multi-comptes. Pour plus de détails sur la création des rôles IAM requis, consultez[Autorisations relatives aux ressources entre comptes](security_iam_region_switch_cross_account.md).
Pour en savoir plus sur les flux de travail, voir[Création de flux de travail liés au changement de région](working-with-rs-workflows.md). Pour plus de détails sur chaque type de bloc d'exécution, notamment les étapes de configuration, son fonctionnement et les éléments évalués dans le cadre de l'évaluation du plan, consultez[Ajouter des blocs d'exécution](working-with-rs-execution-blocks.md).
## Évaluation du plan
L'évaluation du plan est un processus automatisé que Region Switch exécute lorsqu'un plan est créé ou mis à jour, puis toutes les 30 minutes, en régime permanent. Le processus d'évaluation vérifie plusieurs aspects critiques de la configuration du plan et des configurations des ressources. Les évaluations incluent la vérification des autorisations IAM, des configurations des ressources et de la capacité de fonctionnement.
Si le changement de région détecte un problème susceptible d'empêcher l'exécution réussie du plan, il génère un avertissement d'évaluation du plan, qui est mis en évidence sur la page des détails du plan de la console. Vous pouvez également consulter les avertissements d'évaluation des plans avec Amazon EventBridge, ou vous pouvez consulter les avertissements à l'aide de l'API de changement de région. Pour plus d'informations sur l'API Plan Evaluation, consultez [GetPlanEvaluationStatus](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanEvaluationStatus.html)le *Guide de référence de l'API Region Switch* pour Amazon Application Recovery Controller (ARC).
Vous pouvez consulter les détails et les solutions suggérées pour les problèmes liés à l'évaluation du plan dans l'onglet **Évaluation du plan** sur la page des détails du plan. Nous vous recommandons également de tester la restauration des applications en exécutant votre plan de changement de région, et de ne pas vous fier uniquement à l'évaluation du plan de changement de région pour vérifier que votre plan de reprise fonctionnera comme prévu.
## Rapports d'exécution automatique du plan
Le changement de région peut générer automatiquement des rapports PDF complets pour l'exécution des plans afin de vous aider à répondre aux exigences de conformité réglementaire. Ces rapports fournissent des preuves de vos tests de reprise après sinistre et des événements de reprise réels, y compris les délais d'exécution détaillés, les configurations des plans et l'état des ressources.
Lorsque vous configurez la génération automatique de rapports pour un plan, Region Switch crée un rapport PDF une fois l'exécution de chaque plan terminée et le transmet dans un compartiment Amazon S3 que vous spécifiez. Les rapports sont généralement disponibles dans les 30 minutes suivant la fin de l'exécution. Les frais de stockage S3 s'appliquent.
Chaque rapport inclut :
+ Résumé avec aperçu des services et date de création du rapport
+ Détails de configuration du plan tels qu'ils existaient au moment de l'exécution
+ Chronologie d'exécution détaillée avec les étapes, les ressources affectées et les statuts
+ Planifier les avertissements présents au début de l'exécution
+ États des CloudWatch alarmes Amazon et historique des alarmes associées
+ Pour les plans pour parents, les détails de configuration et d'exécution des plans pour enfants
+ Glossaire des termes et des concepts
Pour activer la génération automatique de rapports, vous configurez une destination de sortie de rapport lorsque vous créez ou mettez à jour un plan. Vous devez également vous assurer que le rôle IAM d'exécution de votre plan dispose des autorisations nécessaires pour écrire des rapports dans votre compartiment Amazon S3 et accéder aux ressources nécessaires pour générer le contenu des rapports. Pour plus d’informations sur les autorisations requises, consultez [Autorisations relatives aux rapports d'exécution automatique du plan](security_iam_region_switch_reports.md).
Vous pouvez consulter l'état de la génération des rapports et télécharger les rapports terminés à partir de la page des détails de l'exécution du plan de la console. Si la génération du rapport rencontre des erreurs, telles que des autorisations insuffisantes ou des compartiments Amazon S3 mal configurés, Region Switch fournit des informations détaillées sur les erreurs pour vous aider à résoudre le problème.
L'évaluation du plan valide en permanence la configuration de votre rapport, notamment en vérifiant que le rôle d'exécution dispose des autorisations IAM requises. Si le changement de région détecte des problèmes de configuration susceptibles d'empêcher la génération réussie du rapport, il génère des avertissements que vous pouvez consulter sur la page des détails du plan.
## Alarmes régionales et temps de rétablissement réel
Le changement de région calcule une valeur de *temps de reprise réelle* pour chaque exécution du plan, que vous pouvez consulter après l'exécution du plan. Le temps de restauration réel est indiqué sur la page des détails de l'exécution du plan, afin que vous puissiez le comparer à l'objectif de temps de restauration que vous avez spécifié lors de la création du plan.
Le temps de restauration réel est calculé comme le temps total nécessaire à l'exécution d'un plan et le temps supplémentaire qui s'écoule avant que les CloudWatch alarmes Amazon spécifiques que vous configurez ne repassent à l'état vert.
Pour permettre de calculer un temps de restauration réel précis pour l'exécution du plan, vous devez configurer des CloudWatch alarmes Amazon régionales pour un plan de changement de région qui fournissent un signal sur l'état de santé de votre application dans chaque région. Lorsqu'un plan est exécuté, Region Switch utilise ces alarmes d'état de l'application pour déterminer à quel moment votre application est de nouveau saine. Ensuite, Region Switch calcule le temps de restauration réel en fonction du temps nécessaire à l'exécution de votre plan, ajouté au temps nécessaire pour que votre application redevienne saine, en fonction des alarmes de santé de l'application que vous configurez.
Avant d'ajouter des CloudWatch alarmes à un plan de changement de région, assurez-vous que vous avez mis en place la bonne politique IAM. Pour de plus amples informations, veuillez consulter [CloudWatch alarmes pour les autorisations relatives à l'état des applications](security_iam_region_switch_cloudwatch.md).
# Régions AWS
Le changement de région est disponible dans toutes les régions commerciales Régions AWS, ainsi que dans les régions AWS GovCloud (États-Unis).
Pour obtenir des informations détaillées sur le support régional et les points de terminaison de service pour Amazon Application Recovery Controller (ARC), consultez la section [Points de terminaison et quotas Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/general/latest/gr/arc.html) dans le manuel *Amazon Web Services General Reference*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/r53recovery/latest/dg/aws-regions-rs.html)
# Composants du commutateur de région
Vous trouverez ci-dessous des composants et des concepts relatifs à la fonctionnalité de changement de région d'Amazon Application Recovery Controller (ARC).
**Plan**
Un plan est le processus de restauration fondamental de votre application. Vous créez un plan en élaborant un ou plusieurs flux de travail avec des blocs d'exécution à exécuter en séquence ou en parallèle. Ensuite, en cas de défaillance régionale, vous exécutez le plan pour terminer la restauration de votre application en déplaçant l'application pour qu'elle s'exécute dans une région saine.
**Plan pour enfants**
Un plan enfant est un plan autonome qui peut être exécuté à partir d'un plan parent afin de coordonner des scénarios de restauration d'applications plus complexes. Vous pouvez imbriquer les plans de changement de région à un niveau.
**Flux de travail**
Un plan de changement de région inclut un ou plusieurs flux de travail. Un flux de travail est composé d'étapes contenant des blocs d'exécution, que vous spécifiez pour être exécutés en parallèle ou en séquence, afin de terminer l'activation ou la désactivation d'une région dans le cadre d'un plan de reprise. Pour un plan que vous configurez pour avoir une active/passive approche, vous créez soit un flux de travail qui peut être utilisé pour activer l'une de vos régions, soit des flux de travail d'activation distincts, un pour chaque région. Pour un plan que vous configurez pour une active/active approche, vous créez un flux de travail pour activer vos régions et un flux de travail pour désactiver vos régions.
**Bloc d'exécution**
Vous ajoutez des étapes à vos flux de travail de plan de changement de région contenant un bloc d'exécution. Les blocs d'exécution vous permettent de spécifier la restauration de plusieurs applications ou ressources dans une région d'activation. Lorsque vous ajoutez une étape à un flux de travail, vous pouvez l'ajouter en séquence avec d'autres étapes, ou en parallèle avec une ou plusieurs autres étapes.
**Configurations gracieuses et disgracieuses**
Vous pouvez choisir d'exécuter des blocs d'exécution spécifiques avec une exécution gracieuse (planifiée) ou irrégulière (non planifiée). Lorsque votre environnement est sain, vous pouvez utiliser le flux de travail élégant pour exécuter toutes les étapes nécessaires à une exécution ordonnée du plan. Ce mode de flux de travail peu élégant utilise uniquement les étapes et les actions nécessaires. Lorsque vous exécutez un plan en mode peu élégant, il modifie le comportement des blocs d'exécution dans un flux de travail ou ignore des blocs d'exécution spécifiques, selon le type de bloc d'exécution.
Des types spécifiques de blocs d'exécution ont un comportement différent lorsqu'ils s'exécutent de manière inappropriée. Les détails de ces différences sont décrits dans la section qui inclut des détails sur chaque type de bloc d'exécution. Pour de plus amples informations, veuillez consulter [Ajouter des blocs d'exécution](working-with-rs-execution-blocks.md).
**Configurations Active/active and active/passive**
Il existe deux approches principales pour créer une configuration résiliente pour une application dans plusieurs régions : active/passive active/active. Le changement de région prend en charge la restauration des applications pour ces deux approches.
Avec une active/passive configuration, vous déployez deux répliques de votre application dans deux régions différentes, le trafic client n'étant dirigé que vers une seule région.
Avec une active/active configuration, vous déployez deux répliques dans deux régions différentes, mais les deux répliques traitent du travail ou reçoivent du trafic.
**Exécution du plan**
Lorsqu'un plan de changement de région est exécuté, il met en œuvre la restauration d'une application lorsqu'une région est affectée en activant une région saine pour votre application et le trafic qu'elle reçoit. Avec une active/active configuration, vous exécutez également un plan pour désactiver la région altérée.
**Alarmes de santé des applications**
Les alarmes d'état de l'application sont des CloudWatch alarmes que vous spécifiez pour un plan afin d'indiquer l'état de santé de votre application dans chaque région. Le changement de région utilise des alarmes relatives à l'état de l'application pour déterminer le temps de restauration réel une fois que vous avez changé de région pour implémenter la restauration.
**Triggers**
Vous pouvez utiliser des déclencheurs dans Region Switch pour automatiser la restauration des applications. Lorsque vous créez un déclencheur, vous spécifiez une ou plusieurs CloudWatch alarmes Amazon et définissez les conditions d'alarme (telles que « rouge » ou « vert ») qui doivent déclencher l'exécution du plan. Lorsque les conditions spécifiées sont remplies, le changement de région exécute automatiquement le plan. Les déclencheurs sont distincts des alarmes relatives à l'état des applications : les déclencheurs démarrent l'exécution du plan, tandis que les alarmes relatives à l'état des applications aident Region Switch à calculer le temps de restauration réel une fois le plan terminé.
**Flux de travail après restauration**
Un flux de travail post-restauration est un flux de travail facultatif qui s'exécute après une restauration réussie afin de préparer les futurs événements régionaux. Ces flux de travail nécessitent que les deux régions soient saines et qu'elles s'exécutent dans la région précédemment altérée. Les exécutions après restauration font référence à l'ID d'exécution de restauration de la dernière exécution de restauration.
Les flux de travail après restauration prennent en charge les blocs d'exécution suivants :
+ RDS Create une réplique interrégionale
+ Action personnalisée Lambda
+ Approbation manuelle
+ Plan de changement de région
**Tableaux de bord**
Le changement de région inclut des tableaux de bord dans lesquels vous pouvez suivre les détails de l'exécution des plans en temps réel.
# Plans de données et de contrôle pour le changement de région
Lorsque vous planifiez le basculement et la reprise après sinistre, évaluez la résilience de vos mécanismes de basculement. Nous vous recommandons de vous assurer que les mécanismes sur lesquels vous comptez lors du basculement sont hautement disponibles, afin de pouvoir les utiliser lorsque vous en avez besoin en cas de sinistre. En règle générale, vous devez utiliser les fonctions du plan de données pour vos mécanismes chaque fois que vous le pouvez, pour une fiabilité et une tolérance aux pannes optimales. Dans cette optique, il est important de comprendre comment les fonctionnalités d'un service sont réparties entre les plans de contrôle et les plans de données, et de comprendre dans quels cas vous pouvez compter sur une fiabilité extrême en ce qui concerne le plan de données d'un service.
Comme c'est le cas pour de nombreux AWS services, la fonctionnalité de commutation de région est prise en charge par un plan de contrôle et des plans de données. Bien que les deux types soient conçus pour être fiables, un plan de contrôle est optimisé pour la cohérence des données, tandis qu'un plan de données est optimisé pour la disponibilité. Un plan de données est conçu pour être résilient afin de maintenir sa disponibilité même en cas d'événements perturbateurs, lorsqu'un plan de contrôle peut devenir indisponible.
En général, un *plan de contrôle* vous permet d'exécuter des fonctions de gestion de base, telles que la création, la mise à jour et la suppression de ressources dans le service. Un *plan de données* fournit les fonctionnalités de base d'un service. C'est pourquoi nous vous recommandons d'utiliser les opérations du plan de données lorsque la disponibilité est importante, par exemple lorsque vous devez obtenir des informations sur un plan de changement de région lors d'une panne.
Pour le changement de région, les plans de contrôle et les plans de données sont divisés comme suit :
+ Le plan de contrôle de Region Switch est situé dans la région USA Est (Virginie du Nord) (us-east-1) AWS GovCloud , dans la région (US-Ouest) us-gov-west (-1) et est destiné uniquement à la gestion des services, c'est-à-dire à la création et à la mise à jour de plans, et non à la restauration, c'est-à-dire à l'exécution de plans. *Les opérations de l'API du plan de contrôle de configuration du commutateur de région ne sont pas hautement disponibles.*
+ Le commutateur de région possède des plans de données indépendants dans chacun d'eux Région AWS. Vous devez utiliser le plan de données pour les actions de restauration, c'est-à-dire pour exécuter des plans de changement de région. Pour obtenir la liste des opérations du plan de données, reportez-vous à la section[Opérations de l'API de changement de région](actions.region-switch.md). *Ces opérations du plan de données de commutation de région sont hautement disponibles.*
Le commutateur de région fournit une console indépendante dans chacune d'elles Région AWS, qui appelle les opérations de l'API du plan de données pour les tâches de restauration. Vous pouvez donc utiliser la console de la région que vous activez pour exécuter des plans de restauration d'applications. Pour plus d'informations sur les principales considérations à prendre en compte lors de la préparation et de la réalisation d'une opération de restauration avec Region Switch, consultez[Meilleures pratiques pour le changement de région dans ARC](best-practices.region-switch.md).
Pour plus d'informations sur les plans de données, les plans de contrôle et sur la manière dont AWS les services sont conçus pour répondre aux objectifs de haute disponibilité, consultez le document [Static stability using Availability Zones paper publié](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) dans l'Amazon Builders' Library.
# Marquage pour le changement de région ARC ;
Les balises sont des mots ou des phrases (métadonnées) que vous utilisez pour identifier et organiser vos AWS ressources. Vous pouvez ajouter plusieurs balises à une ressource, chacune de ces balises étant composée d’une clé et d’une valeur que vous définissez. Par exemple, la clé peut être l'environnement et la valeur peut être la production. Vous pouvez rechercher et filtrer vos ressources en fonction des balises que vous ajoutez.
Vous pouvez étiqueter la ressource suivante dans le changement de région dans ARC :
+ Plans
Le balisage dans ARC est uniquement disponible via l'API, par exemple en utilisant le AWS CLI.
Voici des exemples de balisage dans le changement de région à l'aide du AWS CLI.
`aws arc-region-switch --region us-east-1 create-plan --plan-name example-plan --tags Region=IAD,Stage=Prod`
Pour plus d'informations, consultez [TagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_TagResource.html)le *Guide de référence de l'API Region Switch* pour Amazon Application Recovery Controller (ARC).
# Tarification du changement de région dans ARC
Vous payez un coût mensuel fixe par plan de changement de région que vous configurez.
Pour obtenir des informations détaillées sur la tarification de l'ARC et des exemples de tarification, consultez la section [Tarification de l'ARC](https://aws.amazon.com/application-recovery-controller/pricing/).
# Meilleures pratiques pour le changement de région dans ARC
Nous recommandons les meilleures pratiques suivantes pour la préparation à la restauration et au basculement avec le changement de région dans Amazon Application Recovery Controller (ARC).
**Rubriques**
+ [Conservez 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)
+ [Tester le basculement avec ARC](#RSBestPracticeTestFailover)
**Conservez 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 (DR), 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html) de vie spécifiques 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 autres que la reprise après sinistre, nous vous recommandons de continuer à utiliser l'accès fédéré, en utilisant AWS des services tels que l'authentification [AWS unique](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 devrez peut-être modifier dans le cadre de votre mécanisme de basculement, en particulier les enregistrements dont l'état est vérifié, l'utilisation de valeurs TTL inférieures est appropriée. 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 faites un compromis entre latence, fiabilité et réactivité face au changement. Lorsque le TTL d'un enregistrement est plus court, 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 *Choisir des valeurs TTL pour les enregistrements DNS* dans [Meilleures pratiques pour le DNS Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html).
**Réservez la capacité requise pour les applications critiques**
Le changement de région inclut des types de blocs d'exécution qui aident à dimensionner les ressources de calcul dans le cadre de la restauration. Si vous utilisez ces blocs d'exécution dans un plan, Region Switch 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, voir [Pilot light avec capacité réservée : comment optimiser les coûts de reprise après sinistre à l'aide des réservations de capacité à la demande](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 changement de région, voir[Opérations de l'API de changement de région](actions.region-switch.md).
La console de changement de région de chaque région utilise des opérations de plan de données pour exécuter les plans de changement de région. Vous pouvez également appeler les opérations de l'API du plan de données en utilisant AWS CLI ou en exécutant le code que vous écrivez à l'aide de l'un des AWS SDKs. ARC offre une fiabilité extrême grâce à l'API intégrée au plan de données.
**Testez la restauration des applications avec ARC**
Testez régulièrement la restauration des applications avec le commutateur de région ARC, pour activer une pile d'applications secondaire dans une autre Région AWS, ou pour passer d'une configuration active-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 bonnes ressources de votre pile et que tout fonctionne comme vous le souhaitez. Vous devez le tester après avoir configuré le changement de région pour votre environnement, et continuer à le tester régulièrement afin de valider le bon fonctionnement de vos processus de restauration. Effectuez ces tests régulièrement, avant de rencontrer une situation de panne, afin d'éviter les temps d'arrêt pour vos utilisateurs.
**Basculement du DNS via le commutateur de région ARC et restauration accélérée via Route 53**
La restauration accélérée fournit un RTO cible de 60 minutes à APIs utiliser pour mettre à jour les enregistrements de vos zones hébergées publiques activées pour cette fonctionnalité. Si vous devez garder le contrôle de votre RTO et ne pas attendre AWS que le rétablissement soit terminé, vous devez APIs utiliser le contrôle de routage ARC ou le bloc d'exécution du contrôle de santé Route 53 du commutateur de région ARC.
# Tutoriel : Création d'un plan de changement de active/passive région
Ce didacticiel vous explique comment créer un plan de changement de active/passive région pour une application exécutée dans us-east-1 et comment récupérer dans us-west-2. L'exemple inclut les instances Amazon EC2 pour le calcul, la base de données mondiale Amazon Aurora pour le stockage et Amazon Route 53 pour le DNS.
Dans ce didacticiel, vous allez effectuer les étapes suivantes :
+ Création d'un plan de changement de région
+ Créez les flux de travail et les blocs d'exécution du plan
+ Création d'un bloc d'exécution de groupe EC2 Auto Scaling
+ Créez deux blocs d'exécution d'approbation manuelle
+ Créez deux blocs d'exécution Lambda d'actions personnalisés
+ Création d'un bloc d'exécution de la base de données globale Amazon Aurora
+ Création d'un bloc de contrôle de routage ARC
+ Exécuter le plan de changement de région
## Conditions préalables
Avant de commencer ce didacticiel, vérifiez que les conditions requises suivantes sont réunies dans les deux régions :
+ Rôles IAM dotés des autorisations appropriées
+ Groupes EC2 Auto Scaling
+ Fonctions Lambda pour la page de maintenance et les clôtures
+ Aurora Global Database
+ Contrôles de routage ARC
## Étape 1 : Création du plan de changement de région
1. Dans la console de changement de région, choisissez **Créer un plan de changement de région**.
1. Fournissez les informations suivantes :
+ **Région principale** : Choisissez us-east-1
+ **Région de veille** : choisissez us-west-2
+ **Objectif de temps de rétablissement souhaité (RTO)** (facultatif)
+ Rôle **IAM : entrez le rôle** IAM d'exécution du plan. Ce rôle IAM permet de passer d'une région à un AWS service d'appel pendant l'exécution.
1. Choisissez **Créer**.
(Facultatif) Ajoutez des ressources provenant de différents AWS comptes à votre plan de changement de région :
1. Créez le rôle multi-comptes :
+ Dans le compte hébergeant la ressource, créez un rôle IAM.
+ Ajoutez des autorisations pour les ressources spécifiques auxquelles le plan aura accès.
+ Ajoutez une politique de confiance qui permet au rôle d'exécution d'assumer le nouveau rôle.
+ Entrez et notez un identifiant externe que vous utiliserez comme secret partagé.
1. Configurez la ressource dans votre plan :
+ Lorsque vous ajoutez la ressource à votre plan, spécifiez deux champs supplémentaires :
+ **crossAccountRole**: l'ARN du rôle que vous avez créé à l'étape 1
+ **ExternalID : ID** externe que vous avez saisi à l'étape 1
Exemple de configuration pour un bloc d'exécution EC2 Auto Scaling accédant aux ressources du compte 987654321 :
```
{
"executionBlock": "EC2AutoScaling",
"name": "ASG",
"crossAccountRole": "arn:aws:iam::987654321:role/RegionSwitchCrossAccountRole",
"externalId": "unique-external-id-123",
"autoScalingGroupArn": "arn:aws:autoscaling:us-west-2:987654321:autoScalingGroup:*:autoScalingGroupName/CrossAccountASG"
}
```
Autorisations requises :
+ Le rôle d'exécution doit disposer de AssumeRole l'autorisation sts : pour le rôle multi-comptes.
+ Le rôle multi-comptes doit disposer d'autorisations uniquement pour les ressources spécifiques auxquelles il accède.
+ La politique de confiance du rôle multicompte doit inclure :
+ Le compte du rôle d'exécution en tant qu'entité de confiance.
+ La condition d'identification externe.
+ Pour plus d'informations sur la configuration d'un rôle multicompte, consultez[Autorisations relatives aux ressources entre comptes](security_iam_region_switch_cross_account.md).
Avant d'exécuter le plan, Region Switch vérifiera les points suivants :
+ Le rôle d'exécution peut assumer le rôle entre comptes.
+ Le rôle multi-comptes dispose des autorisations requises.
+ L'ID externe correspond à la politique de confiance.
## Étape 2 : Création des flux de travail et des blocs d'exécution du plan
1. Sur la page des détails du plan de changement de région, choisissez **Créer des flux de travail**.
1. Sélectionnez **Créer le même flux de travail d'activation pour toutes les régions**.
1. Entrez une description du flux de travail d'activation par région (facultatif). Cela sera utilisé pour identifier facilement le flux de travail lors de l'exécution du plan.
1. Choisissez **Save and continue (Enregistrer et continuer)**.
### Ajouter le bloc d'exécution EC2 Auto Scaling
Pour plus d'informations sur ce bloc d'exécution, consultez[Bloc d'exécution du groupe Amazon EC2 Auto Scaling](ec2-auto-scaling-block.md).
1. Choisissez **Ajouter une étape**, puis sélectionnez **Exécuter en séquence**.
1. Sélectionnez le bloc d'**exécution EC2 Auto Scaling**, puis **choisissez Ajouter et modifier**. Ce bloc vous permettra de commencer à augmenter la capacité de la région passive.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Entrez « Scale »
+ **Description de l'étape** (facultatif)
+ **ARN du groupe Auto Scaling pour us-east-1** : l'ARN de votre ASG dans us-east-1
+ **ARN du groupe Auto Scaling pour us-west-2** : l'ARN de votre ASG dans us-west-2
+ **Pourcentage correspondant à la capacité de la région source** : entrez 100
+ **Approche de suivi des capacités** : laisser comme « le plus récent »
+ **Délai d'expiration** (facultatif)
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique d'exécution par blocs d'EC2 Auto Scaling](security_iam_region_switch_ec2_autoscaling.md).
1. Choisissez **Enregistrer l'étape**.
### Ajouter un bloc d'exécution des approbations manuelles
Pour plus d'informations sur ce bloc d'exécution, consultez[Bloc d'exécution de l'approbation manuelle](manual-approval-block.md).
1. Choisissez **Ajouter une étape**.
1. Sélectionnez le **bloc d'exécution de l'approbation manuelle** et ajoutez-le à la fenêtre de conception. Ce bloc permet une vérification humaine avant de continuer.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Entrez « Approbation manuelle avant la configuration »
+ **Description de l'étape** (facultatif)
+ **Rôle d'approbation IAM** : rôle qu'un utilisateur doit assumer pour approuver l'exécution
+ **Délai d'expiration** (facultatif). Une fois le délai expiré, l'exécution est interrompue et vous pouvez choisir de réessayer, d'ignorer ou d'annuler.
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique d'exécution des approbations manuelles](security_iam_region_switch_manual_approval.md).
1. Choisissez **Enregistrer l'étape**.
### Ajouter un bloc d'exécution Lambda d'action personnalisé pour la page de maintenance
Pour plus d'informations sur ce bloc d'exécution, consultez[Action personnalisée : bloc d'exécution Lambda](custom-action-lambda-block.md).
1. Choisissez **Ajouter une étape**.
1. Sélectionnez le **bloc d'exécution Lambda de l'action personnalisée**, puis choisissez **Ajouter et modifier**. Ce bloc publie une page de maintenance dans la région en cours d'activation.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Entrez « Afficher la page de maintenance »
+ **Description de l'étape** (facultatif)
+ **ARN Lambda pour activer us-east-1 : ARN de la fonction Lambda de la page de maintenance déployée dans us-east-1**
+ **ARN Lambda pour activer us-west-2 : ARN de la fonction Lambda de la page de maintenance déployée dans us-west-2**
+ **Région pour exécuter la fonction Lambda** : choisissez **Exécuter pour activer la** région
+ **Délai d'expiration** (facultatif)
+ **Intervalle entre les tentatives** (facultatif)
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique de bloc d'exécution Lambda pour les actions personnalisées](security_iam_region_switch_lambda.md).
1. Choisissez **Enregistrer l'étape**.
### Ajouter un bloc d'exécution de la base de données globale Aurora
Pour plus d'informations sur ce bloc d'exécution, consultez[Bloc d'exécution de la base de données globale Amazon Aurora](aurora-global-database-block.md).
1. Choisissez **Ajouter une étape**.
1. Sélectionnez le **bloc d'exécution de la base de données globale Aurora**, puis choisissez **Ajouter et modifier**. Ce bloc déclenche une commutation globale de la base de données Aurora (aucune perte de données). Pour plus d'informations, consultez la section [Utilisation du basculement ou du basculement pour la base de données globale Aurora dans le guide de](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html) l'utilisateur d'*Aurora*.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Enter **Aurora switchover**
+ **Description de l'étape** (facultatif)
+ **Identifiant de base de données global Aurora** : nom du cluster Aurora
+ **ARN du cluster utilisé pour activer us-east-1 :** l'ARN du cluster Aurora dans us-east-1
+ **ARN du cluster utilisé pour activer us-west-2** : l'ARN du cluster Aurora dans us-west-2
+ **Sélectionnez l'option pour la base de données Aurora** : Choisissez **Switchover**
+ **Délai d'expiration** (facultatif)
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique d'exécution de la base de données globale Aurora](security_iam_region_switch_aurora.md).
1. Choisissez **Enregistrer l'étape**.
### Ajouter un bloc d'exécution du contrôle de routage ARC
Pour plus d'informations sur ce bloc d'exécution, consultez[Bloc d'exécution du contrôle de routage ARC](arc-routing-controls-block.md).
1. Choisissez **Ajouter une étape**.
1. Sélectionnez le **bloc d'exécution du contrôle de routage ARC**, puis choisissez **Ajouter et modifier**. Ce bloc effectue un basculement DNS pour transférer le trafic vers la région passive.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Enter **Toggle DNS**
+ **Description de l'étape** (facultatif)
+ **Contrôles de routage utilisés pour activer us-east-1 : choisissez** **Ajouter des contrôles de routage**
+ **Délai d'expiration** : entrez une valeur de délai d'expiration.
1. Choisissez **Ajouter un contrôle de routage** :
+ **ARN du contrôle de routage** : ARN du contrôle de routage qui contrôle us-east-1
+ **État du contrôle de routage** : Choisissez **Activé**
1. Choisissez à nouveau **Ajouter un contrôle de routage** :
+ **ARN du contrôle de routage** : ARN du contrôle de routage qui contrôle us-west-2
+ **État du contrôle du routage** : choisissez **Off**
1. Choisissez **Enregistrer**.
1. **Contrôles de routage utilisés pour activer us-west-2** **: choisissez Ajouter des contrôles de routage**
1. Choisissez **Ajouter un contrôle de routage** :
+ **ARN du contrôle de routage** : ARN du contrôle de routage qui contrôle us-west-2
+ **État du contrôle de routage** : Choisissez **Activé**
1. Choisissez à nouveau **Ajouter un contrôle de routage** :
+ **ARN du contrôle de routage** : ARN du contrôle de routage qui contrôle us-east-1
+ **État du contrôle du routage** : choisissez **Off**
1. Choisissez **Enregistrer**.
1. Choisissez **Enregistrer l'étape**.
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique de bloc d'exécution des contrôles de routage ARC](security_iam_region_switch_arc_routing.md).
1. Choisissez **Enregistrer**.
## Étape 3 : Exécuter le plan
1. Sur la page des détails du plan de changement de région, en haut à droite, choisissez **Execute**.
1. Entrez les détails de l'exécution :
+ Sélectionnez la région à activer.
+ Sélectionnez le mode d'exécution du plan.
+ (Facultatif) Consultez les étapes d'exécution.
+ Reconnaissez l'exécution du plan.
1. Sélectionnez **Démarrer**.
1. Vous pouvez consulter les étapes détaillées au fur et à mesure de l'exécution du plan sur la page des détails d'exécution. Vous pouvez voir chaque étape de l'exécution du plan, y compris l'heure de début, l'heure de fin, l'ARN de la ressource et les messages du journal.
Une fois la région altérée rétablie, vous pouvez exécuter à nouveau le plan (en modifiant les paramètres que vous avez fournis) pour activer la région d'origine, afin de rétablir les opérations de votre application sur la région principale d'origine.
# Tutoriel : Configuration de l'autogénération du rapport d'exécution du plan
Ce didacticiel vous explique comment configurer l'autogénération des rapports d'exécution du plan pour un plan de changement de région. Les rapports fournissent une documentation PDF complète sur l'exécution des plans à des fins de conformité.
Dans ce didacticiel, vous allez effectuer les étapes suivantes :
+ Création d'un compartiment Amazon S3 pour le stockage des rapports
+ Activer la génération automatique des rapports sur un plan de changement de région
+ Exécutez le plan et téléchargez le rapport
## Conditions préalables
Avant de commencer ce didacticiel, vérifiez que vous disposez des éléments suivants :
+ Un plan de changement de région existant avec des flux de travail configurés
+ Autorisations pour créer des compartiments Amazon S3
+ Le rôle IAM d'exécution de votre plan est configuré avec les autorisations requises. Pour de plus amples informations, veuillez consulter [Autorisations relatives aux rapports d'exécution automatique du plan](security_iam_region_switch_reports.md).
## Étape 1 : créer un compartiment Amazon S3 pour les rapports
1. Ouvrez la console Amazon S3 à l'adresse[https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Choisissez **Créer un compartiment**.
1. Fournissez les informations suivantes :
+ **Nom du compartiment** : entrez un nom unique, tel que `my-region-switch-reports`
+ **Paramètres de blocage de l'accès public** : bloquez tous les accès publics (recommandé)
+ **Versionnage des compartiments** : activer la gestion des versions (facultatif mais recommandé)
+ **Chiffrement par défaut** : sélectionnez le cryptage. Si vous utilisez SSM-KMS, le planExecutionRole kms: chiffrement et les kms: GenerateDataKey autorisations sont nécessaires sur la clé CMK par défaut du compartiment s3
1. Choisissez **Créer un compartiment**.
1. Notez le nom du compartiment à utiliser à l'étape suivante.
## Étape 2 : Activez la génération automatique des rapports sur votre plan
1. Ouvrez la console de changement de région à l'adresse[https://console.aws.amazon.com/route53recovery/regionswitch/home](https://console.aws.amazon.com/route53recovery/regionswitch/home).
1. Sélectionnez le plan pour lequel vous souhaitez configurer les rapports.
1. Choisissez **Dans la barre de navigation, accédez à Actions, puis sélectionnez Modifier les détails du plan**.
1. Dans la section **Paramètres du rapport**, fournissez les informations suivantes :
+ Sélectionnez **Activer la génération automatique des rapports**
+ **URI Amazon S3 :** sélectionnez ou entrez l'URI du compartiment S3 que vous avez créé à l'étape 1
+ **ID du compte propriétaire du bucket :** entrez l'ID de compte du propriétaire du bucket
1. Choisissez **Enregistrer**.
1. Attendez que l'évaluation du plan soit terminée. En cas de problème de configuration, des avertissements apparaîtront sur la page des détails du plan.
## Étape 3 : Exécuter le plan et télécharger le rapport
1. Sur la page des détails du plan, choisissez **Execute**.
1. Terminez l'exécution du plan comme d'habitude, en sélectionnant la région à activer et le mode d'exécution.
1. Une fois l'exécution du plan terminée, accédez à la page des détails de l'exécution.
1. Dans la section **Rapport d'exécution du plan**, surveillez l'état de génération du rapport. La génération du rapport s'achève généralement dans les 30 minutes suivant la fin de l'exécution.
1. Lorsque le statut du rapport indique **Terminé**, choisissez **Télécharger le rapport d'exécution du plan** pour télécharger le PDF.
1. Vous pouvez également accéder à votre compartiment Amazon S3 pour accéder directement au rapport. Les rapports sont stockés selon le modèle de dénomination suivant : `ExecutionReport-${planVersion.ownerAccountId}-${planName}-${execution.regionTo}-${event.executionId}-${dateStr}.pdf`
Le rapport généré inclut :
+ Résumé avec aperçu des services et date de création du rapport
+ Détails de configuration du plan tels qu'ils existaient au moment de l'exécution
+ Chronologie d'exécution détaillée avec les étapes, les ressources affectées et les statuts
+ Planifier les avertissements présents au début de l'exécution
+ États des CloudWatch alarmes Amazon et historique des alarmes associées
+ Pour les plans pour parents, les détails de configuration et d'exécution des plans pour enfants
+ Glossaire des termes et des concepts
## Résolution des problèmes
Si la génération du rapport échoue, vérifiez les points suivants :
+ **Erreurs d'autorisation** : vérifiez que le rôle d'exécution dispose des autorisations IAM correctes. Pour de plus amples informations, veuillez consulter [Autorisations relatives aux rapports d'exécution automatique du plan](security_iam_region_switch_reports.md). Consultez les avertissements relatifs à l'évaluation du plan pour détecter des problèmes d'autorisation spécifiques.
+ **Accès au compartiment Amazon S3** : assurez-vous que le compartiment Amazon S3 existe et qu'il est accessible depuis la région où le plan est configuré. Vérifiez que les politiques relatives aux compartiments ne bloquent pas l'accès depuis le rôle d'exécution.
+ **Chiffrement** des compartiments : si vous utilisez des clés KMS gérées par le client pour le chiffrement des compartiments, assurez-vous que le rôle d'exécution est autorisé à utiliser la clé KMS.
Pour obtenir de l'aide supplémentaire, consultez les messages d'erreur détaillés sur la page des détails d'exécution ou contactez le AWS Support.
# Tutoriel : Exécution d'un flux de travail RDS après restauration
Ce didacticiel vous explique comment exécuter un flux de travail après restauration après un basculement RDS réussi. Cette exécution après restauration rétablit la redondance en rétablissant la réplication entre régions pour la base de données RDS, garantissant ainsi que votre base de données RDS est prête pour les futurs événements régionaux.
Dans ce didacticiel, vous allez effectuer les étapes suivantes :
+ Vérifiez les conditions préalables à l'exécution après la restauration
+ Créez un flux de travail après la restauration avec le bloc d'exécution RDS Create Cross-Region Replica
+ Exécuter le flux de travail après la restauration
## Conditions préalables
Avant de commencer ce didacticiel, vérifiez que vous disposez des éléments suivants :
+ Un active/passive plan de changement de région avec un flux de travail d'activation incluant un bloc d'exécution RDS Promote Read Replica
+ Une exécution d'activation réussie qui a favorisé la lecture d'une réplique dans l'autre région
+ Les deux régions sont saines et accessibles
+ L'ID d'exécution de la dernière exécution de restauration
## Étape 1 : créer un flux de travail après la restauration
1. Dans la console de changement de région, choisissez le plan, choisissez **Modifier les flux de travail**, sélectionnez **Config**, cochez la case **Inclure le flux de travail post-restauration dans le plan** et enregistrez.
1. Sur la page Modifier les flux de travail, sélectionnez le menu déroulant **Sélectionnez un flux de travail pour ajouter des étapes** et choisissez **Post-restauration**.
1. Choisissez **Ajouter une étape**.
1. Sélectionnez le **bloc d'exécution Amazon RDS pour créer une réplique interrégionale**.
1. Dans le panneau de droite, configurez le bloc :
+ **Nom de l'étape** : Entrez « Créer une réplique de lecture interrégionale »
+ **Description de l'étape** (facultatif)
+ **ARN de l'instance de base de données RDS pour la région principale** : l'ARN de la base de données de la région principale doit être identique à l'étape de promotion et de lecture de la réplique.
+ **ARN de l'instance de base de données RDS pour la région secondaire** : l'ARN de la base de données promue en secondaire doit être le même que celui de l'étape de promotion et de lecture de la réplique.
+ **Délai d'expiration** (facultatif) : entrez une valeur de délai, telle que 90 minutes
Pour plus d'informations sur les autorisations IAM requises pour ce bloc d'exécution, consultez[Exemple de politique relative aux blocs d'exécution Amazon RDS](security_iam_region_switch_rds.md).
1. Choisissez **Enregistrer l'étape**.
1. Choisissez **Enregistrer le flux de travail**.
## Étape 2 : Exécuter le flux de travail après la restauration
1. Sur la page des détails du plan de changement de région, en haut à droite, choisissez **Execute post-recovery**.
1. Entrez les détails de l'exécution :
+ **ID d'exécution de la restauration** : entrez l'ID d'exécution de la dernière exécution de restauration. Ce champ est utilisé pour identifier la région actuellement active.
+ **Région dans laquelle exécuter** : sélectionnez la région inactive qui ne reçoit aucun trafic d'application. Il s'agit de la région dans laquelle une réplique en lecture sera créée.
1. Passez en revue les étapes d'exécution et confirmez l'exécution.
1. Choisissez **Démarrer une exécution**.
1. Surveillez la progression de l'exécution sur la page des détails de l'exécution. Le bloc d'exécution RDS Create Cross-Region Replica renommera votre ancienne instance principale et créera une nouvelle réplique en lecture dans la région précédemment altérée.
Une fois l'exécution post-restauration terminée avec succès, la réplication entre régions de votre application sera rétablie et vous serez prêt pour les futurs événements régionaux. Vous pouvez vérifier si la nouvelle réplique de lecture a été créée en vérifiant la console RDS dans la région cible. L'ancien serveur principal sera renommé et étiqueté avec *renamedByRegionSwitch*.
**Important**
Le changement de région vérifie que l'ID d'exécution de la restauration correspond à la dernière exécution connue du plan. Si l'ID d'exécution n'est pas valide ou s'il ne s'agit pas de l'ID de la dernière exécution de restauration connue, l'exécution post-restauration ne sera pas exécutée.
# Opérations de l'API de changement de région
Le tableau suivant répertorie les opérations ARC que vous pouvez utiliser pour le changement de région, avec des liens vers la documentation pertinente.
| Action | Utilisation de la console ARC | Utilisation de l'API ARC | API de plan de données |
| --- | --- | --- | --- |
| Approuver ou refuser une étape d'exécution du plan | Consultez [Bloc d'exécution de l'approbation manuelle](manual-approval-block.md) | Consultez [ApprovePlanExecutionStep](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ApprovePlanExecutionStep.html) | Oui |
| Annuler l'exécution d'un plan | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [CancelPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_CancelPlanExecution.html) | Oui |
| Créez un plan | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [CreatePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_CreatePlan.html) | Non |
| Supprimer un plan | Consultez [Utilisation du changement de région](working-with-rs.md) | Consultez [DeletePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_DeletePlan.html) | Non |
| Obtenez un plan | Consultez [Utilisation du changement de région](working-with-rs.md) | Consultez [GetPlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlan.html) | Non |
| Obtenir le statut de l'évaluation du plan | Consultez [Évaluation du plan](region-switch-plans.md#region-switch-plans.plan-evaluation) | Consultez [GetPlanEvaluationStatus](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanEvaluationStatus.html) | Oui |
| Obtenez l'exécution d'un plan | Consultez [Tableaux de bord de changement de région](region-switch.dashboarding-and-reports.md) | Consultez [GetPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanExecution.html) | Oui |
| Obtenez un plan dans la région | Consultez [Utilisation du changement de région](working-with-rs.md) | Consultez [GetPlanInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_GetPlanInRegion.html) | Oui |
| Lister les événements d'exécution du plan | Consultez [Exécuter un plan de changement de région pour récupérer une application](plan-execution-rs.md) | Consultez [ListPlanExecutionEvents](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlanExecutionEvents.html) | Oui |
| Lister les exécutions du plan | Consultez [Exécuter un plan de changement de région pour récupérer une application](plan-execution-rs.md) | Consultez [ListPlanExecutions](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlanExecutions.html) | Oui |
| Lister les plans | Consultez [Utilisation du changement de région](working-with-rs.md) | Consultez [ListPlans](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlans.html) | Non |
| Lister les plans de la région | Consultez [Utilisation du changement de région](working-with-rs.md) | Consultez [ListPlansInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListPlansInRegion.html) | Oui |
| Répertorier les bilans de santé de la Route 53 pour un plan | Consultez [Bloc d'exécution du contrôle de santé Amazon Route 53](route53-health-check-block.md) | Voir [ListRoute53 HealthChecksForPlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListRoute53HealthChecks.html) | Non |
| Répertorier les bilans de santé de la Route 53 pour un plan dans la région | Consultez [Bloc d'exécution du contrôle de santé Amazon Route 53](route53-health-check-block.md) | Voir [ListRoute53 HealthChecksForPlanInRegion](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListRoute53HealthChecksInRegion.html) | Oui |
| Répertorie les balises d'une ressource. | Consultez [Marquage pour le changement de région ARC ;](tagging.region-switch.md) | Consultez [ListTagsForResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_ListTagsForResource.html) | Non |
| Commencer l'exécution d'un plan | Consultez [Exécuter un plan de changement de région pour récupérer une application](plan-execution-rs.md) | Consultez [StartPlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_StartPlanExecution.html) | Oui |
| Étiqueter une ressource | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [TagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_TagResource.html) | Non |
| Supprimer les balises d'une ressource | Consultez [Marquage pour le changement de région ARC ;](tagging.region-switch.md) | Consultez [UntagResource](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UntagResource.html) | Non |
| Mettre à jour un plan | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [UpdatePlan](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlan.html) | Non |
| Mettre à jour l'exécution d'un plan | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [UpdatePlanExecution](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlanExecution.html) | Oui |
| Mettre à jour une étape d'exécution du plan | Consultez [Création d'un plan de changement de région](working-with-rs-create-plan.md) | Consultez [UpdatePlanExecutionStep](https://docs.aws.amazon.com/arc-region-switch/latest/api/API_UpdatePlanExecutionStep.html) | Oui |
# Utilisation du changement de région
Cette section fournit des step-by-step instructions pour travailler avec les plans de changement de région, que vous pouvez utiliser pour récupérer des applications multirégionales. Le changement de région vous permet de créer des plans pour les deux approches active/passive et pour les approches active/active de reprise.
Pour créer un plan de restauration pour votre application, procédez comme suit :
1. Créez un plan de changement de région. Un plan est une structure dotée de certains attributs, tels que la spécificité dans Régions AWS laquelle votre application s'exécute. Chaque plan inclut un ou plusieurs *flux de travail*.
Vous pouvez éventuellement créer plusieurs plans et intégrer ces *plans enfants* dans un plan de reprise global.
1. Créez un flux de travail pour le plan. Vous ne pouvez pas exécuter un plan sans créer au préalable un flux de travail.
1. Dans le flux de travail, ajoutez une ou plusieurs étapes qui constituent chacune un *bloc d'exécution*.
Par exemple, vous pouvez ajouter une étape pour étendre les groupes EC2 Auto Scaling dans une région de destination.
1. Une fois que vous avez ajouté des étapes à votre flux de travail, des étapes supplémentaires peuvent être nécessaires, telles que la configuration des contrôles de santé dans Amazon Route 53. Chaque section du bloc d'exécution inclut les informations de configuration dont vous avez besoin. Pour de plus amples informations, veuillez consulter [Ajouter des blocs d'exécution](working-with-rs-execution-blocks.md).
1. Pour récupérer votre application lorsqu'elle s'exécute dans un environnement Région AWS défaillant, exécutez le plan.
Vous pouvez suivre la progression de l'exécution d'un plan en consultant les informations dans le tableau de bord global ou dans un tableau de bord régional.
Les sections suivantes fournissent des informations détaillées et des étapes pour créer un plan et des flux de travail, et pour ajouter des étapes de blocage d'exécution dans vos flux de travail.
**Topics**
+ [Créez un plan](working-with-rs-create-plan.md)
+ [Créez des flux de travail](working-with-rs-workflows.md)
+ [Ajouter des blocs d'exécution](working-with-rs-execution-blocks.md)
+ [Créez des plans pour enfants](working-with-rs-child-plan.md)
+ [Création de déclencheurs](working-with-rs-triggers.md)
+ [Exécuter un plan](plan-execution-rs.md)
Les procédures décrites dans cette section montrent comment utiliser les plans, les flux de travail, les blocs d'exécution et les déclencheurs à l'aide du AWS Management Console. Pour utiliser plutôt les opérations de l'API de changement de région, voir[Opérations de l'API de changement de région](actions.region-switch.md).
# Création d'un plan de changement de région
Vous pouvez créer deux types de plans différents dans Region Switch : un active/active plan ou un active/passive plan. Lorsque vous créez un plan, spécifiez le type qui s'applique à la manière dont vous souhaitez gérer le basculement.
+ Une approche *active/passive* déploie deux répliques d'applications dans deux régions, le trafic étant acheminé uniquement vers la région active. Vous pouvez activer la réplique dans la région passive en exécutant le plan de changement de région.
+ Une approche *active/active* déploie deux répliques d'applications dans deux régions, et les deux répliques traitent du travail ou reçoivent du trafic.
# Pour créer un plan de changement de région
1. Dans la console de changement de région, choisissez **Créer un plan de changement de région** avec active/passive approche.
1. Fournissez les informations suivantes :
+ **Nom du plan** - Entrez un nom descriptif pour votre plan.
+ **Approche multirégionale** **: sélectionnez **Actif/passif ou actif/actif**.** Cette approche signifie que deux répliques d'applications sont déployées dans deux régions, le trafic étant acheminé uniquement vers la région active. Vous pouvez activer la réplique dans la région passive en exécutant le plan de changement de région.
+ Choisissez **actif/passif** si vous avez déployé deux répliques d'applications dans deux régions, le trafic étant acheminé uniquement vers la région active. Vous pouvez ensuite activer la réplique dans la région passive en exécutant le plan de changement de région qui spécifie *actif/passif*.
+ Choisissez **Actif/actif** si vous avez déployé deux répliques d'applications dans deux régions et que les deux répliques traitent du travail ou reçoivent du trafic.
+ **Régions ou **régions** principales et de secours** : sélectionnez les régions principales et de secours pour votre application. Pour un active/active déploiement, sélectionnez les régions dans lesquelles les répliques sont déployées.
+ **Objectif de temps de restauration (RTO)** - Entrez le RTO souhaité. Le changement de région l'utilise pour donner un aperçu du temps nécessaire à l'exécution du plan de changement de région par rapport au RTO souhaité.
+ **Rôle IAM** - Fournissez un rôle IAM que le commutateur régional utilisera pour exécuter le plan. Pour en savoir plus sur les autorisations, consultez [Identity and Access Management pour le changement de région dans ARC](security-iam-region-switch.md).
+ ** CloudWatch Alarme Amazon** - Fournissez une alarme d'état de l'application que vous avez créée avec Amazon CloudWatch, pour indiquer l'état de santé de votre application dans chaque région. Le changement de région utilise ces alarmes d'état de l'application pour déterminer le temps de restauration réel une fois que vous avez changé de région pour implémenter la restauration.
Avant d'ajouter des CloudWatch alarmes à un plan de changement de région, assurez-vous que vous avez mis en place la bonne politique IAM. Pour de plus amples informations, veuillez consulter [CloudWatch alarmes pour les autorisations relatives à l'état des applications](security_iam_region_switch_cloudwatch.md).
+ **Génération automatique de rapports** : activez éventuellement la génération automatique de rapports pour les exécutions de plans. Lorsque cette option est activée, Region Switch génère un rapport PDF complet une fois l'exécution de chaque plan terminée et le transmet à un compartiment Amazon S3 que vous spécifiez. Fournissez l'URI Amazon S3 et l'ID de compte propriétaire du compartiment.
Avant d'activer la génération automatique de rapports pour les plans, assurez-vous que vous avez mis en place la bonne politique IAM. Pour plus d'informations sur la génération de rapports et les autorisations requises, consultez[Rapports d'exécution automatique du plan](region-switch-plans.md#region-switch-plans.plan-execution-reports).
+ **Tags** - Vous pouvez éventuellement ajouter un ou plusieurs tags à votre plan.
# Création de flux de travail liés au changement de région
Après avoir créé un plan de changement de région, vous devez définir et créer des flux de travail qui spécifient le processus de restauration de votre application. Pour chaque plan, vous définissez un ou plusieurs flux de travail qui achèvent la restauration de votre application. Dans chaque flux de travail, vous ajoutez des étapes qui incluent des *blocs d'exécution* qui définissent chaque action que le changement de région doit effectuer pour la restauration de votre application.
Le nombre de flux de travail que vous créez dépend du scénario de déploiement de votre application et de vos préférences en matière de gestion de la restauration. Par exemple :
+ Si votre plan de changement de région concerne un active/active application deployment, you also need to create a deactivation workflow. This means that for or active/active déploiement, vous aurez au moins deux flux de travail : un flux de travail d'activation et un flux de travail de désactivation.
+ Si votre plan de changement de région concerne le déploiement d'une active/passive application, vous disposez d'une région principale et d'une région secondaire. Si vous choisissez d'avoir des flux de travail d'activation distincts pour chaque région, vous allez créer deux flux de travail : un pour chaque région.
# Pour créer des flux de travail liés au plan de changement de région
1. Dans le plan de changement de région que vous avez créé, choisissez **Créer des flux de travail**.
1. Sélectionnez l'une des options de flux de travail suivantes :
+ **Créez le même flux de travail d'activation pour toutes les régions** : vous permet d'utiliser le même flux de travail d'activation dans toutes les régions.
+ **Créez des flux de travail séparément pour chaque région** : crée un flux de travail d'activation individuel pour chaque région.
1. Vous pouvez éventuellement fournir une description de chaque flux de travail.
1. Définissez le flux de travail requis pour récupérer votre application. Dans votre flux de travail, vous ajoutez *des blocs d'exécution* pour définir les étapes que le changement de région doit effectuer pour votre restauration. Chaque bloc d'exécution définit des actions, telles que le réacheminement du trafic d'applications ou la restauration de bases de données dans une région en cours d'activation, et prend en charge les ressources dans une autre Compte AWS. Vous pouvez choisir de faire exécuter les blocs d'exécution en parallèle ou de manière séquentielle. Pour obtenir des informations détaillées sur les blocs d'exécution spécifiques que vous pouvez ajouter aux flux de travail, consultez[Ajouter des blocs d'exécution](working-with-rs-execution-blocks.md).
1. En fonction de l'option de flux de travail que vous avez sélectionnée, procédez comme suit :
+ Si vous avez sélectionné **Créer le même flux de travail d'activation pour toutes les régions**, un seul flux de travail d'activation est requis.
+ Si vous avez sélectionné **Créer des flux de travail séparément pour chaque région**, deux flux de travail d'activation sont requis.
Pour les active/active plans, vous devez définir à la fois un flux de travail d'activation et un flux de travail de désactivation.
# Ajouter des blocs d'exécution
Vous ajoutez des étapes aux flux de travail dans votre plan de changement de région, pour effectuer les étapes individuelles nécessaires au basculement ou au basculement de votre application. Pour plus de détails sur les fonctionnalités et le comportement de chaque type de bloc d'exécution, consultez les descriptions suivantes.
Le changement de région exécute une évaluation du plan immédiatement après avoir créé un plan ou l'avoir mis à jour, puis toutes les 30 minutes en régime permanent. Le changement de région stocke les informations relatives à l'évaluation du plan dans toutes les régions où votre plan est configuré. Chaque section du bloc d'exécution inclut ici des informations sur ce qui est évalué lorsque Region Switch exécute l'évaluation du plan.
Le changement de région inclut des types de blocs d'exécution qui aident à dimensionner les ressources de calcul dans le cadre de la restauration. Si vous utilisez ces blocs d'exécution dans un plan, sachez que le changement 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, voir [Pilot light avec capacité réservée : comment optimiser les coûts de reprise après sinistre à l'aide des réservations de capacité à la demande](https://aws.amazon.com/blogs/architecture/pilot-light-with-reserved-capacity-how-to-optimize-dr-cost-using-on-demand-capacity-reservations/).
Le commutateur de région prend en charge les blocs d'exécution suivants.
****
| Bloc d'exécution | Fonction | Configuration peu gracieuse |
| --- | --- | --- |
| [Bloc d'exécution du plan de commutation de la région ARC](region-switch-plan-block.md) | Orchestrez la restauration de plusieurs applications en une seule exécution en spécifiant les plans enfants à exécuter. | Lancez des forfaits pour enfants avec leurs configurations peu gracieuses. |
| [Bloc d'exécution du groupe Amazon EC2 Auto Scaling](ec2-auto-scaling-block.md) | Faites évoluer les ressources de calcul EC2 qui se trouvent dans un groupe Auto Scaling dans le cadre de l'exécution de votre plan. | Spécifiez le pourcentage minimum de capacité de calcul qui doit être égalé dans la région que vous activez. |
| [Bloc d'exécution du dimensionnement des ressources Amazon EKS](eks-resource-scaling-block.md) | Faites évoluer les modules de cluster Amazon EKS dans le cadre de l'exécution de votre plan. | N/A |
| [Bloc d'exécution du dimensionnement du service Amazon ECS](ecs-service-scaling-block.md) | Adaptez les tâches de service Amazon ECS dans le cadre de l'exécution de votre plan. | N/A |
| [Bloc d'exécution du contrôle de routage ARC](arc-routing-controls-block.md) | Ajoutez une étape pour modifier l'état d'un ou de plusieurs contrôles de routage ARC, afin de rediriger le trafic de votre application vers une cible Région AWS. | N/A |
| [Bloc d'exécution de la base de données globale Amazon Aurora](aurora-global-database-block.md) | Exécutez un processus de restauration pour une base de données globale Aurora. | Effectuez un basculement des bases de données globales Aurora (cela peut entraîner une perte de données). |
| [Bloc d'exécution Amazon DocumentDB Global Cluster](documentdb-global-cluster-block.md) | Exécutez un flux de restauration pour un cluster global Amazon DocumentDB. | Effectuez un basculement du cluster global Amazon DocumentDB (cela peut potentiellement entraîner une perte de données). |
| [Bloc d'exécution Amazon RDS Promote Read Replica](rds-promote-read-replica-block.md) | Transformez une réplique de lecture Amazon RDS en instance de base de données autonome. | N/A |
| [Amazon RDS Create Inter-Region Replica : bloc d'exécution](rds-create-cross-region-replica-block.md) | Créez une réplique de lecture interrégionale pour une instance de base de données Amazon RDS dans le cadre de la post-restauration. | N/A |
| [Bloc d'exécution de l'approbation manuelle](manual-approval-block.md) | Insérez une étape d'approbation, pour demander l'approbation ou l'annulation d'une exécution avant de poursuivre. | N/A |
| [Action personnalisée : bloc d'exécution Lambda](custom-action-lambda-block.md) | Ajoutez une étape personnalisée pour exécuter une fonction Lambda, afin de permettre des actions personnalisées. | Sautez l'étape. |
| [Bloc d'exécution du contrôle de santé Amazon Route 53](route53-health-check-block.md) | Spécifie les régions vers lesquelles le trafic de votre application sera redirigé pendant le basculement. | N/A |
# Bloc d'exécution du plan de commutation de la région ARC
Le bloc d'exécution du plan de changement de région vous permet d'orchestrer l'ordre dans lequel plusieurs applications basculent vers la région que vous souhaitez activer, en faisant référence à d'autres plans de changement de région enfants. Grâce à cette relation parent/enfant, vous pouvez créer des processus de restauration complexes et coordonnés qui gèrent plusieurs ressources et dépendances au sein de votre infrastructure.
## Configuration
Lorsque vous utilisez le bloc d'exécution du plan de changement de région, vous sélectionnez un plan de changement de région spécifique que vous souhaitez exécuter dans le flux de travail du plan que vous créez.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de bloc d'exécution d'un plan de changement de région](security_iam_region_switch_plan_execution.md).
Pour configurer un bloc d'exécution d'un plan de changement de région, entrez les valeurs suivantes :
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Plan de changement de région :** sélectionnez un plan à exécuter dans le flux de travail du plan actuel.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
Utilisez le bloc d'exécution du plan de changement de région pour créer des flux de travail parents avec parent/child des relations. Notez que ce bloc d'exécution ne prend pas en charge les niveaux supplémentaires de plans enfants et limite le nombre de plans parents-enfants. Les plans pour enfants doivent prendre en charge les mêmes régions que celles prises en charge par le plan parent et doivent suivre la même approche de rétablissement que le plan parent (c' active/active est-à-dire actif/passif).
Ce bloc prend en charge les modes d'exécution gracieux et disgracieux. Des paramètres peu élégants lanceront les plans pour enfants avec leur configuration peu élégante. Si le bloc de commutation de région a été exécuté correctement, puis est passé en mode d'exécution disgracieux, tout plan enfant passera également en mode d'exécution disgracieux.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Si vous partagez un plan entre plusieurs comptes et que le plan n'est plus partagé avec le compte du plan parent, l'évaluation du changement de région renvoie un avertissement indiquant que le plan n'est pas valide.
# Bloc d'exécution du groupe Amazon EC2 Auto Scaling
Le bloc d'exécution du groupe EC2 Auto Scaling vous permet de dimensionner les instances EC2 dans le cadre de votre processus de restauration multirégional. Vous pouvez définir un pourcentage de capacité par rapport à la région que vous quittez (source et destination).
## Configuration
Lorsque vous configurez le bloc d'exécution du groupe EC2 Auto Scaling, vous entrez les ARN EC2 Auto Scaling pour les régions spécifiques associées à votre plan. Vous devez saisir EC2 ARNs Auto Scaling dans chaque région que vous souhaitez étendre pendant l'exécution du plan.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique d'exécution par blocs d'EC2 Auto Scaling](security_iam_region_switch_ec2_autoscaling.md).
Pour configurer un bloc d'exécution d'un groupe EC2 Auto Scaling, entrez les valeurs suivantes :
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **ARN du groupe EC2 Auto Scaling par région** *: entrez l'ARN du groupe EC2 Auto Scaling dans chaque région de votre plan.*
1. **Pourcentage correspondant à la capacité de la région activée :** entrez le pourcentage souhaité du nombre d'instances en cours d'exécution dans le groupe Auto Scaling pour correspondre à la région activée.
1. **Approche de surveillance des capacités :** sélectionnez l'une des approches suivantes pour surveiller la capacité de vos groupes EC2 Auto Scaling :
+ **Capacité de fonctionnement maximale échantillonnée sur 24 heures** : choisissez cette option pour utiliser la valeur de **capacité souhaitée** spécifiée dans la configuration de votre groupe EC2 Auto Scaling. Cette option ne crée pas de coûts supplémentaires, mais elle est potentiellement moins précise que l'utilisation de l'autre option, CloudWatch les métriques.
Dans l'API de changement de région, cette option correspond à la spécification`sampledMaxInLast24Hours`.
Pour plus d'informations, consultez la section [Définir les limites de dimensionnement pour votre groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html) dans le guide de l'utilisateur Amazon EC2 Auto Scaling.
+ **Capacité de fonctionnement maximale échantillonnée sur 24 heures avec CloudWatch** : Choisissez cette option pour utiliser les métriques spécifiées dans Amazon CloudWatch pour EC2 Auto Scaling. L'utilisation de cette option peut être plus précise, mais entraîne des coûts supplémentaires liés à l'utilisation de CloudWatch métriques.
Dans l'API de changement de région, cette option correspond à la spécification`autoscalingMaxInLast24Hours`.
Pour utiliser cette option, vous devez d'abord activer les métriques de groupe pour vos groupes Auto Scaling. Pour plus d'informations, consultez la section [Enable Auto Scaling group metrics](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-metrics.html#as-enable-group-metrics) dans le guide de l'utilisateur Amazon EC2 Auto Scaling.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
Après avoir configuré un bloc d'exécution EC2 Auto Scaling, Region switch confirme qu'il n'existe qu'un seul groupe Auto Scaling source et un seul groupe Auto Scaling de destination. S'il existe plusieurs groupes Auto Scaling, le bloc d'exécution échoue lors de l'évaluation du plan. La capacité cible est définie comme le nombre d'instances dont l'état est défini sur`InService`. Pour plus d'informations, consultez la section Cycle de vie des [instances EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-lifecycle.html).
Sur la base de la valeur que vous spécifiez (lorsque vous configurez le bloc d'exécution Auto Scaling) pour un pourcentage correspondant, Region Switch calcule la nouvelle capacité souhaitée pour le groupe Auto Scaling de destination. La nouvelle capacité souhaitée est comparée à la capacité souhaitée du groupe Auto Scaling de destination. La formule utilisée par Region switch pour calculer la capacité souhaitée est la suivante :`ceil(percentToMatch * Source Auto Scaling group capacity)`, où ceil () est une fonction qui arrondit tout résultat fractionnaire. Si la capacité actuellement souhaitée du groupe Auto Scaling de destination est supérieure ou égale à la capacité souhaitée du nouveau groupe Auto Scaling calculé par Region Switch, le bloc d'exécution se poursuit. Notez que le changement de région ne réduit pas la capacité du groupe Auto Scaling.
Lorsque Region Switch exécute un bloc Auto Scaling, Region Switch tente d'augmenter la capacité du groupe Region Auto Scaling cible pour qu'elle corresponde à la capacité souhaitée. Ensuite, le changement de région attend que la capacité du groupe Auto Scaling demandée soit atteinte dans le groupe Auto Scaling de la région cible avant de passer à l'étape suivante du plan.
**Note**
L'exécution de ce bloc modifie les paramètres de capacité minimale et souhaitée de vos groupes Auto Scaling, ce qui peut entraîner une dérive de configuration si vous gérez ces valeurs par le biais d' infrastructure-as-codeoutils ou d'autres automatismes. Assurez-vous que vos processus de gestion de configuration tiennent compte de ces modifications afin d'éviter les annulations involontaires.
Si vous utilisez une active/active approche, le commutateur de région utilise l'autre région configurée comme source. En d'autres termes, si une région est désactivée, le changement de région utilise l'autre région active comme source pour déterminer le pourcentage d'échelle.
Ce bloc prend en charge les modes d'exécution gracieux et disgracieux. Vous pouvez configurer une exécution irrégulière en spécifiant le pourcentage minimum de capacité de calcul à égaler dans la région cible avant que le changement de région ne passe à l'étape suivante du plan.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications critiques sur la configuration et les autorisations des blocs d'exécution de votre groupe EC2 Auto Scaling. L'évaluation du changement de région vérifie que les groupes Auto Scaling sont présents dans les deux régions, garantit qu'ils sont correctement configurés et accessibles, et note le nombre d'instances en cours d'exécution dans chaque région. Cela confirme également que la capacité maximale du groupe Auto Scaling de la région cible est suffisante pour gérer le pourcentage de correspondance d'échelle spécifié pour la capacité requise.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations appropriées pour Auto Scaling. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md). Si l'une des vérifications échoue, le changement de région renvoie des messages d'avertissement, que vous pouvez consulter dans la console. Vous pouvez également recevoir les avertissements de validation via EventBridge ou en utilisant des opérations d'API.
# Bloc d'exécution du dimensionnement des ressources Amazon EKS
Le bloc d'exécution du dimensionnement des ressources EKS vous permet de dimensionner les ressources EKS dans le cadre de votre processus de restauration multirégional. Lorsque vous configurez le bloc d'exécution, vous définissez un pourcentage de capacité à adapter, par rapport à la capacité de la région en cours de désactivation.
## Configuration des autorisations d'accès à EKS
Avant de pouvoir ajouter une étape pour le dimensionnement des ressources EKS, vous devez fournir à Region Switch les autorisations nécessaires pour effectuer des actions avec les ressources Kubernetes de vos clusters EKS. Pour fournir un accès au commutateur de région, vous devez créer une entrée d'accès EKS pour le rôle IAM que le commutateur de région utilise pour l'exécution du plan, en utilisant la politique d'accès au commutateur de région suivante : `arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy`
### Politique d'accès EKS pour les commutateurs régionaux
Les informations suivantes fournissent des informations détaillées sur la politique d'accès EKS.
**Nom**: `AmazonARCRegionSwitchScalingPolicy`
**ARN de la politique :** `arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy`
| Groupes d’API Kubernetes | Ressources Kubernetes | Verbes (autorisations) Kubernetes |
| --- | --- | --- |
| \$1 | \$1/échelle | obtenir, mettre à jour |
| \$1 | \$1/statut | get |
| autoscaling | autodétartreurs horizontaux à pod | obtenir, patcher |
### Création d'une entrée d'accès EKS pour le changement de région
L'exemple suivant décrit comment créer les associations d'entrée et de politique d'accès requises afin que Region Switch puisse effectuer des actions spécifiques pour vos ressources Kubernetes. Dans cet exemple, les autorisations s'appliquent à l'espace de noms *my-namespace1* du cluster EKS *my-cluster* pour le rôle IAM. `arn:aws:iam::555555555555:role/my-role`
Lorsque vous configurez ces autorisations, assurez-vous de suivre ces étapes pour les deux clusters EKS de votre bloc d'exécution.
**Prérequis**
Avant de commencer, remplacez le mode d'authentification du cluster par `API_AND_CONFIG_MAP` ou`API`. La modification du mode d'autorisation ajoute l'API pour les entrées d'accès. Pour plus d'informations, consultez [Modifier le mode d'authentification pour utiliser les entrées d'accès](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html) dans le guide de l'utilisateur Amazon EKS.
**Créez l'entrée d'accès**
La première étape consiste à créer l'entrée d'accès à l'aide d'une AWS CLI commande similaire à la suivante :
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn
arn:aws:iam::555555555555:user/my-user --type STANDARD
```
Pour plus d'informations, consultez la section [Créer des entrées d'accès](https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html) dans le guide de l'utilisateur Amazon EKS.
**Création de l'association d'entrée d'accès**
Créez ensuite l'association à la politique d'accès du commutateur régional à l'aide d'une AWS CLI commande similaire à la suivante :
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::555555555555:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1 --policy-arn
arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy
```
Pour plus d'informations, consultez [Associer les politiques d'accès aux entrées d'accès](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html) dans le guide de l'utilisateur Amazon EKS.
Assurez-vous de répéter ces étapes avec le deuxième cluster EKS de votre bloc d'exécution, dans l'autre région, afin de vous assurer que les deux clusters sont accessibles par le biais du commutateur de région.
## Configuration
**Important**
Avant d'ajouter une étape de dimensionnement des ressources EKS, assurez-vous d'abord que vous avez configuré les autorisations appropriées. Pour de plus amples informations, veuillez consulter [Configuration des autorisations d'accès à EKS](#eks-resource-scaling-block-permissions). Assurez-vous également que vous avez mis en place la bonne politique IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique d'exécution du dimensionnement des ressources Amazon EKS](security_iam_region_switch_eks.md).
Notez que le changement de région prend actuellement en charge les ReplicaSet ressources suivantes : apps/v1, Deployment, and apps/v 1.
Pour la configuration du bloc d'exécution, entrez les valeurs suivantes.
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Nom de l'application :** entrez le nom de votre application EKS, par exemple, *MyApplication*.
1. *Type de **ressource Kubernetes : entrez le type** de ressource pour l'application, par exemple, Déploiement.*
1. **Ressource par *région* :** pour chaque région, entrez les informations relatives au cluster EKS, notamment l'ARN du cluster EKS, l'espace de noms des ressources, etc.
1. **Pourcentage correspondant à la capacité de la région activée :** entrez le pourcentage souhaité de pods actifs dans la région source pour qu'il corresponde à celui de la région activée.
1. **Approche de surveillance de la capacité :** la seule option de surveillance de la capacité est déjà sélectionnée, **capacité de fonctionnement maximale échantillonnée sur 24 heures**.
Cette approche de surveillance des capacités utilise la `ReplicaCount` valeur des demandes de service EKS. Pour plus d'informations, consultez la section [En savoir plus sur le changement de zone ARC dans Amazon EKS dans](https://docs.aws.amazon.com/eks/latest/userguide/zone-shift.html) le guide de l'utilisateur d'Amazon Elastic Kubernetes Service.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
Au cours de l'exécution d'un plan, Region Switch récupère le nombre maximum de répliques échantillonné au cours des 24 dernières heures pour la ressource cible dans la région que vous activez. Il calcule ensuite le nombre de répliques souhaité pour la ressource de destination à l'aide de la formule suivante : `ceil(percentToMatch * Source replica count)`
Si le nombre de répliques prêtes pour la destination est inférieur à la valeur souhaitée, Region Switch adapte la valeur de réplication de la ressource de destination à la capacité souhaitée. Il attend que les répliques soient prêtes et utilise le scaler automatique de votre nœud pour augmenter la capacité du nœud si nécessaire.
Si le `hpaName` champ facultatif n'est pas vide, Region switch HorizontalPodAutoscaler applique le correctif suivant pour empêcher toute réduction automatique pendant ou après l'exécution : `{"spec":{"behavior":{"scaleDown":{"selectPolicy":"Disabled"}}}}`
Assurez-vous de configurer tout outil de correction de dérive, tel que l' GitOps outillage, de manière à ignorer le champ de réplication pour les ressources du correctif, ainsi que le champ. HorizontalPodAutoscaler
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur le bloc d'exécution et les autorisations que vous avez configurés pour EKS. Le changement de région vérifie que le rôle IAM du plan dispose des autorisations appropriées pour décrire les clusters EKS et répertorier les politiques d'entrée d'accès associées. Le changement de région valide également que le rôle IAM est associé à la bonne politique d'entrée d'accès, de sorte que le commutateur de région dispose des autorisations requises pour agir sur les ressources Kubernetes. Enfin, Region Switch confirme que les clusters EKS et les ressources Kubernetes configurés existent.
En outre, Region Switch vérifie qu'il a correctement collecté et stocké les données de surveillance nécessaires (nombre de répliques Kubernetes) et capture le nombre de pods en cours d'exécution nécessaires pour exécuter le plan de changement de région.
# Bloc d'exécution du dimensionnement du service Amazon ECS
Le bloc d'exécution du dimensionnement du service ECS vous permet de dimensionner votre service ECS dans une région de destination dans le cadre de votre processus de restauration multirégional. Vous pouvez définir un pourcentage de capacité par rapport à la région à partir de laquelle le changement de région bascule ou se désactive.
## Configuration
Pour configurer le bloc d'exécution du service ECS Scaling, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de mise à l'échelle des blocs d'exécution du service Amazon ECS](security_iam_region_switch_ecs.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Ressource pour *la région* :** pour chaque région, entrez l'ARN du cluster ECS et l'ARN du service ECS.
1. **Pourcentage correspondant au nombre de tâches de la région source :** entrez le pourcentage souhaité de tâches en cours d'exécution dans la région source pour qu'il corresponde à celui de la région activée.
1. **Approche de surveillance de la capacité :** sélectionnez l'une des approches suivantes pour surveiller la capacité d'Amazon ECS :
+ **Capacité de fonctionnement maximale échantillonnée sur 24 heures** : choisissez cette option pour utiliser la valeur du **nombre de tâches en cours** dans votre service Amazon ECS. Cette option ne crée pas de coûts supplémentaires, mais elle est potentiellement moins précise que l'utilisation de l'autre option, CloudWatch les métriques.
Dans l'API de changement de région, cette option correspond à la spécification`sampledMaxInLast24Hours`.
Pour plus d'informations, consultez la section [Mise à l'échelle automatique de votre service Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) dans le guide du développeur Amazon Elastic Container Service.
+ **Capacité de fonctionnement maximale échantillonnée sur 24 heures via Container Insights** : choisissez cette option pour utiliser les métriques Amazon ECS Container Insights. L'utilisation de cette option peut être plus précise, mais entraîne des coûts supplémentaires liés à l'utilisation de Container Insights.
Dans l'API de changement de région, cette option correspond à la spécification`autoscalingMaxInLast24Hours`.
Pour utiliser cette option, vous devez d'abord activer Container Insights. Pour plus d'informations, consultez la section [Configurer Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html#set-container-insights-ECS-cluster) dans le guide de CloudWatch l'utilisateur Amazon.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
Après avoir configuré le bloc d'exécution dans votre plan, Region Switch confirme qu'il n'existe qu'un seul service ECS source et un seul service de destination. S'il existe plusieurs services, Region Switch renvoie un avertissement pour le bloc d'exécution. Le changement de région stocke ces données dans toutes les régions pour lesquelles votre plan est configuré. La capacité cible est définie comme le nombre souhaité défini sur votre service ECS.
Pour une active/passive approche, le commutateur de région calcule la nouvelle capacité souhaitée pour le service ECS dans la région de destination (d'activation). La nouvelle capacité souhaitée est comparée à la capacité souhaitée du service ECS de destination. La formule utilisée par Region switch pour calculer la capacité souhaitée est la suivante :`ceil(percentToMatch * Source Auto Scaling group capacity)`, où ceil () est une fonction qui arrondit tout résultat fractionnaire. Si le nombre actuellement souhaité pour le service ECS de destination est supérieur à la nouvelle capacité souhaitée calculée pour le service ECS, l'exécution du plan se poursuit. Notez que le changement de région ne réduit pas la capacité du service ECS.
Si le service ECS a activé le dimensionnement automatique des applications, Region Switch met à jour la capacité minimale dans Application Autoscaling et met également à jour le nombre souhaité dans le service ECS.
Lorsque le commutateur régional exécute un bloc de service ECS, le commutateur régional tente d'augmenter la capacité ECS de la région cible pour qu'elle corresponde à la capacité souhaitée. Ensuite, le changement de région attend que la capacité de service ECS demandée soit atteinte dans le service ECS de la région cible avant de passer à l'étape suivante du plan. Si vous le souhaitez, vous pouvez configurer l'étape pour qu'elle soit terminée avant que le traitement ne soit terminé en définissant un délai d'attente pour le changement de région avant que la capacité ne soit atteinte.
Si vous utilisez une active/active approche, le commutateur de région utilise l'autre région configurée comme source. En d'autres termes, si une région est désactivée, le changement de région utilise l'autre région active comme source pour déterminer le pourcentage d'échelle.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations des blocs d'exécution de votre service ECS. Le changement de région vérifie que les services ECS sont présents à la fois dans les régions source et cible, et vérifie que la capacité maximale définie pour le service ECS de la région cible est suffisante pour gérer le pourcentage de correspondance spécifié par rapport à la capacité de la région cible. Le changement de région valide également que le rôle IAM du plan dispose des autorisations appropriées pour le service ECS. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
En outre, Region Switch vérifie que les données de surveillance nécessaires pour les services ECS ont `ResourceMonitor` été collectées et stockées avec succès, et enregistre le nombre de tâches en cours d'exécution.
Si l'une des vérifications échoue, le changement de région renvoie des messages d'avertissement, que vous pouvez consulter dans la console. Vous pouvez également recevoir les avertissements de validation via EventBridge ou en utilisant des opérations d'API.
# Bloc d'exécution du contrôle de routage ARC
Si vous avez configuré le contrôle de routage d'Amazon Application Recovery Controller (ARC) pour votre application, vous pouvez ajouter une étape de contrôle de routage ARC pour rediriger le trafic de l'application. Cette étape vous permet de modifier l'état d'un ou de plusieurs contrôles de routage ARC afin de rediriger le trafic de votre application vers une destination Région AWS. Le contrôle de routage ARC redirige le trafic en utilisant des contrôles de santé dans Amazon Route 53 qui sont configurés avec les enregistrements DNS associés aux contrôles de routage.
**Important**
Le contrôle de routage d'Amazon Application Recovery Controller (ARC) n'est disponible que dans la partition AWS commerciale.
## Configuration
Pour configurer un bloc d'exécution du contrôle de routage, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de bloc d'exécution des contrôles de routage ARC](security_iam_region_switch_arc_routing.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Contrôles de routage souhaités :** pour chaque région que vous souhaitez activer ou désactiver, entrez l'ARN du contrôle de routage et l'état initial du contrôle de routage, Activé ou Désactivé.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
Le modèle attendu pour ce bloc d'exécution est de spécifier des contrôles de routage et des états initiaux correspondant à la manière dont vous avez configuré votre application en particulier Régions AWS. Par exemple, si vous avez un plan qui vous permet d'activer les régions A et B pour votre application, vous pouvez avoir un contrôle de routage pour la région A où vous définissez l'état sur Activé et un contrôle de routage pour la région B où vous définissez l'état sur Activé.
Ensuite, lorsque vous exécutez le plan et que vous spécifiez que vous souhaitez activer la région A, le flux de travail qui inclut ce bloc d'exécution met le contrôle de routage spécifié à Activé, ce qui dirige le trafic vers la région A.
## Comment ça marche
En configurant un bloc d'exécution du contrôle de routage ARC, vous pouvez rediriger le trafic de l'application vers une destination ou Région AWS, dans le cas d'une active/active approche, empêcher le trafic d'être acheminé vers une région que vous désactivez. Si votre plan inclut plusieurs flux de travail, assurez-vous de fournir les mêmes entrées pour les enregistrements DNS pour tous les blocs d'exécution du contrôle de routage que vous utilisez.
Ce bloc ne prend pas en charge le mode d'exécution peu scrupuleux.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region switch effectue plusieurs vérifications sur le routage, les contrôles, la configuration des blocs d'exécution et les autorisations. Le commutateur de région vérifie que les commandes de routage spécifiées sont correctement configurées et accessibles.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations requises pour accéder aux états de contrôle de routage et les mettre à jour. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution du contrôle de routage. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec les contrôles de routage ARC lorsque cette étape s'exécute pendant l'exécution d'un plan.
## Comparaison des contrôles de routage ARC et des blocs d'exécution des contrôles de santé Route 53
Le bloc d'exécution du contrôle de santé Amazon Route 53 dans Region Switch constitue une alternative moins coûteuse pour la gestion du trafic basée sur le DNS. Toutefois, ce bloc d'exécution dépend de la région Région AWS que vous activez, de sorte que cette région doit être disponible. Cela répond aux besoins de la plupart des clients, car ils activent une région saine.
Les contrôles de routage ARC fournissent une gestion du trafic hautement fiable basée sur le DNS avec un SLA de disponibilité à 100 %. Grâce aux contrôles de routage, vos équipes opérationnelles peuvent transférer le trafic entre les régions à l'aide de glissières de sécurité. Les contrôles de routage fournissent une solution à locataire unique avec un SLA de 100 %. Un cluster de contrôle de routage est réparti sur cinq régions et peut tolérer que deux régions soient hors ligne. Si vous avez des applications très critiques, pensez à utiliser des contrôles de routage.
Les contrôles de routage ne sont pas nécessaires pour utiliser le changement de région. Vous pouvez utiliser le commutateur de région pour gérer la redirection du trafic en utilisant les blocs d'exécution des contrôles de santé de Route 53 sans contrôles de routage.
Les contrôles de routage ajoutent de la valeur avec le changement de région dans les situations suivantes :
+ Vous avez besoin du SLA de disponibilité à 100 % pour le mécanisme de contrôle du trafic lui-même.
+ Votre entreprise a besoin de contrôles opérationnels manuels assortis de règles de sécurité pour les applications critiques.
+ Vous voulez defense-in-depth que les équipes opérationnelles puissent annuler manuellement le routage automatique du trafic si nécessaire.
Les blocs d'exécution du bilan de santé de Route 53 ne dépendent pas du plan de contrôle. Les modifications apportées aux dossiers de contrôle de santé utilisent le plan de données, de sorte qu'elles ne nécessitent pas la région d'activation pour traiter les mises à jour de configuration. Les blocs d'exécution du bilan de santé Route 53 sont suffisants dans les situations suivantes :
+ Votre application peut dépendre de Région AWS celle que vous activez.
+ La redirection automatique du trafic dans le cadre du processus de restauration répond à vos exigences.
+ L'optimisation des coûts est une priorité. Les blocs d'exécution des contrôles de santé Route 53 sont moins coûteux que les contrôles de routage.
La plupart des clients commencent par utiliser les blocs d'exécution des contrôles d'état de Route 53 comme mécanisme de routage du trafic par défaut et ajoutent des contrôles de routage uniquement pour leurs applications les plus critiques qui nécessitent le plus haut niveau de fiabilité pour le mécanisme de gestion du trafic.
# Bloc d'exécution de la base de données globale Amazon Aurora
Le bloc d'exécution de la base de données globale Amazon Aurora vous permet d'exécuter un flux de travail de restauration en cas de *basculement* *ou de basculement* pour une base de données globale.
+ Basculement : utilisez cette approche pour récupérer après une panne imprévue. Avec cette approche, vous effectuez un basculement entre régions vers l'un des clusters de bases de données secondaires de vos bases de données globales Aurora. L'objectif du point de récupération (RPO) pour cette approche est généralement une valeur différente de zéro mesurée en secondes. L'ampleur de la perte de données dépend du délai de réplication des bases de données globales Aurora Régions AWS au moment de la panne. Pour plus d'informations, consultez la section [Restauration d'une base de données globale Amazon Aurora suite à une panne imprévue](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-failover) dans le guide de l'utilisateur Amazon Aurora.
+ Basculement : cette opération était auparavant appelée basculement *planifié géré*. Adoptez cette approche pour les scénarios contrôlés, tels que la maintenance opérationnelle et d’autres procédures opérationnelles planifiées, où tous les clusters Aurora et les autres services avec lesquels ils interagissent sont en bon état. Étant donné que cette fonction synchronise les clusters de bases de données secondaires avec le cluster principal avant toute modification, le RPO est égal à 0 (aucune donnée perdue). Pour plus d'informations, consultez la section [Effectuer des commutations pour les bases de données mondiales Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover) dans le guide de l'utilisateur Amazon Aurora.
## Configuration
Pour configurer un bloc d'exécution de la base de données globale Aurora, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique d'exécution de la base de données globale Aurora](security_iam_region_switch_aurora.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Nom du cluster de base de données globale Aurora :** entrez l'identifiant de la base de données globale.
1. **ARN du cluster pour *la région* :** entrez l'ARN du cluster à utiliser dans chaque région du plan.
1. **Spécifiez l'option pour la base de données Aurora :** choisissez **Switchover** ou **Failover (perte de données)**, selon la méthode que vous souhaitez
1. **Nom du cluster de base de données globale Aurora :**
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
En configurant un bloc d'exécution des bases de données globales Aurora, vous pouvez basculer ou basculer des bases de données globales dans le cadre de la restauration de votre application. Si vous utilisez une active/active approche, le commutateur de région utilise l'autre région configurée comme source. En d'autres termes, si une région est désactivée, le changement de région utilise l'autre région active comme source pour déterminer le pourcentage d'échelle.
Ce bloc prend en charge les modes d'exécution gracieux et disgracieux. Des paramètres incorrects provoquent un *basculement* de la base de données globale Aurora, ce qui peut entraîner une perte de données.
Pour plus d'informations sur la reprise après sinistre d'Aurora Global Database, y compris le basculement et le basculement, consultez la section [Utilisation du basculement ou du basculement dans les bases de données mondiales Amazon Aurora dans le guide de l'utilisateur Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html).
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations de votre bloc d'exécution Aurora. Le changement de région vérifie que les informations suivantes sont correctes :
+ Le cluster global Aurora spécifié dans la configuration existe.
+ Il existe des clusters de base de données Aurora dans les régions source et de destination.
+ Les clusters de base de données source et de destination sont dans un état qui permet le passage d'une base de données globale à un autre.
+ Il existe des instances de base de données dans les clusters source et de destination
+ Les versions du moteur de cluster global pour l'action de commutation sont compatibles. Cela inclut de vérifier que les clusters utilisent les mêmes versions majeure, mineure et correctif, à quelques exceptions près répertoriées dans la documentation Aurora.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations requises pour le basculement et le basculement d'Aurora. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution Aurora. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec l'Aurora lorsque cette étape s'exécute pendant l'exécution d'un plan.
# Bloc d'exécution Amazon DocumentDB Global Cluster
Le bloc d'exécution Amazon DocumentDB Global Cluster vous permet d'exécuter un flux de travail de restauration en cas de *basculement* ou de *basculement* pour un cluster global.
+ Basculement : utilisez cette approche pour récupérer après une panne imprévue. Avec cette approche, vous effectuez un basculement entre régions vers l'un des clusters secondaires de votre cluster global Amazon DocumentDB. L'objectif du point de récupération (RPO) pour cette approche est généralement une valeur différente de zéro mesurée en secondes. L'ampleur de la perte de données dépend du délai global de réplication du cluster Amazon DocumentDB Régions AWS au moment de l'échec.
+ Basculement : utilisez cette approche pour des scénarios contrôlés, tels que la maintenance opérationnelle et d'autres procédures opérationnelles planifiées dans lesquels tous les clusters Amazon DocumentDB sont sains. Comme cette fonctionnalité synchronise les clusters secondaires avec les clusters principaux avant d'apporter d'autres modifications, le RPO est égal à 0 (aucune perte de données).
## Configuration
Pour configurer un bloc d'exécution Amazon DocumentDB Global Cluster, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique d'exécution par blocs d'Amazon DocumentDB Global Cluster](security_iam_region_switch_documentdb.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Identifiant du cluster global Amazon DocumentDB :** entrez l'identifiant du cluster global.
1. **ARN du cluster pour *la région* :** entrez l'ARN du cluster à utiliser dans chaque région du plan.
1. **Spécifiez l'option pour le cluster Amazon DocumentDB :** choisissez **Switchover ou **Failover**** (perte de données).
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
En configurant un bloc d'exécution Amazon DocumentDB Global Cluster, vous pouvez basculer ou basculer sur des clusters globaux dans le cadre de la restauration de votre application. Si vous utilisez une active/active approche, le commutateur de région utilise l'autre région configurée comme source. En d'autres termes, si une région est désactivée, le changement de région utilise l'autre région active comme source pour déterminer le pourcentage d'échelle.
Ce bloc prend en charge les modes d'exécution gracieux et disgracieux. Des paramètres incorrects provoquent un basculement d'Amazon DocumentDB Global *Cluster*, ce qui peut entraîner une perte de données.
Pendant les opérations de basculement ou de basculement, le point de terminaison DNS utilisé par les clients pour écrire sera modifié. Les clients sont tenus de s'assurer qu'ils utilisent le bon point de terminaison une fois l'opération terminée.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations de votre bloc d'exécution Amazon DocumentDB. Le changement de région vérifie que les informations suivantes sont correctes :
+ Le cluster global Amazon DocumentDB spécifié dans la configuration existe.
+ Il existe des clusters Amazon DocumentDB dans les régions source et de destination.
+ Les clusters source et de destination sont disponibles.
+ Il existe des instances dans les clusters source et de destination.
+ Les versions du moteur de cluster global sont compatibles.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations requises pour le basculement et le basculement d'Amazon DocumentDB. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution Amazon DocumentDB. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec Amazon DocumentDB lorsque cette étape s'exécute pendant l'exécution d'un plan.
# Bloc d'exécution Amazon RDS Promote Read Replica
Le bloc d'exécution Amazon RDS Promote Read Replica vous permet de promouvoir une réplique de lecture Amazon RDS vers une instance de base de données autonome dans le cadre de votre processus de restauration multirégional. Cela vous permet de basculer vers une région saine en faisant de la réplique lue de cette région la nouvelle base de données principale.
## Configuration
Pour configurer un bloc d'exécution Amazon RDS Promote Read Replica, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique relative aux blocs d'exécution Amazon RDS](security_iam_region_switch_rds.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **ARN de l'instance de base de données RDS pour la région :** entrez l'ARN de l'instance de base de données pour la réplique lue dans chaque région du plan.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
En configurant un bloc d'exécution Amazon RDS Promote Read Replica, vous pouvez transformer une réplique en lecture en instance de base de données autonome dans le cadre de la restauration de votre application. Lorsque vous exécutez le plan, Region Switch fait en sorte que la réplique en lecture de la région que vous activez devienne une instance de base de données indépendante.
**Note**
Ce bloc ne prend en charge que les active/passive plans
Pendant la promotion, le point de terminaison DNS que vous utilisez pour vous connecter à la base de données restera le même. Toutefois, l'instance promue ne sera plus répliquée à partir de la base de données principale d'origine. Il vous incombe de vous assurer que leur application est configurée pour utiliser le point de terminaison approprié une fois l'opération terminée.
Après la promotion, l'instance promue hérite des paramètres de sauvegarde suivants de l'instance principale d'origine :
+ Période de rétention des sauvegardes
+ Fenêtre de sauvegarde préférée
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations de votre bloc d'exécution Amazon RDS. Le changement de région vérifie que les informations suivantes sont correctes :
+ Les instances de base de données Amazon RDS spécifiées dans la configuration existent.
+ Les instances de base de données dans les régions non principales sont des répliques de lecture.
+ Les répliques de lecture sont dans un état disponible.
+ Les instances de base de données sont correctement configurées pour la réplication entre régions.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations requises pour la promotion des répliques de lecture sur Amazon RDS. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution Amazon RDS. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec Amazon RDS lorsque cette étape s'exécute pendant l'exécution d'un plan.
# Amazon RDS Create Inter-Region Replica : bloc d'exécution
Le bloc d'exécution Amazon RDS Create Cross-Replica vous permet de créer une réplique de lecture interrégionale pour une instance de base de données Amazon RDS dans le cadre de votre processus de post-restauration. Ce bloc d'exécution est généralement utilisé après la promotion d'une réplique en lecture pour rétablir la réplication entre régions, garantissant ainsi que votre application est prête pour les futurs événements régionaux.
## Configuration
Pour configurer un bloc d'exécution Amazon RDS Create Cross-Region Replica, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique relative aux blocs d'exécution Amazon RDS](security_iam_region_switch_rds.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **ARN de l'instance de base de données source pour la région :** entrez l'ARN de l'instance de base de données pour la base de données source dans chaque région du plan. Le bloc d'exécution utilise l'identifiant de la région activée comme base de données source pour créer la réplique de lecture entre régions.
1. **ARN de l'instance de base de données de réplique :** entrez l'ARN de l'instance à utiliser pour la nouvelle réplique de lecture.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
En configurant un bloc d'exécution Amazon RDS Create Cross-Region Replica, vous pouvez créer une réplique en lecture dans l'autre région dans le cadre de votre processus de post-restauration. Ce bloc d'exécution est conçu pour s'exécuter après un basculement réussi afin de rétablir la réplication entre régions.
Ce bloc ne peut être ajouté qu'aux active/passive plans.
Au cours de l'exécution, l'ancienne instance principale sera renommée et étiquetée avec *renamedByRegionSwitch*. Ensuite, une nouvelle instance de réplique en lecture sera créée avec les paramètres suivants copiés à partir de l'ancien serveur principal :
+ Identifiant de l'instance
+ Groupes de paramètres DB
+ Groupes de sous-réseaux DB
+ Clé KMS
+ Groupes de sécurité VPC
+ Groupes d’options
+ Configuration multi-AZ
+ Secret d'authentification de domaine (ARN)
**Important**
L'instance principale renommée reste active et continue d'être facturée. Region Switch l'associe à *renamedByRegionSwitch* à des fins d'identification, mais ne le modifie ni ne le supprime autrement. Vous êtes chargé de gérer l'instance renommée, notamment de décider de la maintenir en activité, de l'arrêter ou de la supprimer en fonction de vos exigences opérationnelles et financières.
**Note**
Ce bloc d'exécution est conçu pour les flux de travail après restauration et nécessite que la région source soit saine et accessible. Il doit être utilisé après un basculement réussi pour rétablir la réplication entre régions.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations de votre bloc d'exécution Amazon RDS. Le changement de région vérifie que les informations suivantes sont correctes :
+ Les instances de base ARNs de données de la configuration sont valides et correctement formatées.
+ Les instances de base de données source existent dans leurs régions respectives.
+ Les instances de base de données source sont disponibles.
Le changement de région confirme également que le rôle IAM du plan dispose des autorisations requises pour créer des répliques de lecture Amazon RDS. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution Amazon RDS. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec Amazon RDS lorsque cette étape s'exécute pendant l'exécution d'un plan.
# Bloc d'exécution de l'approbation manuelle
Le bloc d'exécution manuelle de l'approbation vous permet d'insérer une étape d'approbation que vous associez à un rôle IAM. Les utilisateurs ayant accès au rôle peuvent approuver ou refuser l'exécution d'une étape, suspendre l'étape jusqu'à ce que l'approbation soit accordée ou, éventuellement, empêcher le plan de progresser.
Pour garantir que l'approbation manuelle est requise lors de l'exécution du plan, vous saisissez une étape d'approbation manuelle à un emplacement spécifique du flux de travail, puis vous configurez le rôle IAM pour spécifier qui peut approuver l'étape.
## Configuration
Pour configurer un bloc d'exécution d'approbation manuelle, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique d'exécution des approbations manuelles](security_iam_region_switch_manual_approval.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **Rôle d'approbation IAM :** entrez l'ARN d'un rôle IAM autorisé à approuver manuellement la poursuite de l'exécution pour le plan de changement de région. Le rôle IAM doit figurer dans le compte propriétaire du plan.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
En configurant un bloc d'exécution d'approbation manuelle, vous pouvez demander une approbation dans le cadre de la restauration de votre application. Pour un bloc d'exécution manuelle, Region Switch effectue les opérations suivantes :
+ Lorsque Region Switch exécute un bloc d'exécution manuelle, il suspend l'exécution et définit le statut d'exécution du plan sur En attente d'approbation.
+ Toute personne ayant accès au rôle défini dans le bloc d'exécution peut approuver ou refuser l'exécution de l'étape.
+ S'ils approuvent l'exécution de l'étape, Region Switch procède à l'exécution du plan. S'ils refusent, le changement de région annule l'exécution du plan.
Ce bloc ne prend pas en charge le mode d'exécution peu scrupuleux.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Le changement de région n'effectue aucune évaluation pour les blocs d'exécution d'approbation manuelle.
# Action personnalisée : bloc d'exécution Lambda
Le bloc d'exécution Lambda d'actions personnalisées vous permet d'ajouter une étape personnalisée à un plan à l'aide d'une fonction Lambda.
## Configuration
Pour configurer un bloc d'exécution Lambda, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de bloc d'exécution Lambda pour les actions personnalisées](security_iam_region_switch_lambda.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **ARN de la fonction Lambda à invoquer lors de l'activation ou de la désactivation de *Region*** : Spécifiez l'ARN de la fonction Lambda à exécuter pour cette étape.
1. **Région dans laquelle exécuter la fonction Lambda :** dans le menu déroulant, choisissez la région dans laquelle vous souhaitez exécuter les fonctions Lambda.
1. **Délai d'expiration :** entrez une valeur de délai d'expiration.
1. **Intervalle entre les tentatives :** entrez un intervalle entre les tentatives, pour réexécuter la fonction Lambda si elle échoue dans cet intervalle.
Choisissez ensuite **Enregistrer l'étape.**
## Comment ça marche
+ Lorsque vous créez un bloc d'exécution Lambda d'action personnalisé, vous devez spécifier deux fonctions Lambda pour l'étape à exécuter, une dans chacune des régions du plan.
+ Vous pouvez configurer la région dans laquelle vous souhaitez que le Lambda s'exécute, par exemple, dans la région d'activation ou dans la région de désactivation. Toutefois, si vous exécutez dans la région de désactivation, vous devenez dépendant de cette région. Nous vous déconseillons de devenir dépendant de la région de désactivation.
Ce bloc prend en charge les modes d'exécution gracieux et disgracieux. En mode d'exécution peu élégant, Region Switch ignore l'étape du bloc d'exécution Lambda.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations de votre bloc d'exécution Lambda. Le changement de région vérifie que les informations suivantes sont correctes :
+ Les fonctions Lambda spécifiées dans la configuration existent.
+ Les paramètres de simultanéité des fonctions Lambda ne sont pas limités, notamment en vérifiant les points suivants :
+ La simultanéité n'est pas définie sur 0.
+ Au moins une exécution simultanée est disponible, ou cette simultanéité non réservée existe.
Le commutateur de région exécute une exécution à sec de la fonction Lambda pour valider les paramètres et les autorisations spécifiés, sans exécuter la logique de la fonction elle-même. Les coûts Lambda standard sont encourus lorsque vous effectuez un essai à sec.
Le changement de région valide également que le rôle IAM du plan dispose des autorisations requises pour l'exécution de Lambda. Pour plus d'informations sur les autorisations requises pour les blocs d'exécution de commutateurs régionaux, consultez[Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md).
Les autorisations IAM correctes sont essentielles au bon fonctionnement du bloc d'exécution Lambda. Si l'une de ces validations échoue, Region Switch renvoie des avertissements indiquant la présence de problèmes et fournit des messages d'erreur spécifiques pour vous aider à résoudre les problèmes d'autorisation ou de configuration. Cela garantit que votre plan dispose de l'accès nécessaire pour gérer et interagir avec le Lambda lorsque cette étape s'exécute pendant l'exécution d'un plan.
# Bloc d'exécution du contrôle de santé Amazon Route 53
Le bloc d'exécution du bilan de santé d'Amazon Route 53 vous permet de spécifier les régions vers lesquelles le trafic de votre application sera redirigé lors du basculement. Le bloc d'exécution crée des bilans de santé Amazon Route 53, que vous associez ensuite aux enregistrements DNS Route 53 de votre compte. Lorsque vous exécutez votre plan de changement de région, l'état du bilan de santé de Route 53 est mis à jour et le trafic est redirigé en fonction de votre configuration DNS.
**Important**
La zone hébergée Route 53 doit se trouver dans la même partition que le plan de changement de région.
## Configuration
Pour configurer un bloc d'exécution du contrôle de santé Route 53, entrez les valeurs suivantes.
**Important**
Avant de configurer le bloc d'exécution, assurez-vous que vous avez mis en place la bonne stratégie IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de bloc d'exécution du bilan de santé Route 53](security_iam_region_switch_route53.md).
1. **Nom de l'étape :** entrez un nom.
1. **Description de l'étape (facultatif) :** entrez une description de l'étape.
1. **ID de zone hébergée :** ID de zone hébergée pour votre domaine et vos enregistrements DNS dans Route 53.
1. **Nom de l'enregistrement :** entrez le nom de l'enregistrement (nom de domaine) pour les enregistrements que vous utilisez, avec les contrôles de santé associés, pour rediriger le trafic vers votre application. Le changement de région trouvera les ensembles d'enregistrements Route 53 pour le nom de l'enregistrement et tentera de mapper chaque ensemble d'enregistrements à une région, en fonction du nom de région figurant dans la **valeur** ou l'**identifiant d'ensemble** du jeu d'enregistrements.
1. **Identifiants du jeu d'enregistrements (facultatif) :** vous avez la possibilité de fournir manuellement les identifiants du jeu d'enregistrements si le changement de région ne peut pas automatiquement mapper les ensembles d'enregistrements aux régions à partir du nom d'enregistrement fourni à l'étape 4 une fois que vous avez créé le plan. Si l'évaluation du plan renvoie un avertissement indiquant que des informations supplémentaires sont requises, mettez à jour votre plan avec des identifiants records en incluant les éléments suivants pour chaque région :
+ **Identifiant du jeu d'enregistrements :** entrez l'**identifiant du set** ou la **valeur/route du trafic pour** le set d'enregistrements.
+ **Région :** entrez la région associée au jeu d'enregistrements contenant les informations d'identification du jeu d'enregistrements.
1. Choisissez **Enregistrer l'étape.**
1. Configurez les contrôles de santé dans Route 53.
Le commutateur de région fournit un identifiant de contrôle de santé, pour chaque région, pour chaque nom d'enregistrement au sein d'une zone hébergée définie dans le bloc d'exécution. Assurez-vous de configurer les contrôles de santé pour les ensembles d'enregistrements correspondants de votre compte dans Route 53 afin que le changement de région puisse rediriger correctement le trafic vers votre application pendant l'exécution du plan. Dans l'onglet **Health checks** de la page des détails du plan, vous pouvez consulter les bilans de santé de tous les blocs d'exécution et de toutes les régions.
## Comment ça marche
Vous ajoutez une étape de vérification de l'état à votre flux de travail de changement de région afin de pouvoir rediriger le trafic vers une région secondaire, pour les active/passive configurations, ou hors d'une région désactivée, pour les active/active configurations. Si vous ajoutez plusieurs flux de travail à votre plan, fournissez les mêmes valeurs de configuration pour tous les blocs d'exécution des contrôles de santé qui utilisent les mêmes enregistrements DNS.
Sur la base des informations que vous fournissez lorsque vous configurez le bloc d'exécution, Region Switch tente de déterminer le jeu d'enregistrements correct pour chaque région de votre plan. Généralement, l'ID de zone hébergée et le nom de l'enregistrement sont des informations suffisantes pour déterminer les ensembles d'enregistrements et les régions associées. Dans le cas contraire, lorsque Region Switch exécute son évaluation automatique du plan après avoir créé le plan, un avertissement est renvoyé pour vous informer que des informations supplémentaires sont nécessaires.
Le commutateur de région envoie des bilans de santé pour chaque bloc d'exécution du bilan de santé Route 53. Pour les plans qui utilisent une approche de active/passive reprise, le bilan de santé de la région principale commence comme étant sain, et le bilan de santé de la région de secours est initialement défini comme non sain. Pour les plans qui utilisent l'approche du active/active rétablissement, les bilans de santé pour toutes les régions commencent par un état de santé sain.
Pour permettre à Region Switch d'exécuter correctement ce bloc d'exécution pour votre plan, vous devez ajouter les contrôles de santé à vos enregistrements DNS.
Pour un active/active plan, l'étape d'exécution fonctionne de la manière suivante :
+ Lorsqu'un flux de travail de désactivation s'exécute pour une région, le bilan de santé est défini sur « non fonctionnel » et le trafic n'est plus dirigé vers la région.
+ Lorsqu'un flux de travail d'activation est exécuté pour une région, le bilan de santé est réglé sur sain et le trafic est acheminé vers la région.
Pour un active/passive plan, l'étape d'exécution fonctionne de la manière suivante :
+ Lorsqu'un flux de travail d'activation s'exécute pour une région, le bilan de santé de cette région est défini sur sain et le trafic est acheminé vers la région. Dans le même temps, le bilan de santé de l'autre région du plan est défini comme étant insalubre et les arrêts de circulation sont dirigés vers cette région.
## Ce qui est évalué dans le cadre de l'évaluation du plan
Lorsque Region Switch évalue votre plan, Region Switch effectue plusieurs vérifications sur la configuration et les autorisations du bloc d'exécution du bilan de santé Route 53. Le changement de région vérifie que les contrôles de santé sont attachés aux enregistrements DNS spécifiés dans la configuration du bloc d'exécution. En d'autres termes, le changement de région vérifie que les enregistrements DNS d'une région spécifique Région AWS sont configurés pour utiliser des contrôles de santé pour cette région.
## Comparaison des contrôles de routage ARC et des blocs d'exécution des contrôles de santé Route 53
Le bloc d'exécution du contrôle de santé Amazon Route 53 dans Region Switch constitue une alternative moins coûteuse pour la gestion du trafic basée sur le DNS. Toutefois, ce bloc d'exécution dépend de la région Région AWS que vous activez, de sorte que cette région doit être disponible. Cela répond aux besoins de la plupart des clients, car ils activent une région saine.
Les contrôles de routage ARC fournissent une gestion du trafic hautement fiable basée sur le DNS avec un SLA de disponibilité à 100 %. Grâce aux contrôles de routage, vos équipes opérationnelles peuvent transférer le trafic entre les régions à l'aide de glissières de sécurité. Les contrôles de routage fournissent une solution à locataire unique avec un SLA de 100 %. Un cluster de contrôle de routage est réparti sur cinq régions et peut tolérer que deux régions soient hors ligne. Si vous avez des applications très critiques, pensez à utiliser des contrôles de routage.
Les contrôles de routage ne sont pas nécessaires pour utiliser le changement de région. Vous pouvez utiliser le commutateur de région pour gérer la redirection du trafic en utilisant les blocs d'exécution des contrôles de santé de Route 53 sans contrôles de routage.
Les contrôles de routage ajoutent de la valeur avec le changement de région dans les situations suivantes :
+ Vous avez besoin du SLA de disponibilité à 100 % pour le mécanisme de contrôle du trafic lui-même.
+ Votre entreprise a besoin de contrôles opérationnels manuels assortis de règles de sécurité pour les applications critiques.
+ Vous voulez defense-in-depth que les équipes opérationnelles puissent annuler manuellement le routage automatique du trafic si nécessaire.
Les blocs d'exécution du bilan de santé de Route 53 ne dépendent pas du plan de contrôle. Les modifications apportées aux dossiers de contrôle de santé utilisent le plan de données, de sorte qu'elles ne nécessitent pas la région d'activation pour traiter les mises à jour de configuration. Les blocs d'exécution du bilan de santé Route 53 sont suffisants dans les situations suivantes :
+ Votre application peut dépendre de Région AWS celle que vous activez.
+ La redirection automatique du trafic dans le cadre du processus de restauration répond à vos exigences.
+ L'optimisation des coûts est une priorité. Les blocs d'exécution des contrôles de santé Route 53 sont moins coûteux que les contrôles de routage.
La plupart des clients commencent par utiliser les blocs d'exécution des contrôles d'état de Route 53 comme mécanisme de routage du trafic par défaut et ajoutent des contrôles de routage uniquement pour leurs applications les plus critiques qui nécessitent le plus haut niveau de fiabilité pour le mécanisme de gestion du trafic.
# Créez des plans pour enfants
Pour prendre en charge des scénarios de reprise plus complexes, vous pouvez créer des plans enfants en les ajoutant à l'aide de blocs d'exécution du plan de changement de région. La hiérarchie est limitée à deux niveaux, mais un plan parental peut inclure plusieurs forfaits pour enfants.
**Important**
Avant de créer un forfait enfant, assurez-vous d'avoir mis en place la bonne politique IAM. Pour de plus amples informations, veuillez consulter [Exemple de politique de bloc d'exécution d'un plan de changement de région](security_iam_region_switch_plan_execution.md).
Pour des raisons de compatibilité, les forfaits pour enfants doivent prendre en charge toutes les régions prises en charge par le plan parent. De plus, l'approche de rétablissement, active active/active ou passive, doit être la même pour les plans parents-enfants.
Gardez à l'esprit les manières suivantes selon lesquelles un forfait enfant répond aux modifications que vous apportez à un plan parental et aux scénarios du plan parental.
+ Un bloc d'exécution parent est marqué comme terminé lorsque tous les plans enfants et les autres blocs d'exécution qu'il contient sont terminés.
+ Si une étape échoue dans un plan enfant, le bloc d'exécution du plan de changement de région échoue dans le plan parent.
+ Les actions de contrôle initiées dans le plan parent lors de l'étape de changement de région, telles qu'une pause, un changement progressif ou abusif ou une annulation, sont automatiquement tentées sur le plan enfant, quelle que soit l'étape actuelle du plan enfant.
+ Les opérations de saut ont un comportement particulier : le plan parent est ignoré, mais le plan enfant continue de s'exécuter.
+ Si un plan enfant est déjà en cours d'exécution dans un bloc de commutation régional, afin de déterminer s'il continue de fonctionner, le changement de région évalue la compatibilité du plan enfant avec le plan parent. Si la configuration du plan enfant correspond aux exigences du plan parent, Region Switch traite le plan enfant comme s'il avait été initié par le plan parent.
+ L'étape du plan parent échouera si le plan enfant est exécuté avec des paramètres de configuration incompatibles, tels que les suivants :
+ Le plan pour enfants fonctionne dans une autre région
+ Le plan enfant exécute une opération de désactivation lorsque le commutateur de région s'attend à ce qu'il exécute une opération d'activation
+ Si le plan enfant se termine avec succès pendant une période pendant laquelle un plan parent est suspendu, le plan parent sera couronné de succès lorsque le plan parent reprendra.
# Créer un déclencheur pour un plan de changement de région
Si vous souhaitez automatiser la restauration de votre application dans Region Switch, vous pouvez créer un ou plusieurs déclencheurs pour votre plan de changement de région. Les déclencheurs commencent automatiquement à exécuter un plan de changement de région, en fonction des conditions CloudWatch d'alarme que vous choisissez.
# Pour créer un déclencheur pour un plan de changement de région
1. Après avoir créé un plan, sur la page des **détails du plan**, sélectionnez l'onglet **Déclencheurs**.
1. Choisissez **Gérer les déclencheurs**.
1. Sélectionnez les flux de travail dont vous souhaitez automatiser l'exécution, puis choisissez **Ajouter un déclencheur**.
1. Fournissez une description du déclencheur.
1. Sélectionnez une CloudWatch alarme, puis sélectionnez jusqu'à 10 CloudWatch alarmes pour créer les conditions du déclenchement.
Lorsque vous sélectionnez plusieurs conditions, toutes les conditions doivent être remplies avant que l'exécution automatique du plan ne commence.
Le déclencheur lance l'exécution du plan lorsqu'une CloudWatch alarme passe aux conditions requises pour le déclenchement. Lorsque le déclencheur est ajouté au plan, si les conditions sont déjà remplies, le plan ne s'exécute pas, ce qui empêche les événements de basculement involontaires.
# Exécuter un plan de changement de région pour récupérer une application
Pour récupérer une application lorsqu'elle Région AWS est défectueuse, vous devez exécuter un plan de changement de région dans Amazon Application Recovery Controller (ARC).
+ Si votre application est déployée selon une active/active approche, les flux de travail de votre plan désactivent la région affectée afin que votre autre région active soit correctement dimensionnée et commence à recevoir tout le trafic de votre application.
+ Si votre application est déployée selon une active/passive approche, les flux de travail de votre plan désactivent la région affectée et activent votre région de secours, en y augmentant vos ressources, si nécessaire, et en redirigeant le trafic de votre application vers la région de secours.
Pour restaurer une application manuellement, exécutez votre plan de changement de région en procédant comme suit.
Une autre option consiste à déclencher automatiquement une exécution avec des CloudWatch alarmes Amazon spécifiques que vous spécifiez pour démarrer l'exécution d'un plan. Vous pouvez spécifier des déclencheurs pour l'exécution du plan lorsque vous créez ou mettez à jour un plan. Pour de plus amples informations, veuillez consulter [Créer un déclencheur pour un plan de changement de région](working-with-rs-triggers.md).
# Pour exécuter un plan de changement de région
1. Dans le AWS Management Console, accédez à celui Région AWS que vous souhaitez activer pour votre application.
1. Sur la console Amazon Application Recovery Controller (ARC), choisissez **Region Switch**, puis sélectionnez le plan que vous souhaitez exécuter.
1. Choisissez **Execute plan**.
1. Si votre plan inclut des étapes d'approbation manuelles, approuvez chaque étape lorsque vous y êtes invité.
Pendant l'exécution d'un plan, vous pouvez suivre sa progression sur la page des détails de l'exécution, qui s'ouvre lorsque vous choisissez d'exécuter un plan.
Vous pouvez également consulter les informations relatives à la restauration des applications en cours sur les tableaux de bord des changements de région. Sur la console de changement de région, dans le menu de navigation de gauche, sous **Changement de région**, choisissez l'une des options suivantes :
+ **Tableau de bord mondial**
+ **Exécutions dans le *nom de la région***
Sachez que, s'il y a des déficiences dans une région, le tableau de bord mondial risque de ne pas afficher toutes les données de votre plan. Pour cette raison, nous vous recommandons de vous fier uniquement au tableau de bord des exécutions régionales lors d'événements opérationnels. Le tableau de bord des exécutions régionales est plus résilient car il utilise le plan de données du commutateur régional local.
Lorsque l'exécution du plan est terminée, vous pouvez voir des informations sur l'exécution du plan, ainsi que sur les autres plans exécutés par Region Switch, sur la page **Détails du plan** dans l'onglet **Historique de l'exécution du plan**.
# Tableaux de bord de changement de région
Le changement de région inclut un tableau de bord global que vous pouvez utiliser pour observer l'état des plans de changement de région au sein de votre organisation et des régions. Le changement de région dispose également d'un tableau de bord des exécutions régionales qui affiche uniquement les exécutions de plans dans la région à laquelle vous êtes actuellement connecté AWS Management Console.
Sachez que, s'il y a des déficiences dans une région, le tableau de bord mondial risque de ne pas afficher toutes les données de votre plan. Pour cette raison, nous vous recommandons de vous fier uniquement au tableau de bord des exécutions régionales lors d'événements opérationnels. Le tableau de bord des exécutions régionales est plus résilient car il utilise le plan de données du commutateur régional local.
# Pour ouvrir le tableau de bord global du changement de région
1. Ouvrez la console ARC à l'adresse[https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Sous **Changer de région**, choisissez **Tableau de bord global**.
# Pour ouvrir le tableau de bord régional, changez de région
1. Ouvrez la console ARC à l'adresse[https://console.aws.amazon.com/route53recovery/home#/dashboard](https://console.aws.amazon.com/route53recovery/home#/dashboard).
1. Sous **Changer de région**, choisissez **Tableau de bord régional**.
# Support multicompte lors du changement de région
Dans le changement de région, vous pouvez ajouter des ressources provenant d'autres comptes à vos plans. Vous pouvez également partager un plan de changement de région avec d'autres comptes. Pour plus d’informations, consultez les sections suivantes.
## Ressources multi-comptes
Le changement de région permet d'héberger les ressources dans un compte distinct du compte contenant le plan de changement de région. Lorsque le changement de région exécute un plan, il assume le rôle ExecutionRole. Si le plan utilise des ressources provenant d'un compte différent de celui qui héberge le plan, le commutateur de région utilise le ExecutionRole pour assumer le rôle d'accès crossAccountRole à ces ressources.
Chaque ressource du plan de changement de région comporte deux champs facultatifs : crossAccountRole et ExternalId.
+ crossAccountRole: Ce rôle permet d'accéder aux ressources d'un compte différent de celui qui héberge le plan de changement de région. Le rôle n'a besoin que d'autorisations pour agir sur les ressources de son compte ; il n'a pas besoin d'autorisations pour agir sur les ressources du compte qui héberge le plan de changement de région.
+ ExternalId: il s'agit de l'ID externe STS issu de la politique de confiance du compte qui contient la ressource nécessitant une action. Il s'agit d'une chaîne alphanumérique qui constitue le secret partagé entre les deux comptes.
## Partage de forfaits de changement de région
Le changement de région s'intègre à AWS Resource Access Manager (AWS RAM) pour vous permettre de partager des plans entre plusieurs Comptes AWS. Lorsque vous partagez un plan, les comptes que vous spécifiez peuvent consulter les détails du plan, exécuter le plan et voir les exécutions du plan, ce qui permet un contrôle et une flexibilité accrus des capacités de restauration entre les différentes équipes.
Pour commencer à utiliser le partage entre comptes dans Region Switch, vous devez créer un partage de ressources dans AWS RAM. Le partage des ressources indique les participants autorisés à partager le plan associé à votre compte. Les participants peuvent consulter et exécuter le plan partagé via la console, la CLI ou AWS SDKs.
Important : vous Compte AWS devez être propriétaire des forfaits que vous souhaitez partager. Vous ne pouvez pas partager un plan qui a été partagé avec vous. Pour partager un plan avec votre organisation ou avec une unité organisationnelle AWS Organizations, vous devez activer le partage avec les Organizations.
Pour plus d'informations sur AWS RAM, voir[Support du partage des plans entre les comptes pour le changement de région ARC](resource-sharing.region-switch.md).
# Support du partage des plans entre les comptes pour le changement de région ARC
Amazon Application Recovery Controller (ARC) s'intègre AWS Resource Access Manager pour permettre le partage des ressources. AWS RAM est un service qui vous permet de partager des ressources avec d'autres personnes Comptes AWS ou par le biais de AWS Organizations. Pour le changement de région ARC, vous pouvez partager le plan de changement de région. (Pour utiliser les ressources d'un autre compte dans votre plan, vous utilisez un rôle CrossAccount. Pour en savoir plus, consultez[Ressources multi-comptes](cross-account-resources-rs.md#cross-account-resources-rs-in-plan).)
Avec AWS RAM, vous partagez les ressources que vous possédez en créant un *partage de ressources*. Un partage de ressources indique les ressources à partager et les *participants* avec lesquels les partager. Les participants peuvent inclure :
+ Spécifique Comptes AWS à l'intérieur ou à l'extérieur de l'organisation du propriétaire dans AWS Organizations
+ Une unité organisationnelle au sein de son organisation dans AWS Organizations
+ Toute son organisation en AWS Organizations
Pour plus d'informations AWS RAM, consultez le *[guide de AWS RAM l'utilisateur](https://docs.aws.amazon.com/ram/latest/userguide/)*.
En utilisant AWS Resource Access Manager pour partager des plans entre des comptes dans ARC, vous pouvez utiliser un plan avec plusieurs plans différents Comptes AWS. Lorsque vous choisissez de partager un plan, un autre plan Comptes AWS que vous spécifiez peut exécuter le plan pour effectuer la restauration de l'application.
AWS RAM est un service qui aide les AWS clients à partager des ressources en toute sécurité Comptes AWS. Avec AWS RAM, vous pouvez partager des ressources au sein d'une organisation ou d'unités organisationnelles (OUs) dans AWS Organizations, en utilisant des rôles et des utilisateurs IAM. AWS RAM est un moyen centralisé et contrôlé de partager un plan.
Lorsque vous partagez un plan, vous pouvez réduire le nombre total de plans dont votre organisation a besoin. Avec un plan partagé, vous pouvez répartir le coût total de l'exécution du plan entre différentes équipes, afin de maximiser les avantages de l'ARC à moindre coût. Le partage de plans entre comptes peut également faciliter le processus d'intégration de plusieurs applications dans ARC, en particulier si vous avez un grand nombre d'applications réparties entre plusieurs comptes et équipes opérationnelles.
Pour commencer à utiliser le partage entre comptes dans ARC, vous devez créer un *partage de ressources* dans n. AWS RAM Le partage des ressources indique les *participants* autorisés à partager le plan associé à votre compte.
Cette rubrique explique comment partager les ressources que vous possédez et comment utiliser les ressources qui sont partagées avec vous.
**Topics**
+ [Conditions préalables au partage de plans](#sharing-prereqs-rs)
+ [Partage d'un plan](#sharing-share-rs)
+ [Annulation du partage d'un forfait partagé](#sharing-unshare-rs)
+ [Identification d'un plan partagé](#sharing-identify-rs)
+ [Responsabilités et autorisations pour les forfaits partagés](#sharing-perms-rs)
+ [Frais de facturation](#sharing-billing-rs)
+ [Quotas](#sharing-quotas-rs)
## Conditions préalables au partage de plans
+ Pour partager un plan, vous devez le posséder dans votre Compte AWS. Cela signifie que la ressource doit être allouée ou provisionnée dans votre compte. Vous ne pouvez pas partager un plan qui a été partagé avec vous.
+ Pour partager un plan avec votre organisation ou une unité organisationnelle dans AWS Organizations, vous devez activer le partage avec AWS Organizations. Pour de plus amples informations, veuillez consulter [Activer le partage avec AWS Organizations](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs) dans le *Guide de l'utilisateur AWS RAM *.
## Partage d'un plan
Lorsque vous partagez un plan, les participants que vous désignez pour le partager peuvent consulter et, si vous accordez des autorisations supplémentaires, exécuter le plan.
Pour partager un plan, vous devez l'ajouter à un partage de ressources. Un partage de ressources est une ressource AWS RAM qui vous permet de partager vos ressources entre des Comptes AWS. Un partage de ressources indique les ressources à partager et les participants avec lesquels elles sont partagées. Pour partager un plan, vous pouvez créer un nouveau partage de ressources ou ajouter la ressource à un partage de ressources existant. Pour créer un nouveau partage de ressources, vous pouvez utiliser la [AWS RAM console](https://console.aws.amazon.com/ram) ou utiliser les opérations AWS RAM d'API avec le AWS Command Line Interface ou AWS SDKs.
Si vous faites partie d'une organisation AWS Organizations et que le partage au sein de votre organisation est activé, les participants de votre organisation ont automatiquement accès au plan partagé. Dans le cas contraire, les participants reçoivent une invitation à rejoindre le partage des ressources et ont accès au plan partagé après avoir accepté l'invitation.
Vous pouvez partager un plan dont vous êtes propriétaire en utilisant la AWS RAM console ou en utilisant des opérations d' AWS RAM API avec le AWS CLI ou SDKs.
**Pour partager un forfait dont vous êtes propriétaire à l'aide de la AWS RAM console**
Voir [Création d'un partage de ressources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) dans le *guide de AWS RAM l'utilisateur*.
**Pour partager un forfait dont vous êtes propriétaire à l'aide du AWS CLI**
Utilisez la commande [create-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/create-resource-share.html).
**Octroi d'autorisations pour partager des forfaits**
Le partage de plans entre comptes nécessite les autorisations supplémentaires suivantes pour que le principal IAM partage le plan en utilisant AWS RAM :
```
# read and execute plan permissions
"arc-region-switch:GetPlan",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:StartPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:UpdatePlanExecutionStep"
```
Le propriétaire qui partage le plan doit disposer des autorisations suivantes. Si vous tentez de partager un plan AWS RAM sans disposer de ces autorisations, une erreur est renvoyée.
```
"arc-region-switch:PutResourcePolicy" # Permission only apis
"arc-region-switch:DeleteResourcePolicy" # Permission only apis
"arc-region-switch:GetResourcePolicy" # Permission only apis
```
Pour plus d'informations sur le mode d' AWS Resource Access Manager utilisation de l'IAM, voir [Comment AWS Resource Access Manager utilise l'IAM](https://docs.aws.amazon.com/ram/latest/userguide/security-iam-policies.html) dans le guide de l'*AWS RAM utilisateur*.
## Annulation du partage d'un forfait partagé
Lorsque vous annulez le partage d'un plan, les règles suivantes s'appliquent aux participants et aux propriétaires :
+ Les participants ne peuvent plus consulter ni exécuter le plan non partagé.
Pour annuler le partage d'un plan partagé dont vous êtes propriétaire, supprimez-le du partage de ressources. Vous pouvez le faire en utilisant la AWS RAM console ou en utilisant des opérations AWS RAM d'API avec le AWS CLI ou SDKs.
**Pour annuler le partage d'un forfait partagé dont vous êtes propriétaire à l'aide de la console AWS RAM**
Consultez la section [Mise à jour d'un partage de ressources](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing.html#working-with-sharing-update) du *Guide de l'utilisateur AWS RAM *.
**Pour annuler le partage d'un forfait partagé dont vous êtes propriétaire à l'aide du AWS CLI**
Utilisez la commande [disassociate-resource-share](https://docs.aws.amazon.com/cli/latest/reference/ram/disassociate-resource-share.html).
## Identification d'un plan partagé
Les propriétaires et les participants peuvent identifier les plans partagés en consultant les informations dans AWS RAM. Ils peuvent également obtenir des informations sur les ressources partagées à l'aide de la console ARC et AWS CLI.
En général, pour en savoir plus sur les ressources que vous avez partagées ou qui ont été partagées avec vous, consultez les informations du guide de l' AWS Resource Access Manager utilisateur :
+ En tant que propriétaire, vous pouvez consulter toutes les ressources que vous partagez avec d'autres personnes en utilisant AWS RAM. Pour plus d'informations, consultez la section [Affichage de vos ressources partagées dans AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-view-sr.html).
+ En tant que participant, vous pouvez consulter toutes les ressources partagées avec vous en utilisant AWS RAM. Pour plus d'informations, consultez la section [Affichage de vos ressources partagées dans AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-view-sr.html).
En tant que propriétaire, vous pouvez déterminer si vous partagez un plan en consultant les informations dans AWS Management Console ou en utilisant les opérations AWS Command Line Interface de l'API ARC.
**Pour déterminer si un plan dont vous êtes propriétaire est partagé à l'aide de la console**
Sur la AWS Management Console page de détails d'un plan, consultez l'**état du partage du plan**.
En tant que participant, lorsqu'un plan est partagé avec vous, vous devez généralement accepter le partage afin de pouvoir accéder au plan.
## Responsabilités et autorisations pour les forfaits partagés
### Autorisations accordées aux propriétaires
Les participants peuvent consulter ou exécuter le plan (s'ils disposent des autorisations appropriées).
### Autorisations pour les participants
Lorsque vous partagez un plan que vous possédez avec d'autres personnes Comptes AWS, les participants peuvent consulter ou exécuter le plan (s'ils disposent des autorisations appropriées).
Lorsque vous partagez un plan en utilisant AWS RAM, un participant dispose, par défaut, d'autorisations en lecture seule. Pour consulter la liste des autorisations en lecture seule pour le changement de région, voir. [Autorisations en lecture seule](security_iam_region_switch_read_only.md) Les participants ont besoin d'autorisations supplémentaires pour exécuter un plan de changement de région. Les participants qui doivent exécuter des plans ont besoin d'autorisations supplémentaires. Sachez que vous ne pouvez pas autoriser un AWS RAM participant pour les opérations suivantes :
+ ` ApprovePlanExecutionStep`
+ ` UpdatePlan`
## Frais de facturation
Le propriétaire d'un plan dans ARC est facturé pour les coûts associés au plan. La création de ressources hébergées dans un plan n'entraîne aucun coût supplémentaire, pour les propriétaires de plans ou pour les participants.
Pour obtenir des informations détaillées sur les tarifs et des exemples, consultez la section [Tarification d'Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/pricing/).
## Quotas
Toutes les ressources créées dans un plan partagé sont prises en compte dans les quotas du propriétaire du plan.
Pour obtenir la liste des quotas des plans de changement de région, voir[Quotas pour le changement de région](quotas.region-switch.md).
# Identity and Access Management pour le changement de région dans ARC
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources ARC. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Comment fonctionne le changement de région avec IAM](security_iam_service-with-iam-region-switch.md)
+ [Exemples de politiques basées sur l’identité](security_iam_id-based-policy-examples-region-switch.md)
# Comment fonctionne le changement de région dans ARC avec IAM
Avant d'utiliser IAM pour gérer l'accès à ARC, découvrez quelles fonctionnalités IAM peuvent être utilisées avec ARC.
Avant d'utiliser IAM pour gérer l'accès au changement de région dans Amazon Application Recovery Controller (ARC), découvrez quelles fonctionnalités IAM peuvent être utilisées avec le changement de région.
**Fonctionnalités IAM que vous pouvez utiliser avec le changement de région dans Amazon Application Recovery Controller (ARC)**
| Fonctionnalité IAM | Support de changement de région |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-region-switch-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-region-switch-resource-based-policies) | Oui |
| [Actions de politique](#security_iam_service-with-iam-region-switch-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-region-switch-id-based-policies-resources) | Oui |
| [Clés de condition de politique](#security_iam_service-with-iam-region-switch-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-region-switch-acls) | Oui |
| [ABAC (étiquettes dans les politiques)](#security_iam_service-with-iam-region-switch-tags) | Oui |
| [Informations d’identification temporaires](#security_iam_service-with-iam-region-switch-roles-tempcreds) | Oui |
| [Autorisations de principal](#security_iam_service-with-iam-region-switch-principal-permissions) | Oui |
| [Rôles du service](#security_iam_service-with-iam-region-switch-roles-service) | Non |
| [Rôles liés à un service](#security_iam_service-with-iam-region-switch-roles-service-linked) | Non |
Pour obtenir une vue globale de haut niveau du fonctionnement des AWS services avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le Guide de l'utilisateur *IAM*.
## Politiques basées sur l'identité pour le changement de région
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
Pour consulter des exemples de politiques basées sur l'identité ARC, consultez. [Exemples de politiques basées sur l'identité dans Amazon Application Recovery Controller (ARC)](security_iam_id-based-policy-examples.md)
## Politiques basées sur les ressources dans le cadre du changement de région
**Prend en charge les politiques basées sur les ressources** : oui
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les politiques de confiance de rôle IAM et les politiques de compartiment Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique.
## Actions politiques pour le changement de région
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Les actions politiques dans ARC pour le changement de région utilisent les préfixes suivants avant l'action :
```
arc-region-switch
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules. Par exemple, ce qui suit :
```
"Action": [
"arc-region-switch:action1",
"arc-region-switch:action2"
]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "arc-region-switch:Describe*"
```
Pour voir des exemples de politiques basées sur l'identité ARC pour le changement de région, voir. [Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md)
## Ressources politiques pour le changement de région
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
Pour voir des exemples de politiques basées sur l'identité ARC pour le changement de région, voir. [Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md)
## Clés de conditions de politique pour le changement de région
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour voir des exemples de politiques basées sur l'identité ARC pour le changement de région, voir. [Exemples de politiques basées sur l'identité pour le changement de région dans ARC](security_iam_id-based-policy-examples-region-switch.md)
## Listes de contrôle d'accès (ACLs) dans le commutateur de région
**Supports ACLs :** Oui
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## Contrôle d'accès basé sur les attributs (ABAC) avec commutateur de région
**Prise en charge d’ABAC (balises dans les politiques) :** Oui
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation d'informations d'identification temporaires avec le changement de région
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Autorisations principales interservices pour le changement de région
**Prend en charge les sessions d’accès direct (FAS) :** oui
Lorsque vous utilisez une entité IAM (utilisateur ou rôle) pour effectuer des actions AWS, vous êtes considéré comme un mandant. Les politiques accordent des autorisations au principal. Lorsque vous utilisez certains services, vous pouvez effectuer une action qui déclenche une autre action dans un autre service. Dans ce cas, vous devez disposer des autorisations nécessaires pour effectuer les deux actions.
## Rôles de service pour le changement de région
**Prend en charge les rôles de service :** Non
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
## Rôles liés au service pour le changement de région
**Prend en charge les rôles liés à un service :** non
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS répertoire et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus d’informations sur la création ou la gestion des rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Choisissez le lien **Oui** pour consulter la documentation du rôle lié à ce service.
# Exemples de politiques basées sur l'identité pour le changement de région dans ARC
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources ARC. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par ARC, y compris le ARNs format de chaque type de ressource, consultez la section [Actions, ressources et clés de condition pour Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53recoverycontrols.html) dans le *Service Authorization Reference*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices-zonal)
+ [Politique de confiance relative aux rôles d'exécution du plan](security_iam_region_switch_trust_policy.md)
+ [Autorisations d'accès complètes](security_iam_region_switch_full_access.md)
+ [Autorisations en lecture seule](security_iam_region_switch_read_only.md)
+ [Autorisations de blocage d'exécution](security_iam_region_switch_execution_blocks.md)
+ [CloudWatch alarmes pour les autorisations relatives à l'état des applications](security_iam_region_switch_cloudwatch.md)
+ [Autorisations relatives aux rapports d'exécution automatique du plan](security_iam_region_switch_reports.md)
+ [Autorisations relatives aux ressources entre comptes](security_iam_region_switch_cross_account.md)
+ [Autorisations complètes des rôles d'exécution du plan](security_iam_region_switch_complete_policy.md)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources ARC dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
# Politique de confiance relative aux rôles d'exécution du plan
Il s'agit de la politique de confiance requise pour le rôle d'exécution du plan, afin que l'ARC puisse exécuter un plan de changement de région.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "arc-region-switch.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
# Autorisations d'accès complètes
La politique IAM suivante accorde un accès complet à tous les changements de région : APIs
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "arc-region-switch.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:CreatePlan",
"arc-region-switch:UpdatePlan",
"arc-region-switch:GetPlan",
"arc-region-switch:ListPlans",
"arc-region-switch:DeletePlan",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:ListPlansInRegion",
"arc-region-switch:ApprovePlanExecutionStep",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:StartPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:ListRoute53HealthChecksInRegion",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListTagsForResource",
"arc-region-switch:TagResource",
"arc-region-switch:UntagResource",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:UpdatePlanExecutionStep"
],
"Resource": "*"
}
]
}
```
------
# Autorisations en lecture seule
La politique IAM suivante accorde des autorisations d'accès en lecture seule pour le changement de région :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlan",
"arc-region-switch:ListPlans",
"arc-region-switch:GetPlanInRegion",
"arc-region-switch:ListPlansInRegion",
"arc-region-switch:GetPlanEvaluationStatus",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListRoute53HealthChecks",
"arc-region-switch:ListRoute53HealthChecksInRegion",
"arc-region-switch:ListPlanExecutions",
"arc-region-switch:ListPlanExecutionEvents",
"arc-region-switch:ListTagsForResource"
],
"Resource": "*"
}
]
}
```
------
# Autorisations de blocage d'exécution
Les sections suivantes fournissent des exemples de politiques IAM qui fournissent les autorisations requises pour des blocs d'exécution spécifiques que vous ajoutez à un plan de changement de région.
**Topics**
+ [Exemple de politique d'exécution par blocs d'EC2 Auto Scaling](security_iam_region_switch_ec2_autoscaling.md)
+ [Exemple de politique d'exécution du dimensionnement des ressources Amazon EKS](security_iam_region_switch_eks.md)
+ [Exemple de politique de mise à l'échelle des blocs d'exécution du service Amazon ECS](security_iam_region_switch_ecs.md)
+ [Exemple de politique de bloc d'exécution des contrôles de routage ARC](security_iam_region_switch_arc_routing.md)
+ [Exemple de politique d'exécution de la base de données globale Aurora](security_iam_region_switch_aurora.md)
+ [Exemple de politique d'exécution par blocs d'Amazon DocumentDB Global Cluster](security_iam_region_switch_documentdb.md)
+ [Exemple de politique relative aux blocs d'exécution Amazon RDS](security_iam_region_switch_rds.md)
+ [Exemple de politique d'exécution des approbations manuelles](security_iam_region_switch_manual_approval.md)
+ [Exemple de politique de bloc d'exécution Lambda pour les actions personnalisées](security_iam_region_switch_lambda.md)
+ [Exemple de politique de bloc d'exécution du bilan de santé Route 53](security_iam_region_switch_route53.md)
+ [Exemple de politique de bloc d'exécution d'un plan de changement de région](security_iam_region_switch_plan_execution.md)
# Exemple de politique d'exécution par blocs d'EC2 Auto Scaling
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les groupes EC2 Auto Scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"autoscaling:UpdateAutoScalingGroup"
],
"Resource": [
"arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:123d456e-123e-1111-abcd-EXAMPLE22222:autoScalingGroupName/app-asg-primary",
"arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:1234a321-123e-1234-aabb-EXAMPLE33333:autoScalingGroupName/app-asg-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
}
]
}
```
------
# Exemple de politique d'exécution du dimensionnement des ressources Amazon EKS
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour le dimensionnement des ressources Amazon EKS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster"
],
"Resource": [
"arn:aws:eks:us-east-1:123456789012:cluster/app-eks-primary",
"arn:aws:eks:us-west-2:123456789012:cluster/app-eks-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"eks:ListAssociatedAccessPolicies"
],
"Resource": [
"arn:aws:eks:us-east-1:123456789012:access-entry/app-eks-primary/*",
"arn:aws:eks:us-west-2:123456789012:access-entry/app-eks-secondary/*"
]
}
]
}
```
------
Remarque : Outre cette politique IAM, le rôle d'exécution du plan doit être ajouté aux entrées d'accès du cluster Amazon EKS avec la politique `AmazonArcRegionSwitchScalingPolicy` d'accès. Pour de plus amples informations, veuillez consulter [Configuration des autorisations d'accès à EKS](eks-resource-scaling-block.md#eks-resource-scaling-block-permissions).
# Exemple de politique de mise à l'échelle des blocs d'exécution du service Amazon ECS
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour le dimensionnement du service Amazon ECS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:DescribeServices",
"ecs:UpdateService"
],
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:service/app-cluster-primary/app-service",
"arn:aws:ecs:us-west-2:123456789012:service/app-cluster-secondary/app-service"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:DescribeClusters"
],
"Resource": [
"arn:aws:ecs:us-east-1:123456789012:cluster/app-cluster-primary",
"arn:aws:ecs:us-west-2:123456789012:cluster/app-cluster-secondary"
]
},
{
"Effect": "Allow",
"Action": [
"ecs:ListServices"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"application-autoscaling:DescribeScalableTargets",
"application-autoscaling:RegisterScalableTarget"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:GetMetricStatistics"
],
"Resource": "*"
}
]
}
```
------
# Exemple de politique de bloc d'exécution des contrôles de routage ARC
Remarque : Le bloc d'exécution des contrôles de routage Amazon ARC exige que toutes les politiques de contrôle des services (SCPs) appliquées au rôle d'exécution du plan autorisent l'accès aux régions suivantes pour ces services :
+ `route53-recovery-control-config: us-west-2`
+ `route53-recovery-cluster: us-west-2, us-east-1, eu-west-1, ap-southeast-2, ap-northeast-1`
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les contrôles de routage ARC.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53-recovery-control-config:DescribeControlPanel",
"route53-recovery-control-config:DescribeCluster"
],
"Resource": [
"arn:aws:route53-recovery-control::123456789012:controlpanel/abcd1234abcd1234abcd1234abcd1234",
"arn:aws:route53-recovery-control::123456789012:cluster/4b325d3b-0e28-4dcf-ba4a-EXAMPLE11111"
]
},
{
"Effect": "Allow",
"Action": [
"route53-recovery-cluster:GetRoutingControlState",
"route53-recovery-cluster:UpdateRoutingControlStates"
],
"Resource": [
"arn:aws:route53-recovery-control::123456789012:controlpanel/1234567890abcdef1234567890abcdef/routingcontrol/abcdef1234567890",
"arn:aws:route53-recovery-control::123456789012:controlpanel/1234567890abcdef1234567890abcdef/routingcontrol/1234567890abcdef"
]
}
]
}
```
------
Vous pouvez récupérer l'ID du panneau de commande de routage et l'ID du cluster à l'aide de la CLI. Pour de plus amples informations, veuillez consulter [Configuration des composants de contrôle de routage](getting-started-cli-routing-config.md).
# Exemple de politique d'exécution de la base de données globale Aurora
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les bases de données Aurora.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeGlobalClusters",
"rds:DescribeDBClusters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:FailoverGlobalCluster",
"rds:SwitchoverGlobalCluster"
],
"Resource": [
"arn:aws:rds::123456789012:global-cluster:app-global-db",
"arn:aws:rds:us-east-1:123456789012:cluster:app-db-primary",
"arn:aws:rds:us-west-2:123456789012:cluster:app-db-secondary"
]
}
]
}
```
------
# Exemple de politique d'exécution par blocs d'Amazon DocumentDB Global Cluster
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les clusters globaux Amazon DocumentDB.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeGlobalClusters",
"rds:DescribeDBClusters",
"rds:FailoverGlobalCluster",
"rds:SwitchoverGlobalCluster"
],
"Resource": "*"
}
]
}
```
# Exemple de politique relative aux blocs d'exécution Amazon RDS
Voici un exemple de politique à joindre si vous ajoutez des blocs d'exécution à un plan de changement de région dans le cadre de la promotion de répliques de lecture Amazon RDS ou de la création de répliques entre régions.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DescribeDBInstances",
"rds:PromoteReadReplica",
"rds:CreateDBInstanceReadReplica",
"rds:ModifyDBInstance"
],
"Resource": "*"
}
]
}
```
# Exemple de politique d'exécution des approbations manuelles
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour des approbations manuelles.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:ApprovePlanExecutionStep"
],
"Resource": "arn:aws:arc-region-switch::123456789012:plan/sample-plan:0123abc"
}
]
}
```
------
# Exemple de politique de bloc d'exécution Lambda pour les actions personnalisées
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les fonctions Lambda.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:us-east-1:123456789012:function:app-recovery-primary",
"arn:aws:lambda:us-west-2:123456789012:function:app-recovery-secondary"
]
}
]
}
```
------
# Exemple de politique de bloc d'exécution du bilan de santé Route 53
Voici un exemple de politique à associer si vous ajoutez des blocs d'exécution à un plan de changement de région pour les bilans de santé de Route 53.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:ListResourceRecordSets"
],
"Resource": [
"arn:aws:route53:::hostedzone/Z1234567890ABCDEFGHIJ"
]
}
]
}
```
------
# Exemple de politique de bloc d'exécution d'un plan de changement de région
Voici un exemple de politique à appliquer si vous ajoutez des blocs d'exécution à un plan de changement de région pour exécuter des plans enfants.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"arc-region-switch:StartPlanExecution",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:CancelPlanExecution",
"arc-region-switch:UpdatePlanExecution",
"arc-region-switch:ListPlanExecutions"
],
"Resource": [
"arn:aws:arc-region-switch::123456789012:plan/child-plan-1/abcde1",
"arn:aws:arc-region-switch::123456789012:plan/child-plan-2/fghij2"
]
}
]
}
```
------
# CloudWatch alarmes pour les autorisations relatives à l'état des applications
Voici un exemple de politique à associer aux CloudWatch alarmes d'accès relatives à l'état de santé des applications, qui sont utilisées pour déterminer le temps de restauration réel.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarmHistory",
"cloudwatch:DescribeAlarms"
],
"Resource": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:app-health-primary",
"arn:aws:cloudwatch:us-west-2:123456789012:alarm:app-health-secondary"
]
}
]
}
```
------
# Autorisations relatives aux rapports d'exécution automatique du plan
Voici un exemple de politique à joindre si vous configurez la génération automatique de rapports pour un plan de changement de région. Cette politique inclut les autorisations permettant de rédiger des rapports sur Amazon S3, CloudWatch d'accéder aux données d'alarme et de récupérer les informations des forfaits enfants pour les forfaits parents.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:DescribeAlarms",
"cloudwatch:DescribeAlarmHistory"
],
"Resource": [
"arn:aws:cloudwatch:us-east-1:123456789012:alarm:app-health-primary"
"arn:aws:cloudwatch:us-west-2:123456789012:alarm:app-health-secondary"
],
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutionEvents"
],
"Resource": [
"arn:aws:arc-region-switch:us-east-1:123456789012:plan/child-plan-1/abcde1",
"arn:aws:arc-region-switch:us-west-2:123456789012:plan/child-plan-2/fghij2"
],
}
]
}
```
Remarque : Si vous configurez une AWS KMS clé gérée par le client pour le chiffrement du compartiment Amazon S3, vous devez également ajouter `kms:GenerateDataKey` des `kms:Encrypt` autorisations pour la clé.
# Autorisations relatives aux ressources entre comptes
Si les ressources se trouvent dans des comptes différents, vous aurez besoin d'un rôle multicompte. Voici un exemple de politique de confiance pour un rôle multicompte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/RegionSwitchExecutionRole"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UniqueExternalId123"
}
}
}
]
}
```
------
Et voici l'autorisation pour le rôle d'exécution du plan d'assumer ce rôle entre comptes :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::987654321098:role/RegionSwitchCrossAccountRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "UniqueExternalId123"
}
}
}
]
}
```
------
# Autorisations complètes des rôles d'exécution du plan
La création d'une politique complète incluant des autorisations pour tous les blocs d'exécution nécessiterait une politique assez large. En pratique, vous ne devez inclure des autorisations que pour les blocs d'exécution que vous utilisez dans vos plans spécifiques.
Voici un exemple de politique que vous pouvez utiliser comme point de départ pour une politique de rôle d'exécution de plan. Assurez-vous d'ajouter des politiques supplémentaires requises pour les blocs d'exécution spécifiques que vous incluez dans votre plan. N'incluez que les autorisations requises pour les blocs d'exécution spécifiques que vous utilisez dans votre plan, conformément au principe du moindre privilège
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:SimulatePrincipalPolicy",
"Resource": "arn:aws:iam::123456789012:role/RegionSwitchExecutionRole"
},
{
"Effect": "Allow",
"Action": [
"arc-region-switch:GetPlan",
"arc-region-switch:GetPlanExecution",
"arc-region-switch:ListPlanExecutions"
],
"Resource": "*"
}
]
}
```
------
# Journalisation et surveillance pour le changement de région dans ARC
Vous pouvez utiliser Amazon CloudWatch et Amazon EventBridge pour surveiller le changement de région dans Amazon Application Recovery Controller (ARC), afin de recevoir des alertes, d'analyser des modèles et de résoudre les problèmes. AWS CloudTrail
**Topics**
+ [Enregistrement des appels d'API de changement de région à l'aide AWS CloudTrail](cloudtrail-region-switch.md)
+ [Utilisation du changement de région dans ARC avec Amazon EventBridge](eventbridge-region-switch.md)
# Enregistrement des appels d'API de changement de région à l'aide AWS CloudTrail
Le commutateur de région Amazon Application Recovery Controller (ARC) est intégré à un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans ARC. AWS CloudTrail CloudTrail capture tous les appels d'API pour ARC sous forme d'événements. Les appels capturés incluent des appels provenant de la console ARC et des appels de code vers les opérations de l'API ARC.
Si vous créez un suivi, vous pouvez activer la diffusion continue d' CloudTrail événements vers un compartiment Amazon S3, y compris des événements pour ARC. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans **Historique des événements**.
À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à ARC, l'adresse IP à partir de laquelle la demande a été faite, qui a fait la demande, quand elle a été faite et des détails supplémentaires.
Pour en savoir plus CloudTrail, consultez le [guide de AWS CloudTrail l'utilisateur](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).
## Informations ARC dans CloudTrail
CloudTrail est activé sur votre compte Compte AWS lorsque vous créez le compte. Lorsqu'une activité se produit dans ARC, cette activité est enregistrée dans un CloudTrail événement avec d'autres événements de AWS service dans **l'historique des événements**. Vous pouvez consulter, rechercher et télécharger les événements récents dans votre Compte AWS. Pour plus d'informations, consultez la section [Utilisation de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Pour un enregistrement continu des événements de votre région Compte AWS, y compris ceux de l'ARC, créez un parcours. Un *suivi* permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal d’activité dans la console, il s’applique à toutes les régions Régions AWS. Le journal enregistre les événements de toutes les régions de la AWS partition et transmet les fichiers journaux au compartiment Amazon S3 que vous spécifiez. En outre, vous pouvez configurer d'autres AWS services pour analyser plus en détail les données d'événements collectées dans les CloudTrail journaux et agir en conséquence. Pour plus d’informations, consultez les ressources suivantes :
+ [Présentation de la création d’un journal de suivi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail services et intégrations pris en charge](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html)
+ [Configuration des notifications Amazon SNS pour CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Réception de fichiers CloudTrail journaux de plusieurs régions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) et [réception de fichiers CloudTrail journaux de plusieurs comptes](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Toutes les actions ARC sont enregistrées CloudTrail et documentées dans le lien de référence de l'API TBD. Par exemple, les appels au `TBD` `TBD` et les `TBD` actions génèrent des entrées dans les fichiers CloudTrail journaux.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer les éléments suivants :
+ Si la demande a été faite avec les informations d'identification de l'utilisateur root ou Gestion des identités et des accès AWS (IAM).
+ Si la demande a été effectuée avec les informations d’identification de sécurité temporaires d’un rôle ou d’un utilisateur fédéré.
+ Si la demande a été faite par un autre AWS service.
Pour de plus amples informations, veuillez consulter l'[élément userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Affichage des événements liés au changement de région dans l'historique des événements
CloudTrail vous permet de consulter les événements récents dans **l'historique des événements**. La plupart des événements liés aux demandes d'API de changement de région se produisent dans la région dans laquelle vous travaillez avec un plan de changement de région, par exemple, lorsque vous créez un plan ou que vous exécutez un plan. Toutefois, certaines actions de changement de région que vous exécutez dans la console ARC sont effectuées à l'aide des opérations de l'API du plan de contrôle, plutôt que des opérations du plan de données. Pour les opérations du plan de contrôle, vous pouvez consulter les événements dans l'est des États-Unis (Virginie du Nord). Pour savoir quels appels d'API sont des opérations du plan de contrôle, consultez[Opérations de l'API de changement de région](actions.region-switch.md).
## Comprendre les entrées du fichier journal ARC
Un suivi est une configuration qui permet de transmettre des événements sous forme de fichiers journaux à un compartiment Amazon S3 que vous spécifiez. CloudTrail les fichiers journaux contiennent une ou plusieurs entrées de journal. Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'action demandée, la date et l'heure de l'action, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics, ils n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant montre une entrée de CloudTrail journal qui illustre l'`StartPlanExecution`action du changement de région.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/admin",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA33L3W36EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/admin",
"accountId": "111122223333",
"userName": "EXAMPLENAME"
},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2025-07-06T17:38:05Z"
}
}
},
"eventTime": "2025-07-06T18:08:03Z",
"eventSource": "arc-region-switch.amazonaws.com",
"eventName": "StartPlanExecution",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.50",
"userAgent": "Boto3/1.17.101 Python/3.8.10 Linux/4.14.231-180.360.amzn2.x86_64 exec-env/AWS_Lambda_python3.8 Botocore/1.20.102",
"requestParameters": {
"planArn": "arn:aws:arc-region-switch::555555555555:plan/CloudTrailIntegTestPlan:bbbbb",
"targetRegion": "us-east-1",
"action": "activate" }
"responseElements": {
"executionId": "us-east-1/dddddddEXAMPLE",
"plan": "arn:aws:arc-region-switch::555555555555:plan/CloudTrailIntegTestPlan:bbbbb",
"planVersion": "1",
"activateRegion": "us-east-1" },
"requestID": "fd42dcf7-6446-41e9-b408-d096example",
"eventID": "4b5c42df-1174-46c8-be99-d67aexample",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "us-east-1.arc.amazon.aws"
}
```
# Utilisation du changement de région dans ARC avec Amazon EventBridge
À l'aide d'Amazon EventBridge, vous pouvez configurer des règles basées sur les événements qui surveillent les ressources de votre changement de région dans Amazon Application Recovery Controller (ARC), puis lancer des actions cibles utilisant d'autres AWS services. Par exemple, vous pouvez définir une règle pour l'envoi de notifications par e-mail en signalant un sujet Amazon SNS chaque fois qu'un plan de changement de région est terminé.
Vous pouvez créer des règles dans Amazon EventBridge pour agir sur les événements de changement de région ARC suivants :
+ *Exécution du plan de changement de région.* L'événement indique qu'un plan de changement de région a été exécuté (exécuté).
+ *Évaluation du plan de changement de région.* L'événement indique qu'une évaluation du plan de changement de région est terminée.
Pour capturer des événements ARC spécifiques qui vous intéressent, définissez des modèles spécifiques à l'événement qui EventBridge peuvent être utilisés pour détecter les événements. Les modèles d'événements ont la même structure que les événements auxquels ils correspondent. Le modèle place entre guillemets les champs que vous voulez faire correspondre et fournit les valeurs que vous recherchez.
Les événements sont générés dans la mesure du possible. Ils sont transmis d'ARC EventBridge en temps quasi réel dans des circonstances opérationnelles normales. Cependant, des situations peuvent survenir susceptibles de retarder ou d'empêcher la livraison d'un événement.
Pour plus d'informations sur le fonctionnement EventBridge des règles avec les modèles d'événements, consultez la section [Événements et modèles d'événements dans EventBridge](https://docs.aws.amazon.com//eventbridge/latest/userguide/eventbridge-and-event-patterns.html).
## Surveillez une ressource de changement de région avec EventBridge
Avec EventBridge, vous pouvez créer des règles qui définissent les actions à entreprendre lorsque l'ARC émet des événements pour les ressources de changement de région.
Pour taper ou copier-coller un modèle d'événement dans la EventBridge console, dans la console, sélectionnez l'option **Enter my own** option. Pour vous aider à déterminer les modèles d'événements susceptibles de vous être utiles, cette rubrique inclut des [exemples de modèles de changement de région](#arc-eventbridge-examples-region-switch).
**Pour créer une règle pour un événement de ressource**
1. Ouvrez la EventBridge console Amazon à l'adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Région AWS Pour créer la règle, choisissez la région dans laquelle vous avez créé le plan pour lequel vous souhaitez surveiller les événements.
1. Choisissez **Create rule**.
1. Entrez un **nom** et éventuellement une description pour la règle.
1. Pour **Event bus**, laissez la valeur par défaut, **default**.
1. Choisissez **Suivant**.
1. Pour l'étape **Créer un modèle d'événement**, pour **Source d'événement**, laissez la valeur par défaut, **AWS events**.
1. Sous **Exemple d'événement**, choisissez **Enter my own**.
1. Pour **Exemples d'événements**, tapez ou copiez-collez un modèle d'événement. Pour des exemples, reportez-vous à la section suivante.
## Exemples de modèles de changement de région
Les modèles d'événements ont la même structure que les événements auxquels ils correspondent. Le modèle place entre guillemets les champs que vous voulez faire correspondre et fournit les valeurs que vous recherchez.
Vous pouvez copier et coller des modèles d'événements depuis cette section EventBridge pour créer des règles que vous pouvez utiliser pour surveiller les actions et les ressources de l'ARC.
Les modèles d'événements suivants fournissent des exemples que vous pouvez utiliser EventBridge pour la fonctionnalité de changement de région dans ARC.
+ *Sélectionnez tous les événements dans Region Switch for PlanExecution*.
```
{
"source": [ "aws.arc-region-switch" ],
"detail-type": [ "ARC Region switch Plan Execution" ]
}
```
+ *Sélectionnez tous les événements dans Region Switch for PlanEvaluation*.
```
{
"source": [ "aws.arc-region-switch" ],
"detail-type": [ "ARC Region Switch Plan Evaluation" ]
}
```
Voici un exemple d'événement ARC pour l'*exécution d'un plan de changement de région* :
```
{
"version": "0",
"id": "1111111-bbbb-aaaa-cccc-dddddEXAMPLE", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/aaaaaExample"], # planArn
"detail": {
"version": "0.0.1",
"eventType": "ExecutionStarted",
"executionId": "bbbbbbEXAMPLE",
"executionAction": "activating/deactivating {region}",
"idempotencyKey": "1111111-2222-3333-4444-5555555555", # As there is a possibility of dual logging
}
}
```
Voici un exemple d'événement ARC pour l'*exécution par étapes d'un plan de changement de région* :
```
{
"version": "0",
"id": "1111111-bbbb-aaaa-cccc-dddddEXAMPLE", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/aaaaaExample"], # planArn
"detail": {
"version": "0.0.1",
"eventType": "StepStarted",
"executionId": "bbbbbbEXAMPLE",
"executionAction": "activating/deactivating {region}",
"idempotencyKey": "1111111-2222-3333-4444-5555555555", # As there is a possibility of dual logging
"stepDetails" : {
"stepName": "Routing control step",
"resource": ["arn:aws:route53-recovery-control::111122223333:controlpanel/abcdefghiEXAMPLE/routingcontrol/jklmnopqrsEXAMPLE"]
}
}
}
```
Voici un exemple d'événement ARC pour un *avertissement d'évaluation d'un plan de changement de région*.
Pour l'évaluation d'un plan de changement de région, un événement est émis lorsqu'un avertissement est renvoyé. Si l'avertissement n'est pas effacé, un événement n'est émis pour l'avertissement qu'une fois toutes les 24 heures. Lorsque l'événement est effacé, aucun autre événement n'est émis pour cet avertissement.
```
{
"version": "0",
"id": "05d4d2d5-9c76-bfea-72d2-d4614802adb4", # Random uuid
"detail-type": "ARC Region Switch Plan Execution",
"source": "aws.arc-region-switch",
"account": "111122223333",
"time": "2023-11-16T23:38:14Z",
"region": "us-east-1",
"resources": ["arn:aws:arc-region-switch::111122223333:plan/a2b89be4821bfd1d"],
"detail": {
"version": "0.0.1",
"idempotencyKey": "1111111-2222-3333-4444-5555555555",
"metadata": {
"evaluationTime" : "timestamp",
"warning" : "There is a plan evaluation warning for arn:aws:arc-region-switch::111122223333:plan/a2b89be4821bfd1d. Navigate to the Region switch console to resolve."
}
}
}
```
## Spécifiez un groupe de CloudWatch journaux à utiliser comme cible
Lorsque vous créez une EventBridge règle, vous devez spécifier la cible vers laquelle les événements correspondant à la règle sont envoyés. Pour obtenir la liste des cibles disponibles pour EventBridge, consultez la section [Cibles disponibles dans la EventBridge console](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html#eb-console-targets). L'une des cibles que vous pouvez ajouter à une EventBridge règle est un groupe de CloudWatch journaux Amazon. Cette section décrit les exigences relatives à l'ajout de groupes de CloudWatch journaux en tant que cibles et fournit une procédure pour ajouter un groupe de journaux lorsque vous créez une règle.
Pour ajouter un groupe de CloudWatch journaux en tant que cible, vous pouvez effectuer l'une des opérations suivantes :
+ Création d'un nouveau groupe de journaux
+ Choisissez un groupe de journaux existant
Si vous spécifiez un nouveau groupe de journaux à l'aide de la console lorsque vous créez une règle, le groupe de journaux est EventBridge automatiquement créé pour vous. Assurez-vous que le groupe de journaux que vous utilisez comme cible pour la EventBridge règle commence par`/aws/events`. Si vous souhaitez choisir un groupe de journaux existant, sachez que seuls les groupes de journaux commençant par `/aws/events` apparaissent sous forme d'options dans le menu déroulant. Pour plus d'informations, consultez la section [Créer un nouveau groupe de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group) dans le *guide de CloudWatch l'utilisateur Amazon*.
Si vous créez ou utilisez un groupe de CloudWatch journaux à utiliser comme cible à l'aide d' CloudWatch opérations en dehors de la console, assurez-vous de définir correctement les autorisations. Si vous utilisez la console pour ajouter un groupe de journaux à une EventBridge règle, la politique basée sur les ressources pour le groupe de journaux est automatiquement mise à jour. Toutefois, si vous utilisez le AWS Command Line Interface ou un AWS SDK pour spécifier un groupe de journaux, vous devez mettre à jour la politique basée sur les ressources pour le groupe de journaux. L'exemple de politique suivant illustre les autorisations que vous devez définir dans une stratégie basée sur les ressources pour le groupe de journaux :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"delivery.logs.amazonaws.com"
]
},
"Resource": "arn:aws:logs:us-east-1:222222222222:log-group:/aws/events/*:*",
"Sid": "TrustEventsToStoreLogEvent"
}
]
}
```
------
Vous ne pouvez pas configurer une politique basée sur les ressources pour un groupe de journaux à l'aide de la console. Pour ajouter les autorisations requises à une politique basée sur les ressources, utilisez l'opération CloudWatch [PutResourcePolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutResourcePolicy.html)API. Vous pouvez ensuite utiliser la commande [describe-resource-policies](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/describe-resource-policies.html)CLI pour vérifier que votre politique a été correctement appliquée.
**Pour créer une règle pour un événement de ressource et spécifier une cible de groupe de CloudWatch journaux**
1. Ouvrez la EventBridge console Amazon à l'adresse [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Choisissez Région AWS celui dans lequel vous souhaitez créer la règle.
1. Choisissez **Créer une règle**, puis entrez les informations relatives à cette règle, telles que le modèle d'événement ou les détails du calendrier.
Pour plus d'informations sur la création de EventBridge règles de préparation, voir [Surveiller une ressource de vérification de l'état de préparation avec EventBridge](eventbridge-readiness.md#RCEventBridgeCreateRule).
1. Sur la page **Sélectionner une cible**, choisissez **CloudWatch**comme cible.
1. Choisissez un groupe de CloudWatch journaux dans le menu déroulant.
# Quotas pour le changement de région
Le changement de région dans Amazon Application Recovery Controller (ARC) est soumis aux quotas suivants.
| Entité | Quota |
| --- | --- |
| Nombre de plans par compte | 10 Vous pouvez [demander une augmentation de quota](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/arc-region-switch/quotas). |
| Nombre de blocs d'exécution par plan | 100 |
| Nombre de blocs d'exécution du plan de changement de région par plan | 25 |
| Nombre de blocs d'exécution en parallèle par étape | 20 |
| Nombre d' CloudWatch alarmes par condition de déclenchement | 10 |