# REL 13 Comment planifier la reprise après sinistre (DR) ?
La mise en place de sauvegardes et de composants de charge de travail redondants constitue le début de votre stratégie de DR. [RTO et RPO sont vos objectifs](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) pour la restauration de votre charge de travail. Définissez-les en fonction des besoins de l'entreprise. Mettez en œuvre une stratégie pour atteindre ces objectifs, en particulier en tenant compte de l'emplacement et de la fonction des données et des ressources de charge de travail. La probabilité d'une perturbation et le coût de la reprise sont également des facteurs clés qui permettent de déterminer la valeur opérationnelle de la reprise après sinistre d'une charge de travail.
**Topics**
+ [REL13-BP01 Définir les objectifs de reprise pour les temps d'arrêt et les pertes de données](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 Gérer l'écart de configuration au niveau du site ou de la région de reprise après sinistre](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 Automatiser la reprise](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 Définir les objectifs de reprise pour les temps d'arrêt et les pertes de données
La charge de travail est associée à un objectif de délai de reprise (RTO) et à un objectif de point de reprise (RPO).
*La durée maximale d'interruption admissible (RTO)* correspond au délai maximum acceptable entre l'interruption du service et la restauration du service. Elle détermine ce qui est considéré comme étant un créneau de temps acceptable d'indisponibilité du service.
*L'objectif de point de reprise (RPO)* correspond au temps maximal acceptable depuis le dernier point de reprise des données. Il détermine ce qui est considéré comme étant une perte de données acceptable entre le dernier point de reprise et l'interruption du service.
Les valeurs RTO et RPO sont des considérations importantes lors de la sélection d'une stratégie de reprise après sinistre adaptée à votre charge de travail. Ces objectifs sont déterminés par l'entreprise, puis utilisés par les équipes techniques pour sélectionner et mettre en œuvre une stratégie de reprise après sinistre.
**Résultat souhaité :**
Un RTO et un RPO, définis en fonction de l'impact sur l'entreprise, sont attribués à chaque charge de travail. Un niveau prédéfini, définissant la disponibilité du service et une perte de données acceptable, avec un RTO et un RPO associés est assigné à la charge de travail. Si cette hiérarchisation n'est pas possible, elle peut être attribuée sur mesure pour chaque charge de travail, dans l'intention de créer des niveaux ultérieurement. Le RTO et le RPO font partie des principaux éléments pris en compte pour la sélection de la mise en œuvre d'une stratégie de reprise après sinistre pour la charge de travail. D'autres considérations dans le choix d'une stratégie de reprise après sinistre sont les contraintes de coût, les dépendances de la charge de travail et les exigences opérationnelles.
Pour le RTO, identifiez l'impact en fonction de la durée d'une panne. Est-il linéaire ou non (par exemple, après quatre heures, vous arrêtez une ligne de fabrication jusqu'au début du prochain quart de travail) ?
Une matrice de reprise après sinistre, comme la suivante, peut vous aider à comprendre dans quelle mesure l'ordre d'importance de la charge de travail est lié aux objectifs de reprise. Notez que les valeurs réelles des axes X et Y doivent être personnalisées en fonction des besoins de votre organisation.
![\[Graphique illustrant la matrice de reprise après sinistre\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**Anti-modèles courants :**
+ Aucun objectif de reprise défini.
+ Sélection d'objectifs arbitraires de reprise.
+ Sélection d'objectifs de reprise trop lents et qui ne répondent pas aux objectifs de l'entreprise.
+ Ne pas comprendre l'impact des temps d'arrêt et de la perte de données.
+ Sélection d'objectifs de reprise irréalistes, tels que zéro temps de reprise et zéro perte de données, qui peuvent ne pas être réalisables pour la configuration de votre charge de travail.
+ Sélection d'objectifs de reprise plus rigoureux que les objectifs commerciaux réels. Cela impose des implémentations de reprise après sinistre qui sont plus coûteuses et plus compliquées que ce dont a besoin la charge de travail.
+ Sélection d'objectifs de reprise incompatibles avec ceux d'une charge de travail dépendante.
+ Vos objectifs de reprise ne tiennent pas compte des exigences de conformité réglementaire.
+ Définition de RTO et RPO jamais testés pour une charge de travail.
**Avantages liés au respect de cette bonne pratique :** Vos objectifs de reprise en cas de perte de temps et de données sont nécessaires pour guider votre implémentation de DR.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
Pour la charge de travail donnée, vous devez comprendre l'impact des temps d'arrêt et de la perte de données sur votre entreprise. L'impact augmente généralement avec les temps d'arrêt ou les pertes de données plus importants, mais son ampleur peut varier en fonction du type de charge de travail. Par exemple, vous pouvez tolérer des temps d'arrêt pouvant atteindre une heure avec peu d'impact, mais au-delà de ce délai, l'impact augmente rapidement. L'impact sur l'entreprise se manifeste sous de nombreuses formes, notamment le coût (tel que la perte de revenus), la confiance des clients (et l'impact sur la réputation), les problèmes opérationnels (tels que l'absence d'employés ou la baisse de productivité) et le risque réglementaire. Utilisez les étapes suivantes pour comprendre ces impacts et définir le RTO et le RPO pour votre charge de travail.
**Étapes d'implémentation**
1. Identifiez les parties prenantes spécifiques à cette charge de travail et collaborez avec elles pour mettre en œuvre ces étapes. Les objectifs de reprise d'une charge de travail relèvent d'une décision de l'entreprise. Les équipes techniques travaillent ensuite avec les parties prenantes de l'entreprise pour utiliser ces objectifs afin de sélectionner une stratégie de reprise après sinistre.
**Note**
Pour les étapes 2 et 3, vous pouvez utiliser [Fiche d'implémentation](#implementation-worksheet).
1. Répondez aux questions ci-dessous pour rassembler les informations nécessaires pour prendre une décision.
1. Utilisez-vous des catégories ou des niveaux de criticité pour déterminer l'impact de la charge de travail dans votre organisation ?
1. Si oui, affectez cette charge de travail à une catégorie.
1. Dans le cas contraire, définissez ces catégories. Créez cinq catégories ou moins et affinez la plage de vos objectifs de délai et de point de reprise. Exemples de catégories : critique, élevé, moyen, faible. Pour comprendre comment les charges de travail correspondent aux catégories, déterminez si la charge de travail est stratégique, importante pour l'entreprise ou non commerciale.
1. Définissez le RTO et le RPO de la charge de travail en fonction de sa catégorie. Choisissez toujours une catégorie plus stricte (RTO et RPO inférieurs) que les valeurs brutes calculées au début de cette étape. Si cela entraîne une variation de valeur trop importante, envisagez de créer une autre catégorie.
1. En fonction de ces réponses, attribuez des valeurs de RTO et RPO à la charge de travail. Cela peut se faire directement ou en affectant la charge de travail à un niveau de service prédéfini.
1. Documentez le plan de reprise après sinistre (DRP) pour cette charge de travail, qui fait partie du [plan de continuité d'activité (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), à un emplacement accessible à l'équipe responsable de la charge de travail et aux parties prenantes.
1. Enregistrez le RTO et le RPO, ainsi que les informations utilisées pour déterminer ces valeurs. Spécifiez la stratégie utilisée pour évaluer l'impact de la charge de travail sur l'entreprise.
1. Enregistrez d'autres métriques que le RTO et le RPO que vous suivez ou prévoyez de suivre pour les objectifs de reprise après sinistre.
1. Vous ajouterez les détails de votre stratégie de reprise après sinistre et de votre runbook à ce plan lorsque vous les créerez.
1. En recherchant la criticité de la charge de travail dans une matrice telle que celle de la figure 15, vous pouvez commencer à établir des niveaux de service prédéfinis pour votre organisation.
1. Après avoir mis en œuvre une stratégie de reprise après sinistre (ou une preuve de concept pour une stratégie de reprise après sinistre) conformément à [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](rel_planning_for_recovery_disaster_recovery.md), testez cette stratégie pour déterminer les valeurs RTC (temps de reprise possible) et RPC (point de reprise possible) réelles de la charge de travail. Si ceux-ci n'atteignent pas les objectifs de reprise cibles, vous pouvez soit collaborer avec les parties prenantes de votre entreprise pour les ajuster, soit apporter des modifications à la stratégie de reprise après sinistre, le cas échéant, pour atteindre ces objectifs.
**Questions principales**
1. Quelle est la durée maximale pendant laquelle la charge de travail peut être interrompue avant qu'un impact grave n'affecte l'entreprise ?
1. Déterminez le coût (impact financier direct) pour l'entreprise par minute où la charge de travail est interrompue.
1. Considérez que l'impact n'est pas toujours linéaire. L'impact peut être limité au début, puis augmenter rapidement au-delà d'un point critique dans le temps.
1. Quelle est la quantité maximale de données pouvant être perdues avant qu'un impact grave n'affecte l'entreprise ?
1. Déterminez cette valeur en fonction de votre magasin de données le plus critique. Identifiez la criticité respective pour les autres magasins de données.
1. Les données de la charge de travail peuvent-elles être recréées en cas de perte ? Si cette approche est plus facile sur le plan opérationnel que la sauvegarde et la restauration, choisissez le RPO en fonction de la criticité des données sources utilisées pour recréer les données de la charge de travail.
1. Quels sont les objectifs de reprise et les attentes de disponibilité des charges de travail dont celle-ci dépend (en aval) ou des charges de travail qui dépendent de celle-ci (en amont) ?
1. Choisissez des objectifs de reprise qui permettent à cette charge de travail de répondre aux exigences des dépendances en amont.
1. Choisissez des objectifs de reprise réalisables compte tenu des capacités de reprise des dépendances en aval. Les dépendances en aval non critiques (celles que vous pouvez « contourner ») peuvent être exclues. Ou, si nécessaire, traitez les dépendances critiques en aval pour améliorer leurs capacités de reprise.
**Questions supplémentaires**
Envisagez ces questions et dans quelle mesure elles s'appliquent à cette charge de travail :
1. Avez-vous des RTO et des RPO différents selon le type de panne (région ou AZ, etc.) ?
1. Existe-t-il un moment précis (saisonnalité, événements commerciaux, lancements de produits) où votre RTO/RPO peut changer ? Si oui, en quoi diffèrent-ils et quelle est leur limite de temps ?
1. Combien de clients seront touchés si la charge de travail est interrompue ?
1. Quel sera l'impact sur la réputation si la charge de travail est interrompue ?
1. Quels autres impacts opérationnels peuvent entrer en jeu si la charge de travail est interrompue ? Par exemple, la productivité des employés sera affectée si les systèmes de messagerie ne sont pas disponibles ou si les systèmes de paie ne sont pas en mesure de soumettre des transactions.
1. Comment le RTO et le RPO de la charge de travail s'alignent-ils sur la stratégie de reprise après sinistre de la succursale et de l'organisation ?
1. Existe-t-il des obligations contractuelles internes régissant la prestation d'un service ? Des sanctions sont-elles appliquées en cas de non-respect ?
1. Quelles sont les contraintes réglementaires ou de conformité liées aux données ?
## Fiche d'implémentation
Vous pouvez utiliser cette feuille de calcul pour les étapes d'implémentation 2 et 3. Vous pouvez l'ajuster en fonction de vos besoins spécifiques, par exemple en ajoutant des questions supplémentaires.
![\[Fiche\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/worksheet.png)
**Niveau d'effort du plan d'implémentation : **Faible
## Ressources
**Bonnes pratiques associées :**
+ [REL09-BP04 Effectuer une récupération périodique des données pour vérifier l'intégrité et les processus de sauvegarde](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](rel_planning_for_recovery_dr_tested.md)
**Documents connexes :**
+ [Blog d'architecture AWS : série sur la reprise après sinistre](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Gestion des politiques de résilience avec AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise
Définissez une stratégie de reprise après sinistre qui répond aux objectifs de reprise de votre charge de travail. Choisissez une stratégie telle que : sauvegarde et restauration, mode secours (actif/passif) ou actif/actif.
Une stratégie de reprise après sinistre repose sur la capacité à rétablir votre charge de travail sur un site de reprise si votre emplacement principal ne parvient plus à exécuter cette charge de travail. Les objectifs de récupération les plus courants sont le RTO et le RPO, comme indiqué dans [REL13-BP01 Définir les objectifs de reprise pour les temps d'arrêt et les pertes de données](rel_planning_for_recovery_objective_defined_recovery.md).
Une stratégie de reprise après sinistre sur plusieurs zones de disponibilité (AZ) au sein d'une seule Région AWS peut vous prémunir contre les événements catastrophiques tels que les incendies, les inondations et les pannes de courant majeures. S'il est nécessaire de mettre en œuvre une protection contre un événement improbable qui empêcherait votre charge de travail de s'exécuter dans une Région AWS donnée, optez pour une stratégie de reprise après sinistre qui utilise plusieurs régions.
Lors de la conception d'une stratégie de reprise après sinistre dans plusieurs régions, vous devez choisir l'une des approches suivantes. Elles sont répertoriées par ordre croissant de coûts et de complexité et par ordre décroissant de RTO et RPO. *La région de reprise* fait référence à une Région AWS autre que la région principale utilisée pour votre charge de travail.
![\[Diagramme illustrant les stratégies de reprise après sinistre\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **Sauvegarde et restauration** (RPO de quelques heures, RTO de 24 heures maximum) : sauvegardez vos données et applications dans la région de reprise. L'utilisation de sauvegardes automatisées ou continues permet une récupération ponctuelle, ce qui peut réduire le RPO à seulement 5 minutes dans certains cas. En cas de sinistre, vous déployez votre infrastructure (en utilisant l'infrastructure en tant que code pour réduire le RTO), déployez votre code et restaurez les données sauvegardées pour vous remettre d'un sinistre dans la région de reprise.
+ **Environnement en veille** (RPO de quelques minutes, RTO de dizaines de minutes) : allouez une copie de votre infrastructure de charge de travail principale dans la région de reprise. Répliquez vos données dans la région de reprise et créez-y des sauvegardes. Les ressources requises pour prendre en charge la réplication et la sauvegarde des données, telles que les bases de données et le stockage d'objets, sont toujours actives. D'autres éléments tels que les serveurs d'applications ou le calcul sans serveur ne sont pas déployés, mais peuvent être créés si nécessaire avec la configuration et le code d'application requis.
+ **Secours à chaud** (RPO de quelques secondes, RTO de quelques minutes) : maintenez une version réduite d'une charge de travail entièrement fonctionnelle qui s'exécute toujours dans la région de reprise. Les systèmes stratégiques sont entièrement dupliqués et sont toujours opérationnels, mais avec une flotte réduite. Les données sont répliquées dans la région de reprise et y sont hébergées. Lorsque vient le moment de la reprise, le système est rapidement mis à l'échelle pour gérer la charge de production. Plus l'échelle du secours à chaud est élevée, plus la dépendance au RTO et au plan de contrôle est faible. Lorsqu'il est entièrement mis à l'échelle, on parle de **zone hébergée**.
+ **Multirégion (multisite) actif/actif** (RPO proche de zéro, RTO potentiellement nul) : votre charge de travail est déployée et dessert activement le trafic à partir de plusieurs Régions AWS. Cette stratégie vous oblige à synchroniser les données entre les régions. Il est important d'éviter ou de gérer les éventuels conflits causés par des écritures sur le même enregistrement dans deux réplicas régionaux différents, ce qui peut être complexe. La réplication des données est utile pour la synchronisation des données et vous protège contre certains types de sinistres. Toutefois, elle ne vous protège pas contre la corruption ou la destruction des données à moins que votre solution n'inclue également des options de récupération ponctuelle.
**Note**
La différence entre l'environnement en veille et le secours à chaud est parfois difficile à cerner. Ces deux stratégies incluent un environnement dans votre région de reprise avec des copies des ressources de votre région principale. L'environnement en veille diffère en ce qu'il ne peut pas traiter les demandes sans qu'une action supplémentaire soit entreprise au préalable, tandis que le secours à chaud peut gérer le trafic (à des niveaux de capacité réduits) immédiatement. L'environnement en veille vous oblige à allumer des serveurs, à déployer éventuellement une infrastructure supplémentaire (non essentielle) et à augmenter l'échelle, tandis que le secours à chaud nécessite uniquement une augmentation de l'échelle (tout est déjà déployé et en cours d'exécution). Choisissez entre ces options en fonction de vos besoins en termes de RTO et de RPO.
**Résultat souhaité :**
Pour chaque charge de travail, il existe une stratégie de reprise après sinistre définie et implémentée qui permet à cette charge de travail d'atteindre les objectifs de reprise. Les stratégies de reprise après sinistre entre les charges de travail utilisent des modèles réutilisables (comme les stratégies décrites précédemment).
**Anti-modèles courants :**
+ Mettre en œuvre des procédures de récupération incohérentes pour les charges de travail avec des objectifs de reprise après sinistre similaires.
+ Conserver l'implémentation ad hoc de la stratégie de reprise après sinistre lorsqu'un sinistre se produit.
+ Ne pas avoir de plan de reprise après sinistre.
+ Être dépendant des opérations du plan de contrôle pendant la récupération.
**Avantages liés au respect de cette bonne pratique :**
+ L'utilisation de stratégies de reprise définies vous permet d'utiliser des outils et des procédures de test courantes.
+ L'utilisation de stratégies de récupération définies permet un partage plus efficace des connaissances entre les équipes et une mise en œuvre plus facile de la reprise après sinistre sur les charges de travail qu'elles possèdent.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
+ Sans une stratégie de reprise après sinistre planifiée, mise en œuvre et testée, il est peu probable que vous atteigniez vos objectifs de reprise en cas de sinistre.
## Directives d'implémentation
Pour chacune de ces étapes, consultez les détails ci-dessous.
1. Déterminez une stratégie de reprise après sinistre qui répond aux exigences de récupération pour cette charge de travail.
1. Passez en revue les modèles de mise en œuvre de la stratégie de reprise après sinistre sélectionnée.
1. Évaluez les ressources de votre charge de travail et déterminez quelle sera leur configuration dans la région de reprise avant le basculement (pendant le fonctionnement normal).
1. Déterminez et mettez en œuvre la manière dont vous préparerez votre région de reprise pour le basculement en cas de besoin (lors d'un sinistre).
1. Déterminez et mettez en œuvre la manière dont vous redirigerez le trafic vers le basculement en cas de besoin (lors d'un sinistre).
1. Élaborez un plan pour déterminer la façon dont votre charge de travail se rétablira.
**Étapes d'implémentation**
1. **Déterminez une stratégie de reprise après sinistre qui répond aux exigences de récupération pour cette charge de travail.**
Le choix d'une stratégie de reprise après sinistre vise à trouver un juste milieu entre la réduction des temps d'arrêt et de la perte de données (RTO et RPO) et le coût et la complexité liées à la mise en œuvre de cette stratégie. Évitez de mettre en œuvre une stratégie plus stricte que nécessaire, car cela entraînerait des coûts inutiles.
Par exemple, dans le diagramme suivant, l'entreprise a déterminé son RTO maximal autorisé ainsi que la limite de dépenses possible pour sa stratégie de restauration de service. Compte tenu des objectifs de l'entreprise, les stratégies Environnement en veille et Secours à chaud satisfont à la fois aux critères de RTO et de coût.
![\[Graphique illustrant le choix d'une stratégie de reprise après sinistre basée sur le RTO et le coût\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
Pour en savoir plus, reportez-vous au [plan de continuité d'activité (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **Passez en revue les modèles de mise en œuvre de la stratégie de reprise après sinistre sélectionnée.**
Cette étape consiste à comprendre comment mettre en œuvre la stratégie sélectionnée. Les stratégies reposent sur l'utilisation de Régions AWS comme site principal et site de reprise. Cependant, vous pouvez également choisir d'utiliser des zones de disponibilité dans une seule région comme stratégie de reprise après sinistre, ce qui permet d'exploiter des éléments de plusieurs de ces stratégies.
Dans les étapes qui suivent celle-ci, vous appliquerez la stratégie à votre charge de travail spécifique.
**Sauvegarde et restauration**
*Sauvegarde et restauration* est la stratégie la moins complexe à mettre en œuvre, mais nécessite plus de temps et d'efforts pour la restauration de la charge de travail, ce qui entraîne un RTO et un RPO plus élevés. Il est conseillé de toujours faire des sauvegardes de vos données et de les copier sur un autre site (comme une autre Région AWS).
![\[Diagramme illustrant une architecture de sauvegarde et de restauration\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
Pour plus de détails sur cette stratégie, consultez [Architecture de reprise après sinistre (DR) sur AWS, partie 2 : sauvegarde et restauration avec récupération rapide](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**Environnement en veille**
Avec *l'environnement* en veille, vous répliquez vos données depuis la région principale vers la région de reprise. Les ressources principales utilisées pour l'infrastructure de charge de travail sont déployées dans la région de reprise, mais des ressources supplémentaires et toutes les dépendances sont toujours nécessaires pour en faire une pile fonctionnelle. Par exemple, dans la figure 20, aucune instance de calcul n'est déployée.
![\[Diagramme illustrant une architecture avec environnement en veille\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
Pour plus de détails sur cette stratégie, consultez [Architecture de reprise après sinistre sur AWS, partie 3 : environnement en veille et secours à chaud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Secours à chaud**
La *secours à chaud* consiste à s'assurer qu'il existe une copie réduite, mais entièrement fonctionnelle, de votre environnement de production dans une autre région. Cette approche étend le concept d'environnement en veille et réduit le temps de récupération, car votre charge de travail reste active dans une autre région. Si la région de reprise est déployée à pleine capacité, on parle de *zone hébergée*.
![\[Schéma illustrant la figure 21 : Architecture de secours à chaud\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
L'utilisation du secours à chaud ou de l'environnement en veille nécessite une augmentation des ressources dans la région de reprise. Pour vous assurer que la capacité est disponible en cas de besoin, envisagez l'utilisation de [réservations de capacité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) pour les instances EC2. Si vous utilisez AWS Lambda, [la simultanéité allouée](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) peut initialiser des environnements d'exécution afin qu'ils soient prêts à répondre immédiatement aux appels de votre fonction.
Pour plus de détails sur cette stratégie, consultez [Architecture de reprise après sinistre sur AWS, partie 3 : environnement en veille et secours à chaud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**Multisite actif/actif**
Vous pouvez exécuter votre charge de travail simultanément dans plusieurs régions dans le cadre d'une stratégie *multisite* actif/actif. Une stratégie multisite actif/actif dessert le trafic de toutes les régions dans lesquelles il est déployé. Les clients peuvent sélectionner cette stratégie pour des raisons autres que la reprise après sinistre. Elle peut être utilisée pour augmenter la disponibilité ou lors du déploiement d'une charge de travail auprès d'une audience mondiale (pour rapprocher le point de terminaison des utilisateurs et/ou déployer des piles localisées pour l'audience de cette région). En tant que stratégie de reprise après sinistre, si la charge de travail ne peut pas être prise en charge dans l'une des Régions AWS vers lesquelles elle est déployée, cette région est évacuée, et les régions restantes sont utilisées pour assurer la disponibilité. La stratégie de reprise après sinistre multisite actif/actif est la plus complexe sur le plan opérationnel et ne doit être sélectionnée que lorsque les besoins de l'entreprise l'exigent.
![\[Diagramme illustrant une architecture multisite de type actif/actif\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
Pour plus de détails sur cette stratégie, consultez [Architecture de reprise après sinistre sur AWS, partie 4 : multisite actif/actif](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**Pratiques supplémentaires de protection des données**
Avec toutes les stratégies, vous devez également vous prémunir contre les catastrophes liées aux données La réplication continue des données vous protège contre certains types de sinistres, mais ne vous protège pas toujours contre la corruption ou la destruction des données, à moins que votre stratégie n'inclue également la gestion des versions des données stockées ou des options de récupération ponctuelle. Vous devez également sauvegarder les données répliquées sur le site de reprise pour créer des sauvegardes ponctuelles en plus des réplicas.
**Utilisation de plusieurs zones de disponibilité (AZ) dans une seule Région AWS**
Lorsque vous utilisez plusieurs AZ dans une même région, l'implémentation de la reprise après sinistre exploite plusieurs éléments des stratégies ci-dessus. Vous devez d'abord créer une architecture haute disponibilité (HA), en utilisant plusieurs AZ, comme illustré à la figure 23. Cette architecture utilise une approche multisite actif/actif, car les [instances Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) et le [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) a des ressources déployées dans plusieurs AZ et traite activement les demandes. Cette architecture illustre également la zone hébergée, où si l'instance [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) principale échoue (ou si l'AZ elle-même échoue), l'instance de secours est promue au rang d'instance principale.
![\[Diagramme illustrant la figure 23 : architecture de multi-AZ\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
En plus de cette architecture haute disponibilité, vous devez ajouter des sauvegardes de toutes les données requises pour exécuter votre charge de travail. Ceci est particulièrement important pour les données limitées à une seule zone, telles que les [volumes Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) ou [les clusters Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). Si une zone de disponibilité tombe en panne, vous devrez restaurer ces données dans une autre zone de disponibilité. Dans la mesure du possible, vous devez également copier les sauvegardes de données dans une autre Région AWS comme couche de protection supplémentaire.
Une alternative moins courante l'utilisation d'une seule région est la reprise après sinistre multi-AZ, comme illustré dans le billet de blog, [Création d'applications hautement résilientes à l'aide d'Amazon Route 53 Application Recovery Controller, partie 1 : pile dans une seule région](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). Dans ce cas, la stratégie consiste à maintenir autant que possible l'isolement entre les zones de disponibilité, à l'instar du fonctionnement des régions. Avec cette stratégie alternative, vous pouvez choisir une approche active/active ou active/passive.
Remarque : certaines charges de travail sont soumises à des exigences réglementaires en matière de situation géographique des données. Si cela s'applique à votre charge de travail dans une localité qui n'a actuellement qu'une seule Région AWS, plusieurs régions ne répondront pas aux besoins de votre entreprise. Les stratégies multi-AZ assurent une bonne protection contre la plupart des catastrophes.
1. **Évaluez les ressources de votre charge de travail et déterminez quelle sera leur configuration dans la région de reprise avant le basculement (pendant le fonctionnement normal).**
Pour l'infrastructure et les ressources AWS, utilisez l'infrastructure en tant que code, comme [AWS CloudFormation](https://aws.amazon.com/cloudformation) ou des outils tiers comme Hashicorp Terraform. Pour un déploiement sur plusieurs comptes et régions en une seule opération, vous pouvez utiliser [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). Pour les stratégies « Multisite actif/actif » et « Zone hébergée », l'infrastructure déployée dans la région de reprise dispose des mêmes ressources que la région principale. Pour les stratégies « Environnement en veille » et « Secours à chaud », l'infrastructure déployée nécessitera des actions supplémentaires pour être prête pour la production. Avec les paramètres CloudFormation [les paramètres](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) et [la logique conditionnelle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html), vous pouvez contrôler si une pile déployée est active ou en veille avec un seul modèle. Un exemple de modèle CloudFormation de ce type est inclus dans [ce billet de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Toutes les stratégies de reprise après sinistre nécessitent que les sources de données soient sauvegardées dans la Région AWS, puis ces sauvegardes sont copiées dans la région de reprise. [AWS Backup](https://aws.amazon.com/backup/) fournit une vue centralisée dans laquelle vous pouvez configurer, planifier et surveiller les sauvegardes de ces ressources. Pour les stratégies « Environnement en veille », « Secours à chaud » et « Multisite actif/actif », vous devez également répliquer les données de la région principale vers les ressources de données de la région de reprise, telles que des instances de base de données [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) ou des tables [Amazon DynamoDB](https://aws.amazon.com/dynamodb) . Ces ressources de données sont donc actives et prêtes à répondre aux demandes dans la région de reprise.
Pour en savoir plus sur le fonctionnement des services AWS dans les régions, consultez cette série de blog sur la [création d'une application multirégion avec les services AWS](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **Déterminez et mettez en œuvre la manière dont vous préparerez votre région de reprise pour le basculement en cas de besoin (lors d'un sinistre).**
Pour la stratégie Multisite actif/actif, le basculement consiste à évacuer une région et à s'appuyer sur les régions actives restantes. En général, ces régions sont prêtes à accepter du trafic. Pour les stratégies Environnement en veille et Secours à chaud, vos actions de récupération devront déployer les ressources manquantes, telles que les instances EC2 de la figure 20, ainsi que toute autre ressource manquante.
Pour toutes les stratégies ci-dessus, vous devrez peut-être promouvoir les instances en lecture seule des bases de données au rang d'instances principales en lecture/écriture.
Pour la sauvegarde et la restauration, la restauration des données à partir de la sauvegarde crée des ressources pour ces données, telles que des volumes EBS, des instances de base de données RDS et des tables DynamoDB. Vous devez également restaurer l'infrastructure et déployer le code. Vous pouvez utiliser AWS Backup pour restaurer les données dans la région de reprise. Consulter [REL09-BP01 Identifier et sauvegarder toutes les données qui doivent être sauvegardées, ou reproduire les données à partir de sources](rel_backing_up_data_identified_backups_data.md) pour en savoir plus. La reconstruction de l'infrastructure comprend la création de ressources telles que des instances EC2 en plus des [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc), des sous-réseaux et des groupes de sécurité requis. Vous pouvez automatiser une grande partie du processus de restauration. Pour en savoir plus, consultez [ce billet de blog](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **Déterminez et mettez en œuvre la manière dont vous redirigerez le trafic vers le basculement en cas de besoin (lors d'un sinistre).**
Cette opération de basculement peut être lancée automatiquement ou manuellement. Le basculement lancé automatiquement sur la base de vérifications de l'état ou d'alarmes doit être utilisé avec prudence, car un basculement inutile (fausse alerte) entraînerait des coûts tels que l'indisponibilité et la perte de données. Le basculement manuel est donc souvent utilisé. Dans ce cas, nous vous conseillons tout de même d'automatiser les étapes de basculement, de sorte que vous n'ayez à appuyer que sur un bouton pour lancer le basculement.
Il existe plusieurs options de gestion du trafic à prendre en compte lors de l'utilisation des services AWS. Une option consiste à utiliser [Amazon Route 53](https://aws.amazon.com/route53). Avec Amazon Route 53, vous pouvez associer plusieurs points de terminaison IP dans une ou plusieurs Régions AWS avec un nom de domaine Route 53. Pour implémenter le basculement initié manuellement, vous pouvez utiliser [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/), qui fournit une API de plan de données hautement disponible pour rediriger le trafic vers la région de reprise. Lors de la mise en œuvre du basculement, utilisez les opérations du plan de données et évitez celles du plan de contrôle, comme décrit dans [REL11-BP04 S'appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération](rel_withstand_component_failures_avoid_control_plane.md).
Pour en savoir plus à ce sujet et sur d'autres options, consultez [cette section du livre blanc sur la reprise après sinistre](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **Élaborez un plan pour déterminer la façon dont votre charge de travail se rétablira.**
La restauration consiste à renvoyer l'exploitation de la charge de travail à la région principale, après qu'un événement de sinistre s'est atténué. La mise en service de l'infrastructure et du code dans la région principale suit généralement les mêmes étapes que celles utilisées initialement. Elle s'appuie notamment sur l'infrastructure en tant que code et les pipelines de déploiement de code. Le défi posé par la restauration consiste à restaurer les magasins de données et à garantir leur cohérence avec la région de reprise en cours d'exécution.
Lors de l'état de basculement, les bases de données de la région de reprise sont actives et disposent des données à jour. L'objectif est alors de resynchroniser les données de la région de reprise vers la région principale, en s'assurant qu'elle est à jour.
Certains services AWS effectuent cette opération automatiquement. Si vous utilisez des [tables globales Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/), même si la table de la région principale devenait indisponible, DynamoDB reprendrait la propagation de toutes les écritures en attente lorsqu'elle se reconnecterait. Si vous utilisez une [base de données mondiale Amazon Aurora](https://aws.amazon.com/rds/aurora/global-database/) et que vous avez recours au [basculement planifié géré](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover), la topologie de réplication existante de la base de données mondiale Aurora est conservée. Par conséquent, l'ancienne instance en lecture/écriture de la région principale deviendra un réplica et recevra les mises à jour de la région de reprise.
Dans les cas où cela n'est pas automatique, vous devrez rétablir la base de données dans la région principale en tant que réplica de la base de données dans la région de reprise. Dans de nombreux cas, cela implique la suppression de l'ancienne base de données principale et la création de nouveaux réplicas. Par exemple, pour obtenir des instructions sur la façon de procéder avec une base de données mondiale Amazon Aurora impliquant un *basculement imprévu,* consultez cet atelier : [Basculer vers une base de données mondiale Aurora](https://awsauroralabsmy.com/global/failback/).
Après un basculement, si vous pouvez poursuivre l'exécution dans la région de reprise, envisagez d'en faire la nouvelle région principale. Vous devriez alors suivre toutes les étapes ci-dessus pour convertir l'ancienne région principale en région de reprise. Certaines organisations effectuent une rotation planifiée, en échangeant périodiquement leurs régions principale et de reprise (par exemple tous les trois mois).
Toutes les étapes nécessaires au basculement et au rétablissement doivent être conservées dans un playbook accessible à tous les membres de l'équipe et révisé périodiquement.
**Niveau d'effort du plan d'implémentation** : élevé
## Ressources
**Bonnes pratiques associées :**
+ [REL09-BP01 Identifier et sauvegarder toutes les données qui doivent être sauvegardées, ou reproduire les données à partir de sources](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 S'appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 Définir les objectifs de reprise pour les temps d'arrêt et les pertes de données](rel_planning_for_recovery_objective_defined_recovery.md)
**Documents connexes :**
+ [Blog d'architecture AWS : série sur la reprise après sinistre](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Options de reprise après sinistre dans le cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Créer une solution backend active-active sans serveur sur plusieurs régions en une heure](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Backend sans serveur sur plusieurs régions - rechargé](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS : réplication d'un réplica en lecture entre les régions](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53 : configuration du basculement DNS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3 : réplication entre régions](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [Qu'est-ce que AWS Backup ?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Qu'est-ce que Route 53 Application Recovery Controller ?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform : Premiers pas - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**Vidéos connexes :**
+ [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**Exemples connexes :**
+ [Ateliers AWS Well-Architected - Reprise après sinistre](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - Série d'ateliers illustrant les stratégies de reprise après sinistre
# REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre
Testez régulièrement le basculement vers le site de reprise pour vous assurer qu'il fonctionne correctement et que les RTO et RPO sont respectés.
S'il y a bien un modèle à éviter, c'est celui qui consiste à développer des chemins de récupération rarement testés. Par exemple, vous pouvez avoir un magasin de données secondaire qui est utilisé pour les requêtes en lecture seule. Lorsque vous écrivez dans un magasin de données et que l'instance principale connaît une défaillance, vous pouvez basculer vers le magasin de données secondaire. Si vous ne testez pas fréquemment ce basculement, vous constaterez peut-être que vos hypothèses sur les capacités du magasin de données secondaire sont incorrectes. La capacité du magasin de données secondaire, qui peut avoir été suffisante lors de votre dernier test, peut ne plus être en mesure de tolérer la charge dans le cadre de ce scénario. Notre expérience nous a montré que seul un chemin de récupération après erreur testé fréquemment fonctionne réellement. C'est pourquoi l'idéal est de n'avoir qu'un petit nombre de chemins de récupération. Vous pouvez établir des modèles de reprise et tester ceux-ci régulièrement. Si vous avez un chemin de récupération complexe ou critique, vous devez toujours exécuter régulièrement cette panne en production pour vous assurer du bon fonctionnement de ce chemin de récupération. Dans l'exemple que nous venons de présenter, vous devez procéder régulièrement au basculement vers l'instance de secours, quel que soit le besoin.
**Anti-modèles courants :**
+ Ne jamais exécuter de basculements en production.
**Avantages liés au respect de cette bonne pratique :** En testant régulièrement votre plan de DR, vous vous assurez qu'il fonctionnera quand il le faudra et que votre équipe sait comment exécuter la stratégie.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Préparez vos charges de travail pour la reprise. Testez régulièrement vos chemins de reprise : le calcul orienté récupération (ROC) identifie les caractéristiques des systèmes qui améliorent la reprise. Ces caractéristiques sont les suivantes : isolement et redondance, capacité de l'ensemble du système à réduire les modifications, capacité à surveiller et déterminer l'état de santé, capacité à fournir des diagnostics, reprise automatique, conception modulaire et capacité à redémarrer. Entraînez votre chemin de reprise pour vous assurer qu'elle peut s'effectuer au moment et à l'état spécifiés. Utilisez vos runbooks au cours de cette reprise pour documenter les problèmes et trouver des solutions pour les résoudre avant le prochain test.
+ [Projet informatique orientée reprise Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ Utilisez CloudEndure Disaster Recovery pour implémenter et tester votre stratégie de reprise après sinistre.
+ [Test de la solution de reprise après sinistre avec CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [CloudEndure Disaster Recovery vers AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog d'architecture AWS : série sur la reprise après sinistre](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Test de la solution de reprise après sinistre avec CloudEndure](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [Projet informatique orientée reprise Berkeley/Stanford](http://roc.cs.berkeley.edu/)
+ [Qu'est qu'AWS Fault Injection Simulator (AWS FIS) ?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS (STG208)](https://youtu.be/7gNXfo5HZN8)
**Exemples connexes :**
+ [Ateliers AWS Well-Architected : tester la résilience](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 Gérer l'écart de configuration au niveau du site ou de la région de reprise après sinistre
Assurez-vous que l'infrastructure, les données et la configuration sont conformes aux besoins du site ou de la région de reprise après sinistre. Par exemple, vérifiez que les AMI et les quotas de service sont à jour.
AWS Config surveille et enregistre en permanence les configurations de vos ressources AWS. Il peut détecter tout écart et déclencher [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour le corriger et activer les alarmes. AWS CloudFormation peut également détecter tout écart dans les piles que vous avez déployées.
**Anti-modèles courants :**
+ Ne pas effectuer les mises à jour dans vos emplacements de récupération, lorsque vous apportez des modifications à la configuration ou à l'infrastructure sur les emplacements principaux.
+ Ne pas prendre en compte des limitations potentielles (comme les différences de service) sur le site principal et le site de reprise.
**Avantages liés au respect de cette bonne pratique :** Pour une reprise complète, veillez à ce que votre environnement de reprise après sinistre soit cohérent avec votre environnement existant.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Assurez-vous que vos pipelines de diffusion assurent effectivement cette diffusion au niveau de votre site principal ainsi qu'au niveau de vos sites de sauvegarde. Les pipelines de diffusion pour le déploiement d'applications en production doivent être distribués à tous les emplacements spécifiés de la stratégie de DR, y compris les environnements de développement et de test.
+ Activez AWS Config pour suivre les écart potentiels au niveau des emplacements. Utilisez les règles AWS Config pour créer des systèmes qui appliquent vos stratégies de reprise après sinistre et génèrent des alertes lorsqu'elles détectent un écart.
+ [Correction des ressources AWS non conformes à l'aide des règles AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Utilisez AWS CloudFormation pour déployer votre infrastructure. AWS CloudFormation peut détecter l'écart entre ce que vos modèles CloudFormation spécifient et ce qui est réellement déployé.
+ [AWS CloudFormation : détection de tout écart à l'échelle d'une pile CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog d'architecture AWS : série sur la reprise après sinistre](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation : détection de tout écart à l'échelle d'une pile CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Comment mettre en œuvre une solution de gestion de configuration d'infrastructure sur AWS ?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [Correction des ressources AWS non conformes à l'aide des règles AWS Config Rules](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 Automatiser la reprise
Utilisez AWS ou des outils tiers pour automatiser la reprise du système et acheminer le trafic vers le site ou la région de reprise après sinistre.
En fonction des vérifications de l'état configurées, les services AWS tels qu'Elastic Load Balancing et AWS Auto Scaling peuvent répartir la charge vers des zones de disponibilité saines, tandis que les services tels qu'AWS et Global Accelerator peuvent acheminer la charge vers des Régions AWS saines. Amazon Route 53 Application Recovery Controller vous aide à gérer et à coordonner le basculement à l'aide de vérifications de l'état de préparation et fonctionnalités de contrôle du routage. Ces fonctionnalités surveillent en permanence la capacité de votre application à se rétablir après une défaillance et vous permettent de contrôler la reprise de votre application dans plusieurs Régions AWS, zones de disponibilité et sur site.
Pour les charges de travail sur des centres de données physiques ou virtuels existants ou des clouds privés, [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)disponible via AWS Marketplace, permet aux organisations de configurer une stratégie de reprise après sinistre automatisée pour AWS. CloudEndure prend également en charge la reprise après sinistre entre régions et zones de disponibilité dans AWS.
**Anti-modèles courants :**
+ La mise en œuvre d'un système de basculement et de restauration automatisés identique peut entraîner une oscillation de chemin lorsqu'une défaillance se produit.
**Avantages liés au respect de cette bonne pratique :** La reprise automatique réduit le temps de reprise en éliminant les risques d'erreurs manuelles.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Automatisez les chemins de récupération. Pour les temps de reprise courts, le jugement et les actions de l'humain ne peuvent pas être utilisés pour des scénarios à haute disponibilité. Le système doit absolument reprendre automatiquement, quelle que soit la situation.
+ Utilisez CloudEndure Disaster Recovery pour un basculement et une restauration automatisés. CloudEndure Disaster Recovery réplique en continu vos machines (notamment le système d'exploitation, la configuration d'état du système, les bases de données, les applications et les fichiers) dans une zone intermédiaire économique de votre Compte AWS cible et de votre région préférée. En cas de sinistre, vous pouvez demander à CloudEndure Disaster Recovery de lancer automatiquement des milliers de vos machines dans leur état entièrement mis en service en quelques minutes.
+ [Exécution d'un basculement et d'une reprise après sinistre](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [Blog d'architecture AWS : série sur la reprise après sinistre](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [CloudEndure Disaster Recovery vers AWS](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Reprise après sinistre des charges de travail sur AWS : reprise dans le cloud (livre blanc AWS)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)