# Planification de la reprise après sinistre
La mise en place de sauvegardes et de composants de charge de travail redondants constitue le début de votre stratégie de DR. [L’objectif de délai de reprise (RTO) et l’objectif de point de reprise (RPO)](disaster-recovery-dr-objectives.md) sont vos objectifs 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.
La disponibilité et la reprise après sinistre s’appuient sur les mêmes bonnes pratiques, telles que la surveillance des pannes, le déploiement sur plusieurs sites et le basculement automatique. Cependant, la disponibilité se concentre sur les composants de la charge de travail, tandis que la reprise après sinistre se concentre sur des copies distinctes de l’ensemble de la charge de travail. La reprise après sinistre a des objectifs différents de la disponibilité, car elle se concentre sur le temps de récupération après un sinistre.
**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
Les défaillances peuvent avoir un impact sur votre activité de plusieurs manières. Tout d’abord, les défaillances peuvent entraîner une interruption de service (durée d’indisponibilité). Ensuite, les défaillances peuvent entraîner la perte, l’incohérence ou l’obsolescence des données. Pour déterminer la manière de réagir et de récupérer après une défaillance, définissez un objectif de délai de reprise (RTO) et un objectif de point de reprise (RPO) pour chaque charge de travail. L’*objectif de délai de reprise (RTO)* est le délai maximal acceptable entre l’interruption du service et son rétablissement. *L’objectif de point de reprise (RPO)* est le temps maximal acceptable après le dernier point de récupération des données.
**Résultat escompté :** chaque charge de travail dispose d’un RTO et d’un RPO basés sur des considérations techniques et l’impact sur l’activité.
**Anti-modèles courants:**
+ Vous n’avez pas défini d’objectifs de récupération.
+ Vous sélectionnez des objectifs de récupération arbitraires.
+ Vous sélectionnez des objectifs de récupération trop souples qui ne répondent pas aux objectifs de l’entreprise.
+ Vous n’avez pas évalué l’impact de la durée d’indisponibilité et de la perte de données.
+ Vous sélectionnez des objectifs de récupération non réalistes pour la configuration de votre charge de travail, tels qu’un délai de récupération nul ou une perte de données nulle, qui ne sont pas réalisables.
+ Vous sélectionnez des objectifs de récupération plus rigoureux que les objectifs métier réels. Cela entraîne une mise en œuvre de la récupération plus coûteuse et plus compliquée que ce dont la charge de travail a besoin.
+ Vous sélectionnez des objectifs de récupération incompatibles avec ceux d’une charge de travail dépendante.
+ Vous ne tenez pas compte des exigences réglementaires et de conformité.
**Avantages liés au respect de cette bonne pratique :** lorsque vous définissez des RTO et des RPO pour vos charges de travail, vous définissez des objectifs de récupération clairs et mesurables en fonction des besoins de votre entreprise. Une fois ces objectifs définis, vous pouvez créer des plans de reprise après sinistre (DR) spécialement conçus pour les atteindre.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Créez une matrice ou une fiche qui vous aidera à planifier la reprise après sinistre. Dans cette matrice, créez différentes catégories ou niveaux de charge de travail en fonction de leur impact sur l’activité (critique, élevé, moyen ou faible) et des RTO et RPO associés à cibler pour chacun d’entre eux. La matrice suivante fournit un exemple (notez que vos valeurs RTO et RPO peuvent différer) que vous pouvez suivre :
![\[Graphique illustrant la matrice de reprise après sinistre\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/disaster-recovery-matrix.png)
Pour chaque charge de travail, vous devez étudier et comprendre l’impact de la durée d’indisponibilité et de la perte de données sur votre activité. Cet impact augmente généralement avec la durée d’indisponibilité et la perte de données, mais sa forme peut varier en fonction du type de charge de travail. Par exemple, une durée d’indisponibilité d’une heure peut avoir un impact faible, mais après cela, l’impact peut croître rapidement. L’impact peut prendre de nombreuses formes, y compris la forme d’un impact financier (tel qu’une perte de chiffre d’affaires), d’un impact sur la réputation (y compris la perte de confiance des clients), d’un impact opérationnel (comme une paie manquée ou une baisse de productivité) et d’un risque réglementaire. Une fois terminé, attribuez la charge de travail au niveau approprié.
Lorsque vous analysez l’impact d’une panne, posez-vous les questions suivantes :
1. Quelle est la durée maximale d’indisponibilité de la charge de travail avant qu’elle n’ait un impact inacceptable sur l’activité ?
1. Quelle est l’ampleur et la nature de l’impact d’une interruption de la charge de travail sur l’entreprise ? Tenez compte de tous les types d’impact, notamment financier, de réputation, opérationnel et réglementaire.
1. Quelle est la quantité maximale de données pouvant être perdues ou irrécupérables avant que l’activité ne subisse un impact inacceptable ?
1. Les données perdues peuvent-elles être recréées à partir d’autres sources (également appelées données *dérivées*) ? Si tel est le cas, considérez également les RPO de toutes les données sources utilisées pour recréer les données de la charge de travail.
1. Quels sont les objectifs de récupération et les attentes de disponibilité des charges de travail dont celle-ci dépend (en aval) ? Vos objectifs en matière de charge de travail doivent être réalisables compte tenu des capacités de récupération de ses dépendances en aval. Envisagez des solutions de contournement ou d’atténuation des dépendances en aval susceptibles d’améliorer la capacité de récupération de cette charge de travail.
1. Quels sont les objectifs de récupération et les attentes de disponibilité des charges de travail qui dépendent de celle-ci (en amont) ? Les objectifs de charge de travail en amont peuvent exiger que cette charge de travail soit dotée de capacités de récupération plus strictes qu’il n’y paraît initialement.
1. Les objectifs de récupération sont-ils différents en fonction du type d’incident ? Par exemple, vous pouvez avoir des RTO et des RPO différents selon que l’incident a un impact sur une zone de disponibilité ou sur une région entière.
1. Vos objectifs de récupération changent-ils au cours de certains événements ou à certaines périodes de l’année ? Par exemple, vous pouvez avoir des RTO et des RPO différents pour les fêtes de fin d’année, lors d’événements sportifs, en périodes de soldes et lors du lancement de nouveaux produits.
1. Comment les objectifs de récupération s’alignent-ils sur la stratégie de reprise après sinistre de votre secteur d’activité et de votre organisation ?
1. Y a-t-il des ramifications juridiques ou contractuelles à prendre en compte ? Par exemple, avez-vous l’obligation contractuelle de fournir un service avec un RTO ou un RPO donné ? Quelles pénalités pourriez-vous encourir en cas de non-respect de cette obligation ?
1. Devez-vous maintenir l’intégrité des données pour répondre aux exigences réglementaires ou de conformité ?
La fiche suivante peut vous aider à évaluer chaque charge de travail. Vous pouvez modifier cette fiche en fonction de vos besoins spécifiques, par exemple en ajoutant des questions supplémentaires.
![\[Fiche\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/worksheet.png)
### Étapes d’implémentation
1. Identifiez les parties prenantes et les équipes techniques responsables de chaque charge de travail et interagissez avec elles.
1. Créez des catégories ou des niveaux de criticité pour déterminer l’impact de la charge de travail dans votre organisation. Exemples de catégories : critique, élevé, moyen et faible. Pour chaque catégorie, choisissez un RTO et un RPO qui reflètent les objectifs et les exigences de votre activité.
1. Attribuez l’une des catégories d’impact que vous avez créées à l’étape précédente à chaque charge de travail. Pour déterminer la correspondance d’une charge de travail à une catégorie, tenez compte de l’importance de la charge de travail pour l’activité et de l’impact de son interruption ou d’une perte de données, et utilisez les questions ci-dessus pour vous guider. Cela se traduit par un RTO et un RPO pour chaque charge de travail.
1. Pour chaque charge de travail, tenez compte du RTO et du RPO déterminés à l’étape précédente. Impliquez les équipes stratégiques et techniques chargées de la charge de travail afin de déterminer si les objectifs doivent être ajustés. Par exemple, les parties prenantes de l’entreprise peuvent déterminer que des objectifs plus stricts sont requis. Par ailleurs, les équipes techniques peuvent décider de la nécessité de modifier les cibles pour les rendre réalisables dans le cadre des contraintes technologiques et des ressources disponibles.
## 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](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documents connexes :**
+ [AWS Blog d’architecture : 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](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.
**Résultat escompté :** 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 reprise définies améliore le partage des connaissances entre les équipes et la mise en œuvre de la reprise après sinistre sur les charges de travail qu’elles possèdent.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé. 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
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 classées par ordre croissant de coût et de complexité, et par ordre décroissant de RTO et RPO. La *région de restauration* fait référence à une région 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/latest/reliability-pillar/images/disaster-recovery-strategies.png)
+ **Sauvegarde et restauration** (RPO en heures, RTO de 24 heures maximum) : sauvegardez vos données et applications dans la région de reprise après sinistre. L’utilisation de sauvegardes automatisées ou continues permet une reprise ponctuelle (PITR), 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.
+ **Veilleuse** (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 semi-automatique** (RPO de quelques secondes, RTO de quelques minutes) : maintenez une version réduite verticalement 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 verticalement. 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’elle est entièrement mise à l’échelle, on parle de *veille permanente*.
+ **Multi-région (multi-site) active-active** (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 verticalement, tandis que le secours à chaud nécessite uniquement une augmentation verticale (tout est déjà déployé et en cours d’exécution). Choisissez entre ces options en fonction de vos besoins en matière de RTO et de RPO.
Si le coût est un problème et que vous souhaitez atteindre des objectifs de RPO et RTO similaires à ceux définis dans la stratégie de secours à chaud, vous pouvez envisager des solutions natives du cloud, comme Reprise après sinistre AWS Elastic, qui adoptent l’approche de l’environnement de veille et offrent des objectifs de RPO et RTO améliorés.
**É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 de reprise après sinistre 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/latest/reliability-pillar/images/choosing-a-dr-strategy.png)
Pour en savoir plus, consultez [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 suivantes, vous pouvez appliquer 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/latest/reliability-pillar/images/backup-restore-architecture.png)
Pour en savoir plus 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/).
**Veilleuse**
L’approche de *veilleuse*, vous permet de répliquer 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/latest/reliability-pillar/images/pilot-light-architecture.png)
Pour en savoir plus 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 semi-automatique**
L’approche du *secours semi-automatique* consiste à s’assurer qu’il existe une copie réduite verticalement, 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 *veille permanente*.
![\[Schéma illustrant la figure 21 : Architecture de secours à chaud\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/warm-standby-architecture.png)
L’utilisation du secours à chaud ou de l’environnement en veille nécessite une augmentation verticale des ressources dans la région de reprise. Pour vérifier que la capacité est disponible en cas de besoin, envisagez de l’utiliser pour les [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é provisionnée](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) peut fournir des environnements d’exécution afin qu’ils soient prêts à répondre immédiatement aux invocations 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 active/active*. 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/latest/reliability-pillar/images/multi-site-active-active-architecture.png)
Pour en savoir plus 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/).
**Reprise après sinistre AWS Elastic**
Si vous envisagez d’adopter une stratégie de veilleuse ou de secours à chaud pour la reprise après sinistre, Reprise après sinistre AWS Elastic peut proposer une autre approche offrant de meilleurs avantages. Elastic Disaster Recovery peut offrir un objectif de RPO et de RTO similaire à celui du mode de secours à chaud, tout en conservant l’approche peu coûteuse de la veilleuse. Elastic Disaster Recovery réplique vos données de votre région principale vers votre région de reprise, en utilisant une protection continue des données pour atteindre un RPO mesuré en secondes et un RTO mesurable en minutes. Seules les ressources nécessaires à la réplication des données sont déployées dans la région de reprise, ce qui permet de limiter les coûts, à l’instar de la stratégie de l’environnement de veille. En cas d’utilisation de Elastic Disaster Recovery, le service coordonne et orchestre la récupération des ressources informatiques lorsqu’elle est initiée dans le cadre d’un basculement ou d’une opération.
![\[Schéma d’architecture décrivant comment Reprise après sinistre AWS Elastic fonctionne.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/drs-architecture.png)
**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 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) disposent de ressources déployées dans plusieurs zones de disponibilité, ce qui permet de traiter activement les demandes. L’architecture fait également appel au mode de veille permanente : en cas de défaillance de l’instance [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) principale (ou de l’AZ elle-même), l’instance de secours est promue en instance principale.
![\[Diagramme illustrant la figure 24 : architecture de multi-AZ\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/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. Une telle mesure est particulièrement importante 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 approche alternative moins courante à la reprise après sinistre multi-AZ à une seule région est illustrée dans le billet de blog intitulé [Création d’applications hautement résilientes à l’aide d’Amazon 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.
**Note**
Certaines charges de travail sont soumises à des exigences réglementaires en matière de résidence 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 sous forme de code tel que [AWS CloudFormation](https://aws.amazon.com/cloudformation) ou des outils tiers tels que 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 « Veille permanente », 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. À l’aide des [paramètres](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) et de la [logique conditionnelle](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html) de CloudFormation, vous pouvez contrôler si une pile déployée est active ou en veille avec [un seul modèle](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/). En utilisant Elastic Disaster Recovery, le service répliquera et orchestrera la restauration des configurations d’applications et des ressources informatiques.
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 que ces sauvegardes soient copiées dans la région de restauration. [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 les 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 différentes régions, consultez cette série de blogs sur la [création d’une application multi-régionale avec des 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 reprise 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. Pour plus d’informations, consultez [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). La reconstruction de l’infrastructure inclut la création de ressources telles que des instances EC2 en plus du [Virtual Private Cloud (VPC) Amazon](https://aws.amazon.com/vpc), des sous-réseaux et des groupes de sécurité nécessaires. Vous pouvez automatiser une grande partie du processus de restauration. Pour savoir comment procéder, 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 la surveillance 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. L’une des options consiste à utiliser [Amazon Route 53](https://aws.amazon.com/route53). Amazon Route 53 vous permet d’associer plusieurs points de terminaison IP dans une ou plusieurs Régions AWS avec un nom de domaine Route 53. Pour mettre en œuvre le basculement initié manuellement, vous pouvez utiliser [Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/), qui fournit une API de plan de données hautement disponible pour rediriger le trafic vers la région de récupération. 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.**
Failback 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 failback 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 [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) et que vous utilisez un [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 globale 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.
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.
En utilisant Elastic Disaster Recovery, le service permettra d’orchestrer et d’automatiser le processus de failback. Pour en savoir plus, consultez la section [Réalisation d’un failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html).
**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:**
+ [AWS Blog d’architecture : 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 dorsale active-active sans serveur sur plusieurs régions en une heure](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Solution dorsale 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 qu’Amazon Application Recovery Controller ?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Reprise après sinistre Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform : Démarrage – 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)
# 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 votre site de reprise pour vérifier qu’il fonctionne correctement et que les RTO et RPO sont respectés.
**Anti-modèles courants :**
+ Ne jamais exécuter de basculements en production.
**Avantages du respect de cette bonne pratique :** en testant régulièrement votre plan de reprise après sinistre, vous vous assurez qu’il fonctionnera quand il le faudra et que votre équipe sait comment exécuter la stratégie.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
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 a montré que le seul chemin de récupération après erreur qui fonctionne est celui que vous testez fréquemment. 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.
**Étapes d’implémentation**
1. Préparez vos charges de travail pour la reprise. Testez régulièrement vos chemins de récupération. L’informatique orientée récupération identifie les caractéristiques des systèmes qui améliorent la récupération : 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 vérifier qu’il 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.
1. Pour les charges de travail basées sur Amazon EC2, utilisez [Reprise après sinistre AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) pour implémenter et lancer des instances de test dans le cadre de votre stratégie de reprise après sinistre. Reprise après sinistre AWS Elastic permet d’exécuter des tests de manière efficace, ce qui vous aide à vous préparer en cas de basculement. Vous pouvez également lancer fréquemment vos instances en utilisant Elastic Disaster Recovery à des fins de test et d’opération sans rediriger le trafic.
## Ressources
**Documents connexes:**
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Blog d’architecture : 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)
+ [Reprise après sinistre AWS Elastic](https://aws.amazon.com/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)
+ [Préparation au basculement Reprise après sinistre AWS Elastic](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html)
+ [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](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS](https://youtu.be/7gNXfo5HZN8)
# REL13-BP04 Gérer l’écart de configuration au niveau du site ou de la région de reprise après sinistre
Pour mener à bien une procédure de reprise après sinistre (DR), votre charge de travail doit être en mesure de reprendre son fonctionnement normal en temps opportun, sans aucune perte de fonctionnalité ni de données une fois que l’environnement de reprise après sinistre a été mis en ligne. Pour atteindre cet objectif, il est essentiel de maintenir une infrastructure, des données et des configurations cohérentes entre votre environnement de reprise après sinistre et l’environnement principal.
**Résultat escompté :** la configuration et les données de votre site de reprise après sinistre sont identiques à celles du site principal, ce qui permet une récupération rapide et complète au moment requis.
**Anti-modèles courants :**
+ Vous ne mettez pas à jour les emplacements de récupération lorsque des modifications sont apportées aux emplacements principaux, ce qui entraîne une obsolescence des configurations, susceptible d’entraver les efforts de récupération.
+ Vous ne tenez pas compte des limitations potentielles telles que les différences de service entre les emplacements principaux et de récupération, ce qui peut entraîner des échecs inattendus lors du basculement.
+ Vous vous appuyez sur des processus manuels pour mettre à jour et synchroniser l’environnement de reprise après sinistre, ce qui augmente le risque d’erreur humaine et d’incohérence.
+ Vous ne détectez pas une dérive de configuration et avez une fausse impression de l’état de préparation du site de reprise après sinistre avant un incident.
**Avantages liés au respect de cette bonne pratique :** la cohérence entre l’environnement de reprise après sinistre et l’environnement principal améliore considérablement les chances de réussite de la récupération après un incident et réduit le risque d’échec de la procédure de récupération.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Une approche globale de la gestion de la configuration et de la préparation au basculement peut vous aider à vérifier que le site de reprise après sinistre est régulièrement mis à jour et prêt à prendre le relais en cas de défaillance du site principal.
Pour garantir la cohérence entre votre environnement principal et votre environnement de reprise après sinistre (DR), assurez-vous que vos pipelines de distribution répartissent les applications à la fois sur votre site principal et sur votre site de reprise après sinistre. Déployez les modifications sur les sites de reprise après une période d’évaluation appropriée (on parle alors de *déploiements échelonnés*) afin de détecter les problèmes sur le site principal et d’arrêter le déploiement avant qu’ils ne se propagent. Mettez en œuvre une surveillance pour détecter les dérives de configuration et suivre les modifications et la conformité dans l’ensemble de vos environnements. Procédez à des corrections automatisées sur le site de reprise après sinistre pour qu’il reste totalement cohérent et prêt à prendre le relais en cas d’incident.
### Étapes d’implémentation
1. Vérifiez que la région de reprise après sinistre contient les services et fonctionnalités AWS nécessaires à la bonne exécution de votre plan de reprise après sinistre.
1. Utilisez une infrastructure en tant que code (IaC). Maintenez l’exactitude de vos modèles de configuration de l’infrastructure de production et des applications, et appliquez-les régulièrement à votre environnement de reprise après sinistre. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) peut détecter des dérives entre ce que vos modèles CloudFormation spécifient et ce qui est réellement déployé.
1. Configurez des pipelines CI/CD pour déployer des applications et des mises à jour d’infrastructure dans tous les environnements, y compris les sites principaux et de reprise après sinistre. Les solutions CI/CD telles qu’[AWS CodePipeline](https://aws.amazon.com/codepipeline/) peuvent automatiser le processus de déploiement, ce qui réduit le risque de dérive de la configuration.
1. Échelonnez les déploiements entre l’environnement principal et l’environnement de reprise après sinistre. Cette approche permet de déployer et de tester initialement les mises à jour dans l’environnement principal, ce qui permet d’isoler les problèmes sur le site principal avant qu’ils ne soient propagés au site de reprise après sinistre. Cette approche empêche la transmission simultanée des défauts en production et au site de reprise après sinistre et préserve l’intégrité de l’environnement de reprise après sinistre.
1. Surveillez en permanence les configurations des ressources dans l’environnement principal et l’environnement de reprise après sinistre. Des solutions telles qu’[AWS Config](https://aws.amazon.com/config/) peuvent aider à renforcer la conformité des configurations et à détecter les dérives, ce qui permet de maintenir la cohérence des configurations dans tous les environnements.
1. Mettez en œuvre des mécanismes d’alerte pour suivre et signaler toute dérive de configuration, ainsi que toute interruption ou tout retard de réplication des données.
1. Automatisez la correction des dérives de configuration détectées.
1. Planifiez des audits et des contrôles de conformité réguliers pour vérifier l’alignement continu entre les configurations principale et de reprise après sinistre. Les examens périodiques vous aident à maintenir la conformité aux règles définies et à identifier les éventuelles anomalies à corriger.
1. Recherchez des disparités au niveau de la capacité provisionnée, des quotas de service, des limitations et des différences de configuration et de version AWS.
## Ressources
**Bonnes pratiques associées :**
+ [REL01-BP01 Connaître les quotas de service et les contraintes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html)
+ [REL01-BP02 Gérer les quotas de service entre les comptes et les régions](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html)
+ [REL01-BP04 Surveiller et gérer les quotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**Documents connexes :**
+ [Correction des ressources AWS non conformes par 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)
+ [AWS CloudFormation : Détection de modifications non gérées de la configuration des piles et des ressources](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)
+ [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 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 par 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)
**Exemples connexes :**
+ [CloudFormation Registry](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/)
+ [Quota Monitor for AWS](https://aws.amazon.com/solutions/implementations/quota-monitor/)
+ [Mise en œuvre de la correction automatique des dérives pour AWS CloudFormation à l’aide d’Amazon CloudWatch et d’AWS Lambda](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/)
+ [AWS Blog d’architecture : 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)
+ [Automatiser les déploiements sécurisés et sans intervention](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
# REL13-BP05 Automatiser la reprise
Mettez en œuvre des mécanismes de reprise testés et automatisés, à la fois fiables, observables et reproductibles afin de réduire le risque et l’impact sur l’activité d’une panne.
**Résultat escompté :** vous avez mis en œuvre un flux de travail d’automatisation bien documenté, standardisé et entièrement testé pour les processus de récupération. L’automatisation de la récupération corrige automatiquement les problèmes mineurs qui présentent un faible risque d’indisponibilité ou de perte de données. Vous êtes en mesure d’invoquer rapidement des processus de récupération pour des incidents graves, d’observer le comportement de correction pendant leur fonctionnement et de mettre fin aux processus si vous observez des situations dangereuses ou des défaillances.
**Anti-modèles courants :**
+ Dans le cadre de votre plan de reprise, vous dépendez de composants ou de mécanismes défaillants ou dégradés.
+ Vos processus de récupération nécessitent une intervention manuelle, telle que l’accès à la console (également appelé *ClickOps*).
+ Vous lancez automatiquement les procédures de récupération dans les situations présentant un risque élevé d’indisponibilité ou de perte de données.
+ Vous omettez d’inclure un mécanisme permettant d’annuler une procédure de récupération (comme un *système Andon* ou un *bouton d’arrêt d’urgence*) qui ne fonctionne pas ou qui présente des risques supplémentaires.
**Avantages liés au respect de cette bonne pratique :**
+ Fiabilité, prévisibilité et cohérence accrues des opérations de récupération.
+ Capacité à atteindre des objectifs de reprise plus stricts, notamment l’objectif de délai de reprise (RTO) et l’objectif de point de reprise (RPO).
+ Diminution du risque d’échec de la récupération lors d’un incident.
+ Réduction du risque d’échec associé aux processus de récupération manuels susceptibles de provoquer des erreurs humaines.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Pour mettre en œuvre la restauration automatique, vous avez besoin d’une approche globale qui utilise les services et les bonnes pratiques AWS. Pour commencer, identifiez les composants critiques et les points de défaillance potentiels de votre charge de travail. Développez des processus automatisés capables de récupérer vos charges de travail et vos données en cas de panne sans intervention humaine.
Développez l’automatisation de la récupération en utilisant les principes de l’infrastructure en tant que code (IaC). Cela rend votre environnement de récupération cohérent avec l’environnement source et permet de contrôler la version de vos processus de récupération. Pour orchestrer des flux de travail de récupération complexes, envisagez des solutions telles que [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ou [AWS Step Functions](https://aws.amazon.com/step-functions/).
L’automatisation des processus de récupération présente des avantages considérables et peut vous aider à atteindre plus facilement votre objectif de délai de reprise (RTO) et votre objectif de point de reprise (RPO). Toutefois, vous pouvez rencontrer des situations inattendues susceptibles de provoquer un échec ou de créer de nouveaux risques, tels qu’une durée d’indisponibilité et une perte de données supplémentaires. Pour atténuer ce risque, offrez la possibilité d’arrêter rapidement une automatisation de récupération en cours. Une fois celle-ci arrêtée, vous pouvez enquêter et prendre des mesures correctives.
Pour les charges de travail prises en charge, envisagez des solutions telles qu’AWS Elastic Disaster Recovery (AWS DRS) pour fournir un basculement automatisé. AWS DRS 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 de votre Compte AWS cible et de votre région préférée. En cas d’incident, AWS DRS automatise la conversion de vos serveurs répliqués en charges de travail entièrement provisionnées dans votre région de récupération sur AWS.
La maintenance et l’amélioration de la récupération automatisée sont un processus continu. Testez et affinez continuellement vos procédures de récupération sur la base des enseignements acquis, et tenez-vous au fait des nouveaux services et fonctionnalités AWS susceptibles d’améliorer vos capacités de récupération.
### Étapes d’implémentation
1. **Planifier une récupération automatisée**
1. Réalisez un examen approfondi de l’architecture, des composants et des dépendances de votre charge de travail afin d’identifier et de planifier des mécanismes de récupération automatisés. Classez les dépendances de votre charge de travail en dépendances *strictes* et *souples*. Les dépendances strictes sont celles sans lesquelles la charge de travail ne peut pas fonctionner et que rien ne peut substituer. Les dépendances souples sont celles que la charge de travail utilise habituellement, mais qui peuvent être remplacées par des systèmes ou des processus de substitution temporaires ou qui peuvent être traitées par une [dégradation appropriée](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation).
1. Établissez des processus pour identifier et récupérer les données manquantes ou corrompues.
1. Définissez les étapes permettant de confirmer le rétablissement d’un état stable après l’exécution des actions de récupération.
1. Envisagez toutes les actions nécessaires pour préparer le système récupéré à être pleinement opérationnel, telles que la préparation et le remplissage des caches.
1. Tenez compte des problèmes susceptibles d’être rencontrés au cours du processus de récupération et de la manière de les détecter et de les corriger.
1. Envisagez des scénarios dans lesquels le site principal et son plan de contrôle sont inaccessibles. Vérifiez que les actions de récupération peuvent être effectuées indépendamment, sans avoir recours au site principal. Envisagez des solutions telles qu’[Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) pour rediriger le trafic sans qu’il soit nécessaire de muter manuellement les enregistrements DNS.
1. **Développer un processus de récupération automatisé**
1. Mettez en œuvre des mécanismes automatisés de détection des pannes et de basculement pour une récupération sans intervention manuelle. Créez des tableaux de bord avec des outils tels qu’[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) pour rendre compte de la progression et de l’état des procédures de récupération automatisées. Incluez des procédures pour valider la réussite de la récupération. Fournissez un mécanisme permettant d’annuler une récupération en cours.
1. Créez des [playbooks](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency) comme processus de secours pour les pannes qui ne permettent pas une récupération automatique, et tenez compte de votre [plan de reprise après sinistre](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts).
1. Testez les processus de récupération comme indiqué dans le document [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html).
1. **Préparer la récupération**
1. Évaluez l’état de votre site de reprise et déployez-y les composants stratégiques à l’avance. Pour plus de détails, consultez [REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).
1. Définissez des rôles, des responsabilités et des processus décisionnels clairs pour les opérations de récupération, en impliquant les parties prenantes et les équipes sur l’ensemble de l’organisation.
1. Définissez les conditions pour lancer vos processus de récupération.
1. Créez un plan pour annuler le processus de récupération et revenir à votre site principal si nécessaire ou une fois que celui-ci est considéré comme sûr.
## Ressources
**Bonnes pratiques associées :**
+ [REL07-BP01 Utiliser l’automatisation lors de l’obtention des ressources ou de leur mise à l’échelle](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html)
+ [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html)
+ [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 Effectuer un test de validation de la mise en œuvre de la reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html)
+ [REL13-BP04 Gérer la dérive de configuration au niveau du site ou de la région de reprise après sinistre](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)
**Documents connexes :**
+ [AWS Architecture Blog: Disaster Recovery Series](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud (AWS Whitepaper)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Orchestration de l’automatisation de la reprise après sinistre à l’aide d’Amazon Route 53 ARC et d’AWS Step Functions](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/)
+ [Création de dossiers d¦exploitation AWS Systems Manager Automation à l’aide d’AWS CDK](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/)
+ [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 Elastic AWS](https://aws.amazon.com/disaster-recovery/)
+ [Utilisation d’Elastic Disaster Recovery pour le basculement et le failback](https://docs.aws.amazon.com/drs/latest/userguide/failback.html)
+ [Ressources de reprise après sinistre Elastic AWS](https://aws.amazon.com/disaster-recovery/resources/)
+ [Partenaire APN : partenaires pouvant faciliter la reprise après sinistre](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2022: AWS On Air ft. AWS Failback for AWS Elastic Disaster Recovery](https://youtu.be/Ok-vpV8b1Hs)