# Gestion des défaillances
**Topics**
+ [REL 9 Comment sauvegarder des données ?](w2aac19b9c11b5.md)
+ [REL 10 Comment utiliser l'isolation des pannes pour protéger votre charge de travail ?](w2aac19b9c11b7.md)
+ [REL 11 Comment concevoir votre charge de travail pour la rendre résistante aux défaillances de composants ?](w2aac19b9c11b9.md)
+ [REL 12 Comment tester la fiabilité ?](w2aac19b9c11c11.md)
+ [REL 13 Comment planifier la reprise après sinistre (DR) ?](w2aac19b9c11c13.md)
# REL 9 Comment sauvegarder des données ?
Sauvegardez les données, les applications et la configuration pour répondre à vos exigences en matière d'objectifs de délai de reprise (RTO) et d'objectifs de point de reprise (RPO).
**Topics**
+ [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)
+ [REL09-BP02 Sécuriser et chiffrer les sauvegardes](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 Effectuer automatiquement la sauvegarde des données](rel_backing_up_data_automated_backups_data.md)
+ [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)
# REL09-BP01 Identifier et sauvegarder toutes les données qui doivent être sauvegardées, ou reproduire les données à partir de sources
Tous les magasins de données AWS offrent des fonctionnalités de sauvegarde. Des services comme Amazon RDS et Amazon DynamoDB prennent également en charge la sauvegarde automatisée qui permet la récupération ponctuelle (PITR). Vous pouvez ainsi restaurer une sauvegarde remontant jusqu'à cinq minutes ou moins avant l'heure actuelle. De nombreux services AWS offrent la possibilité de copier des sauvegardes vers une autre Région AWS. AWS Backup est un outil qui vous permet de centraliser et d'automatiser la protection des données sur les services AWS.
Amazon S3 peut être utilisé comme destination de sauvegarde pour les sources de données autogérées et gérées par AWS. Les services AWS tels qu'Amazon EBS, Amazon RDS et Amazon DynamoDB ont des fonctionnalités intégrées permettant de créer des sauvegardes. Vous pouvez aussi utiliser des logiciels de sauvegarde tiers.
Les données sur site peuvent être sauvegardées dans le AWS Cloud avec [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) ou [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html). Des compartiments Amazon S3 peuvent être utilisés pour stocker ces données sur AWS. Amazon S3 offre plusieurs niveaux de stockage comme [Amazon Glacier ou S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) pour réduire les coûts de stockage des données.
Il se peut que vous puissiez répondre aux besoins de récupération de données en reproduisant les données à partir d'autres sources. Par exemple, [les nœuds de réplica Amazon Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) ou [les réplicas en lecture RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) pourraient être utilisés pour reproduire des données si la source principale est perdue. Dans les cas où des sources comme celle-ci pourraient être mises à profit pour répondre à votre [objectif de point de récupération (RPO) et à votre objectif de temps de récupération (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html), une sauvegarde n'est peut-être pas nécessaire. Autre exemple, si vous travaillez avec Amazon EMR, il n'est peut-être pas nécessaire de sauvegarder votre magasin de données HDFS, tant que vous pouvez [reproduire les données dans EMR à partir de S3](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
Lors de la sélection d'une stratégie de sauvegarde, tenez compte du temps nécessaire pour récupérer les données. Le temps nécessaire pour récupérer les données dépend du type de sauvegarde (dans le cas d'une stratégie de sauvegarde) ou de la complexité du mécanisme de reproduction des données. Cette durée doit être conforme au RTO de la charge de travail.
**Résultat souhaité :**
Les sources de données ont été identifiées et classées en fonction de leur ordre d'importance. Définissez ensuite une stratégie de récupération des données basée sur le RPO. Cette stratégie implique soit de sauvegarder ces sources de données, soit d'avoir la capacité de reproduire des données provenant d'autres sources. En cas de perte de données, la stratégie mise en place permet la récupération ou la reproduction des données dans les RPO et RTO définis.
**Phase de maturité du cloud :** Foundational
**Anti-modèles courants :**
+ Ne pas connaître toutes les sources de données pour la charge de travail ni leur ordre d'importance.
+ Ne pas effectuer de sauvegardes des sources de données critiques.
+ Sauvegarder uniquement certaines sources de données sans utiliser leur ordre d'importance comme critère.
+ Aucun RPO défini, ou la fréquence de sauvegarde ne parvient pas à atteindre le RPO.
+ Ne pas évaluer si une sauvegarde est nécessaire ou si les données peuvent être reproduites à partir d'autres sources.
**Avantages liés au respect de cette bonne pratique :** Identifier les emplacements où les sauvegardes sont nécessaires et mettre en place un mécanisme pour créer des sauvegardes, ou être capable de reproduire les données à partir d'une source externe améliore la capacité de restauration et de récupération des données lors d'une panne.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
Identifiez et utilisez les fonctionnalités de sauvegarde des services et ressources AWS utilisés par votre charge de travail. La plupart des services AWS offrent des fonctionnalités permettant de sauvegarder vos données de charge de travail.
**Étapes d'implémentation :**
1. **Identifiez toutes les sources de données pour la charge de travail**. Les données peuvent être stockées sur un certain nombre de ressources ( [gérées](https://aws.amazon.com/products/databases/), [volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [systèmes de fichiers](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [systèmes de journalisation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)et [stockage d'objets)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). Reportez-vous à **Ressources** pour trouver **des documents connexes** sur les différents services AWS où les données sont stockées, et la fonctionnalité de sauvegarde que ces services fournissent.
1. **Classez les sources de données en fonction de leur ordre d'importance**. Différents jeux de données ont différents niveaux d'importance pour une charge de travail, et donc différentes exigences en matière de résilience. Par exemple, certaines données peuvent être critiques et nécessiter un RPO proche de zéro, tandis que d'autres données peuvent être moins critiques et peuvent tolérer un RPO plus élevé et la perte de certaines données. De même, différents jeu de données peuvent également avoir des exigences de RTO différentes.
1. **Utilisez AWS ou des services tiers pour créer des sauvegardes des données**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) est un service géré qui permet de créer des sauvegardes de diverses sources de données sur AWS. La plupart de ces services ont également des fonctionnalités natives permettant de créer des sauvegardes. AWS Marketplace inclut de nombreuses solutions qui offrent également ces fonctionnalités. Reportez-vous à **Ressources** ci-dessous pour découvrir comment créer des sauvegardes de données à partir de divers services AWS.
1. **Pour les données non sauvegardées, définissez un mécanisme de reproduction des données**. Vous pouvez choisir de ne pas sauvegarder les données qui peuvent être reproduites à partir d'autres sources pour diverses raisons. Il peut arriver qu'il soit moins coûteux de reproduire des données à partir de sources en cas de besoin plutôt que de créer une sauvegarde, car le stockage des sauvegardes peut impliquer un coût. Ou peut-être la restauration à partir d'une sauvegarde prend-elle plus de temps que la reproduction des données à partir des sources, ce qui entraîne une violation du RTO. Dans de telles situations, envisagez les avantages et inconvénients de chaque approche et définissez un processus clair sur la façon dont les données peuvent être reproduites à partir de ces sources lorsque la récupération des données est nécessaire. Si vous avez chargé des données depuis Amazon S3 vers un entrepôt de données (comme Amazon Redshift) ou un cluster MapReduce (comme Amazon EMR) pour les analyser, vous disposez d'un exemple de données reproductibles à partir d'autres sources. Tant que les résultats de ces analyses sont stockés quelque part ou reproductibles, vous ne perdrez pas données en cas de défaillance de l'entrepôt de données ou du cluster MapReduce. Parmi les autres exemples reproductibles à partir de sources, figurent les caches (comme Amazon ElastiCache) ou les réplicas en lecture RDS.
1. **Spécifiez un rythme de sauvegarde des données**. La création de sauvegardes de sources de données est un processus périodique, et la fréquence doit dépendre du RPO.
**Niveau d'effort du plan d'implémentation :** Modéré
## Ressources
**Bonnes pratiques associées :**
[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)
**Documents connexes :**
+ [Qu'est-ce que AWS Backup ?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Qu'est-ce qu'AWS DataSync ?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Qu'est-ce que la passerelle de volume ?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [Partenaire APN : partenaires pouvant faciliter la sauvegarde](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace : produits pouvant être utilisés pour la sauvegarde](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Instantanés Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Sauvegarde d'Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Sauvegarde d'Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [Sauvegarde et restauration d'ElastiCache pour Redis](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Création d'un instantané de cluster de base de données dans Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [Création d'un instantané de bases de données](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [Création d'une règle EventBridge qui se déclenche selon un calendrier](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Réplication entre régions](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) avec Amazon S3
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Exportation de données de journal vers Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Gestion du cycle de vie des objets](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [Sauvegarde et restauration à la demande pour DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [Restauration à un instant dans le passé pour DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Utilisation des instantanés d'index Amazon OpenSearch Service](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**Vidéos connexes :**
+ [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup Demo: Cross-Account and Cross-Region Backup](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Exemples connexes :**
+ [Atelier Well-Architected : implémentation de la réplication bidirectionnelle entre régions pour Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Atelier Well-Architected : test de la sauvegarde et de la restauration de données](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Atelier Well-Architected : sauvegarde et restauration avec basculement automatique pour la charge de travail d'analyse](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Atelier Well-Architected : reprise après sinistre -sauvegarde et restauration](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 Sécuriser et chiffrer les sauvegardes
Contrôlez et détectez l'accès aux sauvegardes à l'aide de l'authentification et de l'autorisation, telles qu'AWS IAM. Assurez la prévention et détectez si l'intégrité des données des sauvegardes est compromise à l'aide du chiffrement.
Amazon S3 prend en charge plusieurs méthodes de chiffrement de vos données inactives. Grâce au chiffrement côté serveur, Amazon S3 accepte vos objets sous forme de données non chiffrées, puis les chiffre lors de leur stockage. Avec le chiffrement côté client, votre application de charge de travail s'occupe du chiffrement des données avant leur transmission à Amazon S3. Ces deux méthodes vous permettent d'utiliser AWS Key Management Service (AWS KMS) pour créer et stocker la clé de données. Vous pouvez également fournir votre propre clé (vous en assumez alors la responsabilité). Avec AWS KMS, vous pouvez définir des stratégies via IAM pour déterminer qui peut ou non accéder à vos clés de données et à vos données déchiffrées.
Pour Amazon RDS, si vous avez choisi de chiffrer vos bases de données, vos sauvegardes sont également chiffrées. Les sauvegardes DynamoDB sont toujours chiffrées.
**Anti-modèles courants :**
+ Avoir le même accès aux sauvegardes et à l'automatisation de la restauration que vous le faites pour les données.
+ Absence de chiffrement de vos sauvegardes.
**Avantages liés au respect de cette bonne pratique :** La sécurisation de vos sauvegardes empêche la falsification des données. De même, le chiffrement des données empêche l'accès à ces données si elles sont accidentellement exposées.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Utilisez le chiffrement sur chacun de vos magasins de données. La sauvegarde est également chiffrée si vos données sources le sont.
+ Activez le chiffrement dans RDS. Vous pouvez configurer le chiffrement au repos à l'aide d'AWS Key Management Service lorsque vous créez une instance RDS.
+ [Chiffrement des ressources Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ Activez le chiffrement sur les volumes EBS. Vous pouvez configurer le chiffrement par défaut ou spécifier une clé unique lors de la création du volume.
+ [Chiffrement Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ Utilisez le chiffrement Amazon DynamoDB requis. DynamoDB chiffre toutes les données au repos. Vous pouvez utiliser une clé AWS KMS détenue par AWS ou une clé KMS gérée par AWS, en spécifiant une clé stockée dans votre compte.
+ [Chiffrement DynamoDB au repos](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Gestion des tables chiffrées](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Chiffrez vos données stockées dans Amazon EFS. Configurez le chiffrement lorsque vous créez votre système de fichiers.
+ [Chiffrement des données et métadonnées dans EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ Configurez le chiffrement dans les régions source et de destination. Vous pouvez configurer le chiffrement au repos dans Amazon S3 à l'aide de clés stockées dans KMS, mais les clés sont spécifiques à la région. Vous pouvez spécifier les clés de destination lorsque vous configurez la réplication.
+ [Configuration supplémentaire de la réplication entre régions : réplication d'objets créés avec le chiffrement côté serveur (SSE) à l'aide de clés de chiffrement stockées dans AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ Mettez en œuvre les autorisations de moindre privilège pour accéder à vos sauvegardes. Suivez les bonnes pratiques pour limiter l'accès aux sauvegardes, instantanés et réplicas conformément aux bonnes pratiques de sécurité.
+ [Pilier Sécurité : AWS Well-Architected](./wat.pillar.security.en.html)
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits pouvant être utilisés pour la sauvegarde](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Chiffrement Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3 : protection des données à l'aide du chiffrement](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [Configuration supplémentaire de la réplication entre régions : réplication d'objets créés avec le chiffrement côté serveur (SSE) à l'aide de clés de chiffrement stockées dans AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [Chiffrement DynamoDB au repos](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Chiffrement des ressources Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Chiffrement des données et métadonnées dans EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Chiffrement des sauvegardes dans AWS](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [Gestion des tables chiffrées](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [Pilier Sécurité : AWS Well-Architected](./wat.pillar.security.en.html)
**Exemples connexes :**
+ [Atelier Well-Architected : implémentation de la réplication bidirectionnelle entre régions pour Amazon S3](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 Effectuer automatiquement la sauvegarde des données
Configurez les sauvegardes à effectuer automatiquement en fonction d'un calendrier périodique informé par l'objectif de point de récupération (RPO) ou par les modifications du jeu de données. Les jeux de données critiques dont le seuil de tolérance pour la perte de données est faible doivent être sauvegardés automatiquement et fréquemment, tandis que les données moins critiques où certaines données peuvent être perdues peuvent être sauvegardées moins fréquemment.
AWS Backup peut être utilisé pour créer des sauvegardes de données automatisées de diverses sources de données AWS. Les instances Amazon RDS peuvent être sauvegardées presque en continu toutes les cinq minutes, et les objets Amazon S3 peuvent être sauvegardés presque en continu toutes les quinze minutes, ce qui permet une récupération ponctuelle (PITR) dans l'historique de sauvegarde. Pour les autres sources de données AWS, telles que les volumes Amazon EBS, les tables Amazon DynamoDB ou les systèmes de fichiers Amazon FSx, AWS Backup peut exécuter une sauvegarde automatique qui peut avoir lieu toutes les heures. Ces services offrent également des fonctionnalités de sauvegarde natives. Les services AWS qui assurent une sauvegarde automatisée avec une récupération ponctuelle incluent [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)et [Amazon Keyspaces (pour Apache Cassandra)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) – La restauration peut avoir lieu à un moment précis dans l'historique de sauvegarde. La plupart des autres services de stockage de données AWS offrent la possibilité de planifier des sauvegardes périodiques, à une fréquence de sauvegarde pouvant atteindre toutes les heures.
Amazon RDS et Amazon DynamoDB offrent une sauvegarde continue avec une restauration ponctuelle. La gestion des versions Amazon S3, une fois activée, est automatique. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) peut être utilisé pour automatiser la création, la copie et la suppression des instantanés Amazon EBS. Il peut également automatiser la création, la copie, l'abandon et le désenregistrement des Amazon Machine Images (AMI) basées sur Amazon EBS et de leurs instantanés Amazon EBS sous-jacents.
AWS Backup fournit une solution de sauvegarde entièrement gérée basée sur des stratégies afin d'offrir une vue centralisée de l'automatisation et de l'historique de vos sauvegardes. Cette solution centralise et automatise la sauvegarde des données sur plusieurs services AWS dans le cloud et sur site à l'aide d'AWS Storage Gateway.
Outre la gestion des versions, Amazon S3 intègre la réplication. L'intégralité du compartiment S3 peut être automatiquement répliquée vers un autre compartiment d'une autre Région AWS.
**Résultat souhaité :**
Un processus automatisé qui crée des sauvegardes de sources de données à une cadence établie.
**Anti-modèles courants :**
+ Exécution manuelle des sauvegardes
+ Utilisation de ressources qui ont une capacité de sauvegarde, mais sans inclure la sauvegarde dans votre automatisation.
**Avantages liés au respect de cette bonne pratique :** L'automatisation des sauvegardes garantit qu'elles sont effectuées régulièrement en fonction de votre RPO et vous alerte dans le cas contraire.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
1. **Identifiez les sources de données** qui sont actuellement sauvegardées manuellement. Reportez-vous à [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 obtenir des conseils à ce sujet.
1. **Déterminez le RPO** de la charge de travail. Reportez-vous à [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) pour obtenir des conseils à ce sujet.
1. **Utilisez une solution de sauvegarde automatisée ou un service géré**. AWS Backup est un service entièrement géré qui facilite la [centralisation et l'automatisation de la protection des données sur les services AWS, dans le cloud et sur site](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). Les plans de sauvegarde sont une fonctionnalité AWS Backup qui permet la création de règles définissant les ressources à sauvegarder et la fréquence à laquelle ces sauvegardes doivent être créées. Cette fréquence doit être informée par le RPO établi à l'étape 2. [Cet atelier WA](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) fournit des conseils pratiques sur la façon de créer des sauvegardes automatisées avec AWS Backup. Les fonctionnalités de sauvegarde natives sont offertes par la plupart des services AWS qui stockent des données. Par exemple, RDS peut être exploité pour les sauvegardes automatisées avec une récupération ponctuelle (PITR).
1. **Pour les sources de données non prises en charge** par une solution de sauvegarde automatisée ou un service géré tel que des sources de données sur site ou des files d'attente de messages, envisagez d'utiliser une solution tierce de confiance pour créer des sauvegardes automatisées. Vous pouvez également créer une automatisation pour ce faire avec AWS CLI ou les kits SDK. Vous pouvez utiliser les fonctions AWS Lambda ou AWS Step Functions pour définir la logique impliquée dans la création d'une sauvegarde de données, et exploiter Amazon EventBridge pour l'exécuter à une fréquence basée sur votre RPO (comme établi à l'étape 2).
**Niveau d'effort du plan d'implémentation :** Faible
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant faciliter la sauvegarde](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace : produits pouvant être utilisés pour la sauvegarde](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Création d'une règle EventBridge qui se déclenche selon un calendrier](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Qu'est-ce que AWS Backup ?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Qu'est-ce qu'AWS Step Functions ?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**Vidéos connexes :**
+ [AWS re:Invent 2019: Deep dive on AWS Backup, ft. Rackspace (STG341)](https://youtu.be/av8DpL0uFjc)
**Exemples connexes :**
+ [Atelier Well-Architected : test de la sauvegarde et de la restauration de données](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 Effectuer une récupération périodique des données pour vérifier l'intégrité et les processus de sauvegarde
Confirmez que l'implémentation de votre processus de sauvegarde répond à vos objectifs de délai de reprise (RTO) et à vos objectifs de point de reprise (RPO) en effectuant un test de récupération.
Avec AWS, vous pouvez mettre en place un environnement de test et restaurer vos sauvegardes afin d'évaluer le RTO et le RPO, et exécuter des tests sur le contenu et l'intégrité des données.
De plus, Amazon RDS et Amazon DynamoDB permettent une restauration à un instant donné dans le passé (PITR). Grâce à la sauvegarde continue, vous pouvez restaurer votre jeu de données à l'état dans lequel il était à une date et une heure spécifiées.
**Résultat souhaité :** Les données des sauvegardes sont périodiquement récupérées à l'aide de mécanismes bien définis pour garantir que la récupération est conforme à l'objectif de temps de récupération (RTO) établi pour la charge de travail. Vérifiez que la restauration à partir d'une sauvegarde aboutit à une ressource qui contient les données d'origine sans qu'aucune d'entre elles ne soit corrompue ou inaccessible, et avec une perte de données conforme à l'objectif de point de récupération (RPO).
**Anti-modèles courants :**
+ Restauration d'une sauvegarde, mais sans interroger ou récupérer des données pour garantir l'utilisation de la restauration
+ Supposer qu'une sauvegarde existe.
+ Supposer que la sauvegarde d'un système est pleinement opérationnelle et que les données peuvent être récupérées à partir de celle-ci.
+ Supposer que le temps de restauration ou de récupération des données à partir d'une sauvegarde est conforme au RTO de la charge de travail.
+ Supposer que les données contenues dans la sauvegarde sont conformes au RPO de la charge de travail.
+ Effectuer une restauration ad hoc, sans utiliser de runbook ou en dehors d'une procédure automatisée établie.
**Avantages liés au respect de cette bonne pratique :** Le test de la récupération des sauvegardes garantit que les données peuvent être restaurées en cas de besoin sans craindre qu'elles soient manquantes ou corrompues, que la restauration et la récupération sont possibles conformément au RTO de la charge de travail et que toute perte de données est conforme au RPO de la charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
Tester la fonctionnalité de sauvegarde et de restauration permet de garantir que ces actions peuvent être effectuées pendant une panne. Restaurez périodiquement les sauvegardes vers un nouvel emplacement et exécutez des tests pour vérifier l'intégrité des données. Certains tests courants à réaliser vérifient
si toutes les données sont disponibles, si elles ne sont pas corrompues, si elles sont accessibles et si toute perte de données est conforme au RPO de la charge de travail. Ces tests peuvent également contribuer à déterminer si les mécanismes de récupération sont suffisamment rapides pour s'adapter au RTO de la charge de travail.
1. **Identifiez les sources de données** qui sont actuellement sauvegardées et où ces sauvegardes sont stockées. Reportez-vous à [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 sur la mise en œuvre.
1. **Définissez des critères de validation des données** pour chaque source de données. Différents types de données ont des propriétés différentes qui pourraient nécessiter des mécanismes de validation distincts. Réfléchissez à la manière dont ces données pourraient être validées avant de vous assurer que vous pouvez les utiliser en production. Certaines méthodes courantes de validation des données consistent à utiliser des propriétés de données et de sauvegarde telles que le type de données, le format, la somme de contrôle, la taille ou une combinaison de ces propriétés avec une logique de validation personnalisée. Par exemple, il peut s'agir d'une comparaison des valeurs de somme de contrôle entre la ressource restaurée et la source de données au moment de la création de la sauvegarde.
1. **Définissez le RTO et le RPO** de sorte à restaurer les données en fonction de l'ordre d'importance des données. Reportez-vous à [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) pour en savoir plus sur la mise en œuvre.
1. **Évaluez votre capacité de récupération**. Passez en revue votre stratégie de sauvegarde et de restauration pour déterminer si elle peut répondre au RTO et au RPO, et ajustez la stratégie si nécessaire. Avec le [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html), vous pouvez exécuter une évaluation de votre charge de travail. Celle-ci se concentre sur la configuration de votre application par rapport à la stratégie de résilience et signale si vos objectifs RTO et RPO peuvent être atteints.
1. **Effectuez un test de restauration** avec les processus établis utilisés en production pour la restauration des données. Ces processus dépendent de la façon dont la source de données d'origine a été sauvegardée, du format et de l'emplacement de stockage de la sauvegarde elle-même, ou ils varient selon que les données sont reproduites à partir d'autres sources. Par exemple, si vous utilisez un service géré comme [AWS Backup, il peut suffire de restaurer la sauvegarde dans une nouvelle ressource](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). Si vous avez utilisé AWS Elastic Disaster Recovery, vous pouvez [lancer une opération de récupération](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **Validez la récupération des données** à partir de la ressource restaurée (de l'étape précédente) en fonction des critères que vous avez précédemment établis pour la validation des données à l'étape 2. Les données restaurées et récupérées contiennent-elles l'enregistrement/l'élément le plus récent au moment de la sauvegarde ? Ces données sont-elles conformes au RPO de la charge de travail ?
1. **Mesurez le temps nécessaire** à la restauration et la récupération et comparez-le au RTO établi précédemment à l'étape 3. Ce processus est-il conforme au RTO de la charge de travail ? Par exemple, comparez les horodatages du début du processus de restauration et de la fin de la validation de la récupération pour calculer la durée de ce processus. Tous les appels d'API AWS sont horodatés, et ces informations sont disponibles dans [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Bien que ces informations puissent fournir des détails sur le début du processus de restauration, l'horodatage indiquant la fin de la validation doit être enregistré par votre logique de validation. Si vous utilisez un processus automatisé, des services comme [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) peuvent être utilisés pour stocker ces informations. En outre, de nombreux services AWS fournissent un historique des événements qui contient des informations horodatées indiquant quand certaines actions se sont produites. Dans AWS Backup, les actions de sauvegarde et de restauration sont appelées *Postes*, et ces tâches contiennent des informations d'horodatage dans le cadre de leurs métadonnées qui peuvent être utilisées pour mesurer le temps nécessaire à la restauration et à la récupération.
1. **Informez les parties prenantes** si la validation des données échoue ou si le temps requis pour la restauration et la récupération dépasse le RTO établi pour la charge de travail. Lors de la mise en œuvre de l'automatisation de ce processus, [comme dans cet atelier](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/), des services comme Amazon Simple Notification Service (Amazon SNS) peuvent être utilisés pour envoyer des notifications push telles que des e-mails ou des SMS aux parties prenantes. [Ces messages peuvent également être publiés sur des applications de messagerie telles qu'Amazon Chime, Slack ou Microsoft Teams,](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) ou être utilisés pour [créer des tâches en tant qu'OpsItems à l'aide d'AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **Automatisez ce processus pour qu'il s'exécute périodiquement**. Par exemple, des services comme AWS Lambda ou une machine d'état dans AWS Step Functions peuvent être utilisés pour automatiser les processus de restauration et de récupération, et Amazon EventBridge peut être utilisé pour déclencher périodiquement ce flux de travail d'automatisation, comme indiqué dans le diagramme d'architecture ci-dessous. Découvrez comment [automatiser la validation de la récupération des données avec AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/). En outre, [cet atelier Well-Architected](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) apporte une expérience pratique sur une façon d'automatiser plusieurs des étapes indiquées ici.
![\[Diagramme illustrant un processus de sauvegarde et de restauration automatisé\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**Niveau d'effort du plan d'implémentation :** Modéré à élevé selon la complexité des critères de validation.
## Ressources
**Documents connexes :**
+ [automatiser la validation de la récupération des données avec AWS Backup](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [Partenaire APN : partenaires pouvant faciliter la sauvegarde](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace : produits pouvant être utilisés pour la sauvegarde](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Création d'une règle EventBridge qui se déclenche selon un calendrier](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [Sauvegarde et restauration à la demande pour DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [Qu'est-ce que AWS Backup ?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Qu'est-ce qu'AWS Step Functions ?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Qu'est-ce qu'AWS Elastic Disaster Recovery ?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**Exemples connexes :**
+ [Atelier Well-Architected : test de la sauvegarde et de la restauration de données](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL 10 Comment utiliser l'isolation des pannes pour protéger votre charge de travail ?
Les limites isolées pour les défaillances limitent l'effet d'une défaillance au sein d'une charge de travail à un nombre limité de composants. Les composants en dehors de la limite ne sont pas affectés par la défaillance. En utilisant plusieurs limites isolées par défaut, vous pouvez limiter l'impact sur votre charge de travail.
**Topics**
+ [REL10-BP01 Déployer la charge de travail sur plusieurs emplacements](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Sélectionner les emplacements appropriés pour votre déploiement multisite](rel_fault_isolation_select_location.md)
+ [REL10-BP03 Automatiser la récupération pour les composants limités à un seul emplacement](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 Utiliser des architectures cloisonnées pour limiter la portée de l'impact](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Déployer la charge de travail sur plusieurs emplacements
Distribuez les données et les ressources de charge de travail sur plusieurs zones de disponibilité ou, si nécessaire, entre Régions AWS. Ces emplacements peuvent être aussi variés que nécessaire.
L'un des principes fondamentaux de la conception de services dans AWS est d'éviter les points de défaillance uniques dans l'infrastructure physique sous-jacente. Cela nous motive à développer des logiciels et des systèmes qui utilisent plusieurs zones de disponibilité et sont résilients à la défaillance d'une seule zone. De la même manière, les systèmes sont conçus pour être résilients à la défaillance d'un seul nœud de calcul, d'un seul volume de stockage ou d'une seule instance de base de données. Lors de la création d'un système qui s'appuie sur des composants redondants, il est important de s'assurer que les composants fonctionnent de manière indépendante et, dans le cas de Régions AWS, de façon autonome. Les avantages obtenus grâce aux calculs de disponibilité théoriques avec des composants redondants ne sont valides qu’à cette condition.
**Zones de disponibilité (AZ)**
Les Régions AWS sont composées de plusieurs zones de disponibilité, toutes conçues pour être indépendantes les unes des autres. Chaque zone de disponibilité est séparée par une distance physique logique des autres zones afin d'éviter les scénarios de défaillance corrélées liés à des risques environnementaux comme les incendies, les inondations et les tornades. Chaque zone de disponibilité comporte également une infrastructure physique indépendante : connexions dédiées à l'alimentation, sources d'énergie d'appoint indépendantes, services mécaniques indépendants et connectivité réseau indépendante dans et au-delà de la zone de disponibilité. Ce modèle limite les défaillances susceptibles de se produire dans l'un de ces systèmes à la seule zone de disponibilité affectée. Bien que géographiquement séparées, les zones de disponibilité sont situées dans la même zone régionale, ce qui permet une mise en réseau à haut débit et à faible latence. L'intégralité de la Région AWS (dans toutes les zones de disponibilité, composées de plusieurs centres de données physiquement indépendants) peut être traitée comme une cible de déploiement logique unique pour votre charge de travail, y compris pour répliquer les données de manière synchrone (par exemple, entre les bases de données). Cela vous permet d'utiliser les zones de disponibilité dans une configuration active/active ou active/veille.
Les zones de disponibilité sont indépendantes et, par conséquent, la disponibilité de la charge de travail est augmentée lorsque la charge de travail est conçue pour utiliser plusieurs zones. Certains services AWS (y compris le plan de données d'instance Amazon EC2) sont déployés en tant que services strictement locaux où leur sort dépend de la zone de disponibilité dans laquelle ils se trouvent. Cependant, les instances Amazon EC2 dans les autres AZ ne sont pas affectées et continuent à fonctionner . De même, si une défaillance dans une zone de disponibilité entraîne l'échec d'une base de données Amazon Aurora, une instance de réplica en lecture Aurora dans une AZ non affectée peut être automatiquement promue comme instance principale. D'autre part, les services régionaux AWS, comme Amazon DynamoDB, utilisent en interne plusieurs zones de disponibilité dans une configuration active/active pour atteindre les objectifs de conception de disponibilité de ce service, sans que vous ayez besoin de configurer le placement AZ.
![\[Diagramme illustrant l'architecture multiniveau déployée sur trois zones de disponibilité. Notez qu'Amazon S3 et Amazon DynamoDB comportent toujours automatiquement plusieurs zones de disponibilité. L'ELB est également déployé dans les trois zones.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
Bien que les plans de contrôle AWSoffrent généralement la possibilité de gérer les ressources sur l'ensemble de la région (plusieurs zones de disponibilité), certains plans de contrôle (y compris Amazon EC2 et Amazon EBS) ont la capacité de filtrer les résultats en une seule zone de disponibilité. Lorsque c'est le cas, la requête est traitée uniquement dans la zone de disponibilité spécifiée, ce qui réduit l'exposition aux perturbations dans les autres zones de disponibilité. Cet exemple AWS CLI illustre l'obtention d'informations sur l'instance Amazon EC2 uniquement à partir de la zone de disponibilité us-east-2c :
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS Local Zones*
Les AWS Local Zones agissent de la même manière que les zones de disponibilité au sein de leur Région AWS respective, car elles sont sélectionnables en tant qu'emplacement de placement des ressources AWS de la zone comme les sous-réseaux et les instances EC2. Elles sont spéciales, car elles ne sont pas situées dans la Région AWS associée, mais près de grands centres de population, industriels et informatiques où aucune Région AWS n'existe actuellement. Cependant, elles conservent une connexion sécurisée et à bande passante élevée entre les charges de travail locales dans la zone locale et celles exécutées dans la Région AWS. Utilise les AWS Local Zones pour déployer des charges de travail plus près de vos utilisateurs afin de répondre aux exigences de faible latence.
**Réseau périphérique mondial d'Amazon**
Le réseau périphérique mondial d'Amazon se compose d'emplacements périphériques dans des villes du monde entier. Amazon CloudFront utilise ce réseau pour fournir du contenu aux utilisateurs finaux avec une latence plus faible. AWS Global Accelerator vous permet de créer vos points de terminaison de charge de travail dans ces emplacements périphériques pour assurer l'intégration au réseau mondial AWS à proximité de vos utilisateurs. Amazon API Gateway active les points de terminaison d'API optimisés en périphérie à l'aide d'une distribution CloudFront pour faciliter l'accès client via l'emplacement périphérique le plus proche.
*Régions AWS*
Les Régions AWS sont conçues pour être autonomes. Par conséquent, pour utiliser une approche multirégion, vous devez déployer des copies dédiées des services dans chaque région.
Une approche multirégion est courante pour que *les stratégies de reprise après sinistre* atteignent les objectifs de récupération lorsque des événements ponctuels à grande échelle se produisent. Consulter [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) pour en savoir plus sur ces stratégies. Ici cependant, nous nous concentrons plutôt sur la *disponibilité*, qui vise à atteindre un objectif de disponibilité moyenne dans le temps. Pour des objectifs de haute disponibilité, une architecture multirégion est généralement conçue pour être active/active, où chaque copie de service (dans ses régions respectives) est active (en répondant aux requêtes).
**Recommandations**
Les objectifs de disponibilité pour la plupart des charges de travail peuvent être satisfaits à l'aide d'une stratégie multi-AZ dans une seule Région AWS. Envisagez les architectures multirégion uniquement lorsque les charges de travail ont des exigences de disponibilité extrêmes ou en cas d'autres objectifs commerciaux nécessitant une architecture multirégion.
AWS vous offre la possibilité de gérer des services entre régions. Par exemple, AWS fournit une réplication continue et asynchrone des données via la réplication Amazon Simple Storage Service (Amazon S3), les réplicas en lecture Amazon RDS (y compris les réplicas en lecture Aurora) et les tables globales Amazon DynamoDB. Grâce à la réplication continue, des versions de vos données sont disponibles pour une utilisation quasi immédiate dans chacune de vos régions actives.
Avec AWS CloudFormation, vous pouvez définir votre infrastructure et la déployer de manière cohérente sur les Comptes AWS et dans les Régions AWS. AWS CloudFormation StackSets étend cette fonctionnalité en vous permettant de créer, mettre à jour ou supprimer des piles AWS CloudFormation sur plusieurs comptes et régions en une seule opération. Pour les déploiements d'instance Amazon EC2, une AMI (Amazon Machine Image) est utilisée pour fournir des informations telles que la configuration matérielle et les logiciels installés. Vous pouvez implémenter un pipeline Amazon EC2 Image Builder qui crée les AMI dont vous avez besoin et les copie dans vos régions actives. Cela garantit que ces *AMI approuvées* disposent de tout ce dont vous avez besoin pour déployer et faire évoluer votre charge de travail dans chaque nouvelle région.
Pour acheminer le trafic, Amazon Route 53 et AWS Global Accelerator permettent la définition de politiques qui déterminent quels utilisateurs accèdent à quel point de terminaison régional actif. Avec Global Accelerator, vous définissez une option de trafic pour contrôler le pourcentage de trafic dirigé vers chaque point de terminaison d'application. Route 53 prend en charge cette approche de pourcentage, ainsi que plusieurs autres politiques disponibles, notamment celles basées sur la géoproximité et la latence. Global Accelerator exploite automatiquement le vaste réseau de serveurs périphériques AWS pour intégrer le trafic à la dorsale du réseau AWS dès que possible, ce qui réduit la latence des demandes.
L'ensemble de ces fonctionnalités opèrent de manière à préserver l'autonomie de chaque région. Il existe quelques rares exceptions à cette approche, y compris nos services qui fonctionnent en périphérie au niveau mondial (comme Amazon CloudFront et Amazon Route 53), ainsi que le plan de contrôle pour le service Gestion des identités et des accès AWS (IAM) La plupart des services fonctionnent entièrement au sein d'une seule région.
**Centre de données sur site**
Pour les charges de travail exécutées dans un centre de données sur site, concevez une expérience hybride dans la mesure du possible. AWS Direct Connect fournit une connexion réseau dédiée entre vos locaux et AWS, ce qui vous permet d'utiliser les deux.
Une autre option consiste à exécuter l'infrastructure et les services AWS sur site à l'aide d' AWS Outposts. AWS Outposts est un service entièrement géré qui étend l'infrastructure AWS, les services AWS, les API et les outils à votre centre de données. La même infrastructure matérielle utilisée dans le AWS Cloud est installée dans votre centre de données. Les services AWS Outposts sont alors connectés à la Région AWS la plus proche. Vous pouvez ensuite utiliser les services AWS Outposts pour prendre en charge vos charges de travail à faible latence ou vos exigences en matière de traitement des données locales.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Utilisez plusieurs zones de disponibilité et Régions AWS. Distribuez les données et les ressources de charge de travail sur plusieurs zones de disponibilité ou, si nécessaire, entre Régions AWS. Ces emplacements peuvent être aussi variés que nécessaire.
+ Les services régionaux sont, par nature, déployés entre les zones de disponibilité.
+ Cela inclut Amazon S3, Amazon DynamoDB et AWS Lambda (lorsqu'ils ne sont pas connectés à un VPC).
+ Déployez votre conteneur, votre instance et vos charges de travail basées sur des fonctions dans plusieurs zones de disponibilité. Utilisez les magasins de données multi-AZ, y compris les caches. Utilisez les fonctionnalités d'EC2 Auto Scaling, le placement de tâches ECS, la configuration de fonctions AWS Lambda lors de l'exécution de votre VPC et les clusters ElastiCache.
+ Utilisez les sous-réseaux situés dans des zones de disponibilité distinctes lorsque vous déployez des groupes Auto Scaling.
+ [Exemple : Distribution d'instances dans des zones de disponibilité](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Stratégies de placement des tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Configuration d'une fonction AWS Lambda pour accéder aux ressources dans un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [Choix des régions et des zones de disponibilité](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Utilisez des sous-réseaux situés dans des zones de disponibilité distinctes lorsque vous déployez des groupes Auto Scaling.
+ [Exemple : Distribution d'instances dans des zones de disponibilité](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ Utilisez les paramètres de placement des tâches ECS, en spécifiant des groupes de sous-réseaux de base de données.
+ [Stratégies de placement des tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Utilisez des sous-réseaux dans plusieurs zones de disponibilité lorsque vous configurez une fonction à exécuter dans votre VPC.
+ [Configuration d'une fonction AWS Lambda pour accéder aux ressources dans un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ Utilisez plusieurs zones de disponibilité avec des clusters ElastiCache.
+ [Choix des régions et des zones de disponibilité](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Choisissez une stratégie sur plusieurs régions si votre charge de travail doit être déployée dans plusieurs régions. La plupart des besoins de fiabilité peuvent être satisfaits au sein d'une même Région AWS à l'aide d'une stratégie à plusieurs zones de disponibilité. Utilisez une stratégie sur plusieurs régions si nécessaire pour répondre aux besoins de votre entreprise.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ La sauvegarde dans une autre Région AWS peut donner des garanties supplémentaires que les données seront disponibles en cas de besoin.
+ Il existe, pour certaines charges de travail, des exigences réglementaires qui imposent l'utilisation d'une stratégie sur plusieurs régions.
+ Évaluez AWS Outposts pour votre charge de travail. Si votre charge de travail nécessite une faible latence de connexion à votre centre de données sur site ou si elle a des exigences locales en matière de traitement des données, Exécutez ensuite l'infrastructure et les services AWS sur site à l'aide d'AWS Outposts.
+ [Qu'est-ce qu'AWS Outposts ?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ Déterminez si AWS Local Zones vous permet de fournir un service à vos utilisateurs. Si vous avez des exigences de faible latence, vérifiez si AWS Local Zones est situé près de vos utilisateurs. Si oui, utilisez-le pour déployer des charges de travail plus près de ces utilisateurs.
+ [FAQ sur AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## Ressources
**Documents connexes :**
+ [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [FAQ sur AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Stratégies de placement des tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Choix des régions et des zones de disponibilité](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [Exemple : Distribution d'instances dans des zones de disponibilité](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Tables globales : réplication multirégions avec DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Utilisation des bases de données mondiales Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [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/)
+ [Qu'est-ce qu'AWS Outposts ?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.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: Innovation and operation of the AWS global network infrastructure (NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Sélectionner les emplacements appropriés pour votre déploiement multisite
## Résultat souhaité
Pour une haute disponibilité, déployez toujours (si possible) vos composants de charge de travail sur plusieurs zones de disponibilité (AZ), comme illustré à la figure 10. Pour les charges de travail avec des exigences de résilience extrêmes, évaluez soigneusement les options pour une architecture multirégion.
![\[Diagramme illustrant un déploiement de base de données multi-AZ résilient avec sauvegarde vers une autre région AWS\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## Anti-modèles courants
+ Choisir de concevoir une architecture multirégion alors qu'une architecture multi-AZ répond aux exigences.
+ Ne pas tenir compte des dépendances entre les composants de l'application si les exigences en matière de résilience et d'emplacements multiples diffèrent entre ces composants.
## Avantages liés au respect de cette bonne pratique :
Pour la résilience, vous devez adopter une approche qui repose sur des couches de défense. Une couche protège contre les perturbations de petite envergure et courantes en créant une architecture hautement disponible à l'aide de plusieurs AZ. Une autre couche de défense est destinée à protéger contre les événements rares tels que les catastrophes naturelles généralisées et les perturbations au niveau régional. Cette deuxième couche implique de concevoir l'architecture de votre application pour qu'elle s'étende sur plusieurs Régions AWS.
+ La différence entre une disponibilité de 99,5 % et une disponibilité de 99,99 % est de plus de 3,5 heures par mois. La disponibilité attendue d'une charge de travail ne peut atteindre les « quatre neuf » que si elle se trouve dans plusieurs zones de disponibilité.
+ En exécutant votre charge de travail dans plusieurs AZ, vous pouvez isoler les pannes d'alimentation, de refroidissement et de mise en réseau, ainsi que la plupart des catastrophes naturelles telles que les incendies et les inondations.
+ La mise en œuvre d'une stratégie multirégion pour votre charge de travail permet de la protéger contre les catastrophes naturelles généralisées qui affectent une grande région géographique d'un pays, ou les défaillances techniques à l'échelle régionale. Sachez que la mise en œuvre d'une architecture multirégion peut être très complexe et n'est généralement pas requise pour la plupart des charges de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
Dans le cas d'une catastrophe basée sur l'interruption ou la perte partielle d'une zone de disponibilité, la mise en œuvre d'une charge de travail hautement disponible dans plusieurs zones de disponibilité au sein d'une seule Région AWS permet d'atténuer les effets des catastrophes naturelles et techniques. Chaque Région AWS est composé de plusieurs zones de disponibilité, chacune isolée des défaillances des autres zones et séparée par une distance significative. Cependant, dans le cas d'une catastrophe incluant le risque de perdre plusieurs composants de la zone de disponibilité (composants qui sont à une distance importante les uns des autres), vous devez implémenter des options de reprise après sinistre pour vous prémunir contre les défaillances à l'échelle de la région. Pour les charges de travail nécessitant une résilience extrême (infrastructure critique, applications liées à la santé, infrastructure du système financier, etc.), une stratégie multirégion peut être nécessaire.
## Étapes d'implémentation
1. Évaluez votre charge de travail et déterminez si les besoins de résilience peuvent être satisfaits par une approche multi-AZ (Région AWS unique) ou s'ils nécessitent une approche multirégion. La mise en œuvre d'une architecture multirégion pour répondre à ces exigences ajoute de la complexité. Par conséquent, examinez attentivement votre cas d'utilisation et ses exigences. Les exigences de résilience peuvent presque toujours être satisfaites avec une seule Région AWS. Tenez compte des exigences possibles suivantes lorsque vous déterminez si vous devez utiliser plusieurs régions :
1. **Reprise après sinistre** : dans le cas d'une catastrophe basée sur l'interruption ou la perte partielle d'une zone de disponibilité, la mise en œuvre d'une charge de travail hautement disponible dans plusieurs zones de disponibilité au sein d'une seule Région AWS permet d'atténuer les effets des catastrophes naturelles et techniques. Dans le cas d'une catastrophe incluant le risque de perdre plusieurs composants de la zone de disponibilité (composants qui sont à une distance importante les uns des autres), vous devez implémenter des options de reprise après sinistre entre plusieurs régions pour vous prémunir contre les catastrophes naturelles et les incidents techniques à l'échelle de la région.
1. **Haute disponibilité** : une architecture multirégion (utilisant plusieurs AZ dans chaque région) peut être utilisée pour atteindre une disponibilité supérieure à quatre 9 (> 99,99 %).
1. **Localisation des piles** : lors du déploiement d'une charge de travail auprès d'une audience mondiale, vous pouvez déployer des piles localisées dans différentes Régions AWS pour répondre aux besoins des audiences dans ces régions. La localisation peut inclure la langue, la devise et les types de données stockées.
1. **Proximité avec les utilisateurs :** lors du déploiement d'une charge de travail auprès d'une audience mondiale, vous pouvez réduire la latence en déployant des piles dans les Régions AWS à proximité de l'endroit où se trouvent les utilisateurs finaux.
1. **Résidence des données** : certaines charges de travail sont soumises à des exigences en matière de situation géographique des données, où les données de certains utilisateurs doivent rester à l'intérieur des frontières d'un pays spécifique. En fonction de la réglementation en question, vous pouvez choisir de déployer une pile entière, ou uniquement les données, dans la Région AWS au sein de ces frontières.
1. Voici quelques exemples de fonctionnalités multi-AZ fournies par les services AWS :
1. Pour protéger les charges de travail à l'aide d'EC2 ou d'ECS, déployez un Elastic Load Balancer devant les ressources de calcul. Elastic Load Balancing fournira ensuite la solution pour détecter les instances dans les zones non saines et acheminer le trafic vers les zones qui le sont.
1. [Démarrer avec Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Démarrer avec les Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. Dans le cas d'instances EC2 exécutant des logiciels commerciaux prêts à l'emploi qui ne prennent pas en charge l'équilibrage de charge, vous pouvez bénéficier d'une forme de tolérance aux pannes via la mise en œuvre d'une méthodologie de reprise après sinistre multi-AZ.
1. [REL13-BP02 Utiliser des stratégies de reprise définies pour répondre aux objectifs de reprise](rel_planning_for_recovery_disaster_recovery.md)
1. Pour les tâches Amazon ECS, déployez votre service uniformément sur trois AZ pour atteindre un juste équilibre entre disponibilité et coût.
1. [Bonnes pratiques de disponibilité Amazon ECS \$1 Conteneurs](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Pour les tâches qui n'entrent pas dans le cadre d'Aurora Amazon RDS, vous pouvez choisir Multi-AZ comme option de configuration. En cas de défaillance de l'instance de base de données principale, Amazon RDS promeut automatiquement une base de données de secours pour recevoir le trafic dans une autre zone de disponibilité. Des réplicas en lecture multirégion peuvent également être créés pour améliorer la résilience.
1. [Déploiements multi-AZ Amazon RDS](https://aws.amazon.com/rds/features/multi-az/)
1. [Création d'un réplica en lecture dans une autre Région AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. Voici quelques exemples de fonctionnalités multirégions fournies par les services AWS :
1. Pour les charges de travail Amazon S3, où la disponibilité multi-AZ est fournie automatiquement par le service, envisagez des points d'accès multirégions si un déploiement multirégion est nécessaire.
1. [Points d'accès multirégions dans Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. Pour les tables DynamoDB, où la disponibilité multi-AZ est fournie automatiquement par le service, vous pouvez facilement convertir les tables existantes en tables globales pour tirer parti de plusieurs régions.
1. [Convertir vos tables Amazon DynamoDB à région unique en tables globales](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. Si votre charge de travail repose sur des Application Load Balancers ou des Network Load Balancers, utilisez AWS Global Accelerator pour améliorer la disponibilité de votre application en dirigeant le trafic vers plusieurs régions qui contiennent des points de terminaison sains.
1. [Points de terminaison pour les accélérateurs standards dans AWS Global Accelerator - AWS Global Accelerator (amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. Pour les applications qui tirent parti d'AWS EventBridge, envisagez des bus interrégionaux pour transférer les événements vers d'autres régions que vous sélectionnez.
1. [Envoi et réception d'événements Amazon EventBridge entre les Régions AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Pour les bases de données Amazon Aurora, considérez les bases de données globales Aurora, qui couvrent plusieurs régions AWS. Les clusters existants peuvent également être modifiés pour ajouter de nouvelles régions.
1. [Premiers pas avec les avec les bases de données globales Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. Si votre charge de travail comprend des clés de chiffrement AWS Key Management Service (AWS KMS), déterminez si les clés multirégions sont appropriées pour votre application.
1. [Clés multirégions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. Pour d'autres fonctionnalités de service AWS, 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/)
**Niveau d'effort du plan d'implémentation : **De Modéré à Élevé
## Ressources
**Documents connexes :**
+ [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/)
+ [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/)
+ [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [FAQ sur AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Architecture de reprise après sinistre (DR) sur AWS, première partie : stratégies de reprise dans le cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [La reprise après sinistre est différente dans le cloud](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [Tables globales : réplication multirégions avec DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0 : architecture à haute disponibilité sur plusieurs régions pouvant atteindre plus de 1,5 milliard de connexions par mois avec basculement automatique](https://www.youtube.com/watch?v=vGywoYc_sA8)
**Exemples connexes :**
+ [Architecture de reprise après sinistre (DR) sur AWS, première partie : stratégies de reprise dans le cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC atteint une résilience bien supérieure à ce qu'elle peut obtenir sur site](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group utilise une architecture reposant sur plusieurs zones de disponibilité et plusieurs régions avec un service DNS propriétaire pour renforcer la résilience des applications](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber : reprise après sinistre pour une plateforme Kafka sur plusieurs régions](https://eng.uber.com/kafka/)
+ [Netflix : stratégie active-active pour une résilience sur plusieurs régions](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Comment nous créons la résidence des données pour le cloud Atlassian](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax fonctionne sur deux régions](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 Automatiser la récupération pour les composants limités à un seul emplacement
Si les composants de la charge de travail ne peuvent s'exécuter que dans une seule zone de disponibilité ou un centre de données sur site, vous devez implémenter la capacité permettant d'effectuer une reconstruction complète de la charge de travail dans le cadre de vos objectifs de récupération définis.
Si la bonne pratique de déploiement de la charge de travail sur plusieurs emplacements n'est pas possible en raison de contraintes technologiques, vous devez implémenter une autre solution de résilience. Vous devez automatiser la possibilité de recréer l'infrastructure nécessaire, de redéployer les applications et de recréer les données nécessaires pour ces situations.
Par exemple, Amazon EMR lance tous les nœuds d'un cluster donné dans la même zone de disponibilité, car l'exécution d'un cluster dans la même zone améliore les performances des flux de travail en fournissant un taux d'accès aux données plus élevé. Si ce composant est requis pour la résilience de la charge de travail, vous devez pouvoir redéployer le cluster et ses données. De même, pour Amazon EMR, vous devez assurer la redondance autrement qu'en utilisant plusieurs zones de disponibilité. Vous pouvez allouer [plusieurs nœuds](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). Avec le [système de fichiers EMR (EMRFS)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html), les données EMR peuvent être conservées dans Amazon S3 et ainsi être répliquées sur plusieurs zones de disponibilité ou Régions AWS.
De même, Amazon Redshift met en service, par défaut, votre cluster dans une zone de disponibilité sélectionnée de façon aléatoire au sein de la Région AWS que vous sélectionnez. Tous les nœuds de cluster sont mis en service dans la même zone.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Implémentation de l'autorégénération Dans la mesure du possible, déployez vos instances ou vos conteneurs en utilisant la scalabilité automatique. Si vous ne pouvez pas utiliser la scalabilité automatique, utilisez la récupération automatique pour les instances EC2 ou mettez en place un mécanisme d'autoréparation basé sur Amazon EC2 ou des événements de cycle de vie de conteneur ECS.
+ Utilisez les groupes Auto Scaling pour les instances et les charges de travail de conteneur qui n'ont aucune exigence en matière d'adresse IP d'instance, d'adresse IP privée, d'adresse IP élastique et de métadonnées d'instance.
+ [Qu'est-ce que EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Scalabilité automatique des services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ Les données utilisateur de la configuration de lancement peuvent être utilisées pour mettre en place un mécanisme permettant la récupération automatique de la plupart des charges de travail.
+ Utilisez la récupération automatique des instances EC2 pour les charges de travail nécessitant une seule adresse d'ID d'instance, une seule adresse IP privée, une seule adresse IP élastique, et des métadonnées d'instance.
+ [Récupérer votre instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ La récupération automatique envoie des alertes de statut de récupération à une rubrique SNS lorsque la défaillance de l'instance est détectée.
+ Utilisez les événements du cycle de vie de l'instance EC2 ou les événements ECS pour automatiser l'autoréparation lorsque la scalabilité automatique ou la récupération de votre instance EC2 ne peuvent pas être utilisées.
+ [Hooks de cycle de vie EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Événements Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ Utilisez les événements pour appeler le mécanisme vous permettant de réparer votre composant selon la logique de processus dont vous avez besoin.
## Ressources
**Documents connexes :**
+ [Événements Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Hooks de cycle de vie EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Récupérer votre instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Scalabilité automatique des services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Qu'est-ce que EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 Utiliser des architectures cloisonnées pour limiter la portée de l'impact
À l'instar des cloisons d'un navire, ce modèle garantit qu'une panne reste limitée à un petit sous-ensemble de requêtes ou de clients afin que le nombre de requêtes compromises soit limité et que la plupart puissent continuer sans erreur. Les cloisons des données sont souvent appelées partitions, tandis que les cloisons des services sont appelées cellules.
Dans une *architecture cellulaire,*chaque cellule est une instance complète et indépendante du service et a une taille maximale fixe. Les charges de travail augmentent en même temps que la charge par l'ajout de cellules. Une clé de partition est utilisée sur le trafic entrant pour déterminer la cellule qui traitera la requête. Toute défaillance est contenue dans la seule cellule dans laquelle elle se produit, de sorte que le nombre de requêtes compromises soit limité et que les autres puissent continuer sans erreur. Il est important de choisir la bonne clé de partition afin de minimiser les interactions entre cellules et d'éviter d'avoir à utiliser des services de mappage complexes pour chaque requête. Les services qui nécessitent un mappage complexe ne font finalement que déplacer le problème vers les services de mappage, tandis que les services qui nécessitent des interactions entre cellules créent des dépendances entre les cellules (et, par conséquent, réduisent les améliorations de disponibilité présumées qui en découlent).
![\[Diagramme illustrant une architecture cellulaire\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Dans son billet de blog AWS, Colm MacCarthaigh explique comment Amazon Route 53 utilise le concept de [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) pour isoler les demandes des clients en partitions. Dans ce cas, une partition se compose d’au moins deux cellules. En fonction de la clé de partition, le trafic d'un client (ou des ressources, ou tout ce que vous souhaitez isoler) est acheminé vers la partition qui lui est attribuée. Par exemple, avec huit cellules et deux cellules par partition et des clients répartis entre les quatre partitions, 25 % des clients subiraient un impact en cas de problème.
![\[Diagramme illustrant un service divisé en partitions traditionnelles\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
Avec le partitionnement aléatoire, vous créez des partitions virtuelles de deux cellules chacune et attribuez vos clients à l'une de ces partitions virtuelles. Lorsqu'un problème se produit, vous pouvez toujours perdre un quart de l'ensemble du service, mais la façon dont les clients ou les ressources sont attribués signifie que la portée de l'impact du partitionnement aléatoire est considérablement inférieure à 25 %. Avec huit cellules, il existe 28 combinaisons uniques de deux cellules, soit 28 partitions aléatoires possibles (partitions virtuelles). Si vous avez des centaines ou des milliers de clients et que vous assignez chaque client à une partition aléatoire, l'impact lié à un problème est seulement de 1/28e. C'est sept fois mieux que le partitionnement standard.
![\[Diagramme illustrant un service divisé en partitions aléatoires.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
Une partition peut être utilisée pour les serveurs, les files d'attente ou d'autres ressources en plus des cellules.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Utilisez des architectures cloisonnées. À l'instar des cloisons d'un navire, ce modèle garantit qu'une panne reste limitée à un petit sous-ensemble de requêtes ou d'utilisateurs afin que le nombre de requêtes compromises soit limité et que la plupart puissent continuer sans erreur. Les cloisons des données sont souvent appelées partitions, tandis que les cloisons des services sont appelées cellules.
+ [Atelier Well-Architected : Isolement des pannes avec le partitionnement aléatoire](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ Évaluez l'architecture basée sur les cellules pour votre charge de travail. Dans une architecture basée sur les cellules, chaque cellule est une instance complète et indépendante du service et a une taille maximale fixe. Les charges de travail augmentent en même temps que la charge par l'ajout de cellules. Une clé de partition est utilisée sur le trafic entrant pour déterminer la cellule qui traitera la requête. Toute défaillance est contenue dans la seule cellule dans laquelle elle se produit, de sorte que le nombre de requêtes compromises soit limité et que les autres puissent continuer sans erreur. Il est important de choisir la bonne clé de partition afin de minimiser les interactions entre cellules et d'éviter d'avoir à utiliser des services de mappage complexes pour chaque requête. Les services qui nécessitent un mappage complexe ne font finalement que déplacer le problème vers les services de mappage, tandis que les services qui nécessitent des interactions entre cellules réduisent l'autonomie des cellules (et, par conséquent, les améliorations de disponibilité présumées qui en découlent).
+ Dans son billet de blog AWS, Colm MacCarthaigh explique comment Amazon Route 53 utilise le concept de partitionnement aléatoire pour isoler les demandes des clients dans des partitions
+ [Partitionnement aléatoire : Isolement massif et magique des pannes](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## Ressources
**Documents connexes :**
+ [Partitionnement aléatoire : Isolement massif et magique des pannes](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [L'Amazon Builders' Library : isolement de la charge de travail à l'aide du partitionnement aléatoire](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**Vidéos connexes :**
+ [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20)
+ [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**Exemples connexes :**
+ [Atelier Well-Architected : Isolement des pannes avec le partitionnement aléatoire](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
# REL 11 Comment concevoir votre charge de travail pour la rendre résistante aux défaillances de composants ?
Les charges de travail exigeant une haute disponibilité et un faible temps moyen de récupération (MTTR) doivent être conçues pour être résilientes.
**Topics**
+ [REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Basculer vers des ressources saines](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatiser la réparation sur toutes les couches](rel_withstand_component_failures_auto_healing_system.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)
+ [REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Envoyer des notifications lorsque des événements affectent la disponibilité](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Surveiller tous les composants de la charge de travail pour détecter les défaillances
Surveillez en continu l'état de votre charge de travail afin que vous et vos systèmes automatisés ayez connaissance de la dégradation ou de la défaillance dès qu'elle se produit. Surveillez les indicateurs de performance clés (KPI) en fonction de la valeur commerciale.
Tous les mécanismes de récupération et de réparation doivent commencer par la capacité à détecter rapidement les problèmes. Les défaillances techniques doivent être détectées au préalable pour être résolues. Cependant, la disponibilité repose sur la capacité de votre charge de travail à fournir une valeur commerciale. Il doit donc s'agir d'indicateurs clés de performance (KPI) de votre stratégie de détection et de correction.
**Anti-modèles courants :**
+ Aucune alarme n'a été configurée. Il n'y a donc pas de notification lorsque des interruptions se produisent.
+ Des alarmes existent, mais les seuils ne laissent pas assez de temps pour réagir.
+ Les métriques ne sont pas collectées à une fréquence suffisante pour atteindre l'objectif de délai de reprise (RTO).
+ Seul le niveau client de la charge de travail est surveillé activement.
+ Collecte uniquement des métriques techniques et non des métriques de fonction commerciale.
+ Aucune métrique ne mesure l'expérience utilisateur de la charge de travail.
**Avantages liés au respect de cette bonne pratique :** La surveillance appropriée à toutes les couches vous permet de réduire le temps de récupération en réduisant le temps de détection.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Déterminez l'intervalle de collecte de vos composants en fonction de vos objectifs de récupération.
+ Votre intervalle de surveillance dépend de la vitesse à laquelle vous devez effectuer la récupération. Votre délai de reprise dépend du temps nécessaire à la récupération. Vous devez donc déterminer la fréquence de collecte en tenant compte de cette durée et de votre objectif de délai de reprise (RTO).
+ Configurez la surveillance détaillée des composants.
+ Déterminez la nécessité d'une surveillance détaillée pour les instances EC2 et Auto Scaling La surveillance détaillée fournit des métriques à intervalle d'une minute, et la surveillance par défaut fournit des métriques à intervalle de 5 minutes.
+ [Activer ou désactiver la surveillance détaillée pour votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Surveillance de vos groupes et instances Auto Scaling à l'aide d'Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Déterminez la nécessité de la surveillance améliorée pour RDS. La surveillance améliorée utilise un agent sur les instances RDS pour obtenir des informations utiles sur différents processus ou threads sur une instance RDS.
+ [Enhanced Monitoring (Surveillance améliorée)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Créez des métriques personnalisées pour mesurer les indicateurs clés de performance (KPI) métier. Les charges de travail implémentent des fonctions métier clés. Ces fonctions doivent être utilisées comme des KPI permettant d'identifier la survenue d'un problème indirect.
+ [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Surveillez l'expérience utilisateur pour détecter les défaillances à l'aide de tests canary utilisateur. Les tests de transaction synthétiques (également appelés « tests canary », à ne pas confondre avec les déploiements canary) qui peuvent exécuter et simuler le comportement des clients font partie des processus de test les plus importants. Exécutez ces tests en permanence sur vos points de terminaison de charge de travail à partir de divers emplacements distants.
+ [Amazon CloudWatch Synthetics vous permet de créer des tests canary utilisateur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Créez des métriques personnalisées qui suivent l'expérience utilisateur. Si vous pouvez analyser l'expérience du client, vous pouvez savoir à quel moment l'expérience du consommateur se dégrade.
+ [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Définissez des alarmes pour détecter quand une partie de votre charge de travail ne fonctionne pas correctement et pour indiquer quand mettre à l'échelle automatiquement les ressources. Les alarmes peuvent être des signaux visuels sur les tableaux de bord ou des alertes via Amazon SNS ou e-mail et utiliser la mise à l'échelle automatique pour augmenter ou diminuer les ressources pour une charge de travail.
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Créez des tableaux de bord pour la visualisation de vos métriques. Les tableaux de bord peuvent être utilisés pour afficher visuellement des tendances, des valeurs aberrantes et d'autres indicateurs de problèmes potentiels, ou pour fournir une indication des problèmes que vous pourriez vouloir examiner.
+ [Fonctionnement des tableaux de bord CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Ressources
**Documents connexes :**
+ [Amazon CloudWatch Synthetics vous permet de créer des tests canary utilisateur](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Activer ou désactiver la surveillance détaillée pour votre instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring (Surveillance améliorée)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Surveillance de vos groupes et instances Auto Scaling à l'aide d'Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Fonctionnement des tableaux de bord CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : implémentation de la surveillance de l'état et gestion des dépendances pour améliorer la fiabilité](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Basculer vers des ressources saines
Vérifiez que les ressources saines peuvent continuer à traiter les demandes en cas de défaillance d’une ressource. Pour les défaillances liées à l'emplacement (par exemple, zone de disponibilité ou Région AWS), vérifiez que vous disposez de systèmes en place pour basculer vers des ressources saines dans des emplacements intacts.
Les services AWS tels qu'Elastic Load Balancing et AWS Auto Scaling contribuent à répartir la charge entre les ressources et les zones de disponibilité. Par conséquent, la défaillance d'une ressource individuelle (telle qu'une instance EC2) ou la dégradation d'une zone de disponibilité peut être atténuée en déplaçant le trafic vers les ressources saines restantes. La situation est beaucoup plus compliquée quand il s'agit de charges de travail distribuées sur plusieurs régions. À titre d'exemple, les réplicas en lecture entre régions vous permettent de déployer vos données dans plusieurs Régions AWS. Cependant, vous devez toujours promouvoir le réplica en lecture en tant que réplica principal et orienter votre trafic vers celui-ci en cas de défaillance de basculement. Amazon Route 53 et AWS Global Accelerator contribuent à acheminer le trafic entre les Régions AWS.
Si votre charge de travail utilise des services AWS, comme Amazon S3 ou Amazon DynamoDB, ils sont automatiquement déployés sur plusieurs zones de disponibilité. En cas de défaillance, le plan de contrôle AWS s'occupe de l'acheminement automatique du trafic vers des emplacements sains. Les données sont stockées de manière redondante dans plusieurs zones de disponibilité et restent disponibles. Pour Amazon RDS, vous devez choisir Multi-AZ comme option de configuration, puis en cas de panne, AWS dirige automatiquement le trafic vers l'instance saine. Pour les instances Amazon EC2, les tâches Amazon ECS ou les pods Amazon EKS, vous choisissez les zones de disponibilité du déploiement. Elastic Load Balancing fournit ensuite la solution pour détecter les instances dans les zones non saines et acheminer le trafic vers les zones saines. Elastic Load Balancing peut même acheminer le trafic vers les composants de votre centre de données sur site.
Pour les approches multirégions (qui peuvent également inclure des centres de données sur site), Amazon Route 53 permet de définir des domaines Internet et d'attribuer des stratégies de routage qui peuvent inclure des vérifications de l'état afin de s'assurer que le trafic est acheminé vers des régions saines. AWS Global Accelerator fournit également des adresses IP statiques qui font office de points d'entrée fixe dans votre application avant un acheminement vers les points de terminaison des Régions AWS de votre choix via le réseau mondial AWS au lieu d'Internet pour optimiser les performances et la fiabilité.
AWS aborde la conception de nos services en ayant à l'esprit la récupération en cas de panne. Nous concevons les services afin de minimiser le temps de restauration en cas de défaillance et l'impact sur les données. Nos services utilisent principalement des magasins de données qui valident les requêtes uniquement lorsque les données sont stockées durablement sur plusieurs réplicas au sein d'une région. Ces services et ressources incluent Amazon Aurora, Amazon Relational Database Service (Amazon RDS), les instances de base de données multi-AZ, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) et Amazon Elastic File System (Amazon EFS). Ils sont élaborés de manière à utiliser l'isolation basée sur les cellules et à faire appel à l'isolement des pannes fourni par des zones de disponibilité. Nous utilisons largement l'automatisation dans nos procédures opérationnelles. Nous optimisons également notre fonction de remplacement et redémarrage afin de récupérer rapidement en cas d'interruptions.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Basculez vers des ressources saines. Vérifiez que les ressources saines peuvent continuer à traiter les demandes en cas de défaillance d’une ressource. Pour les défaillances liées à l'emplacement (par exemple, zone de disponibilité ou Région AWS), vérifiez que vous disposez de systèmes en place pour basculer vers des ressources saines dans des emplacements intacts.
+ Si votre charge de travail utilise des services AWS, comme Amazon S3 ou Amazon DynamoDB, ils sont automatiquement déployés sur plusieurs zones de disponibilité. En cas de défaillance, le plan de contrôle AWS s'occupe de l'acheminement automatique du trafic vers des emplacements sains.
+ Pour Amazon RDS, vous devez choisir Multi-AZ comme option de configuration, puis en cas de panne, AWS dirige automatiquement le trafic vers l'instance saine.
+ [Haute disponibilité (Multi-AZ) pour Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Pour les instances Amazon EC2 ou les tâches Amazon ECS, vous choisissez les zones de disponibilité du déploiement. Elastic Load Balancing fournit ensuite la solution pour détecter les instances dans les zones défectueuses et acheminer le trafic vers les zones saines. Elastic Load Balancing peut même acheminer le trafic vers les composants de votre centre de données sur site.
+ Pour les approches multi-régions (qui peuvent également inclure des centres de données sur site), assurez-vous que les données et les ressources provenant d'emplacements sains peuvent continuer à traiter les demandes.
+ À titre d'exemple, les réplicas en lecture entre régions vous permettent de déployer vos données dans plusieurs Régions AWS. Cependant, vous devez toujours faire du réplica en lecture le réplica principal et orienter votre trafic vers celui-ci en cas de défaillance de l'emplacement principal.
+ [Présentation des réplicas en lecture Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 permet de définir des domaines Internet et d'attribuer des politiques de routage, pouvant inclure des surveillances de l'état, afin de s'assurer que le trafic est acheminé vers des régions saines. AWS Global Accelerator fournit également des adresses IP statiques qui font office de points d'entrée fixe dans votre application avant un acheminement vers les points de terminaison des Régions AWS de votre choix via le réseau mondial AWS au lieu de l'Internet public pour optimiser les performances et la fiabilité.
+ [Amazon Route 53 : choix d'une stratégie de routage](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Qu'est-ce qu'AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à automatiser votre tolérance aux pannes](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace : produits pouvant être utilisés pour la tolérance aux pannes](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks : utilisation de la réparation automatique pour remplacer des instances défectueuses](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53 : choix d'une stratégie de routage](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Haute disponibilité (Multi-AZ) pour Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Présentation des réplicas en lecture Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Stratégies de placement des tâches Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Création de groupes Kubernetes Auto Scaling pour plusieurs zones de disponibilité](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Qu'est-ce qu'AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : implémentation de la surveillance de l'état et gestion des dépendances pour améliorer la fiabilité](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatiser la réparation sur toutes les couches
Utilisez des capacités automatisées pour effectuer des actions correctives en cas de détection d'une défaillance.
*La possibilité d'exécuter un redémarrage* est un outil important pour corriger les pannes. Comme indiqué précédemment pour les systèmes distribués, une bonne pratique consiste à supprimer, dans la mesure du possible, l’état des services. Cela évite la perte de données ou de disponibilité au redémarrage. Dans le cloud, vous pouvez (et devriez généralement) remplacer la totalité de la ressource (par exemple, une instance EC2 ou une fonction Lambda) dans le cadre du redémarrage. Le redémarrage proprement dit est un moyen simple et fiable de récupération après une défaillance. De nombreux types de défaillances différents se produisent dans les charges de travail. Les défaillances peuvent se produire au niveau du matériel, des logiciels, des communications et des opérations. Plutôt que de créer de nouveaux mécanismes pour piéger, identifier et corriger chacun des différents types de défaillances, mappez de nombreuses catégories de défaillances différentes à la même stratégie de récupération. Une instance peut cesser de fonctionner suite à une panne matérielle, à un bogue du système d'exploitation ou à une fuite de mémoire. D’autres causes sont néanmoins possibles. Plutôt que de créer une correction personnalisée pour chaque situation, traitez l'une d'entre elles comme une défaillance d'instance. Résiliez l'instance et autorisez AWS Auto Scaling à la remplacer. Effectuez ensuite une analyse de cette ressource défaillante hors bande.
Un autre exemple est la possibilité de redémarrer une requête réseau. Appliquez la même approche de récupération à la fois pour un délai d'expiration réseau et une défaillance de la dépendance, si la dépendance renvoie une erreur. Comme ces deux événements ont un effet semblable sur le système, plutôt que d'essayer de traiter l'un ou l'autre événement comme un « cas particulier », appliquez une stratégie semblable de nouvelle tentative limitée avec une temporisation exponentielle et une instabilité.
*La possibilité d'exécuter un redémarrage* est un mécanisme de récupération présenté dans les architectures de cluster haute disponibilité et d'informatique orientée récupération.
Amazon EventBridge peut être utilisé pour surveiller et filtrer les événements tels que les alarmes CloudWatch ou les changements d'état dans d'autres services AWS. En fonction des informations d'événement, il peut ensuite déclencher AWS Lambda, AWS Systems Manager Automation (ou d'autres cibles) pour exécuter une logique de correction personnalisée sur votre charge de travail.
Amazon EC2 Auto Scaling peut être configuré pour vérifier l'état de l'instance EC2. Si l'instance est dans un état autre que celui en cours d'exécution, ou si le statut du système est dégradé, Amazon EC2 Auto Scaling considère l'instance comme défectueuse et lance une instance de remplacement. Si vous utilisez AWS OpsWorks, vous pouvez configurer la réparation automatique des instances EC2 au niveau de la couche OpsWorks.
Pour les remplacements à grande échelle (comme la perte d'une zone de disponibilité complète), il est préférable d'opter pour la stabilité statique pour une haute disponibilité plutôt que d'essayer d'obtenir plusieurs nouvelles ressources simultanément.
**Anti-modèles courants :**
+ Déploiement d'applications une par une dans des instances ou des conteneurs.
+ Déploiement d'applications qui ne peuvent pas être déployées dans plusieurs emplacements sans utiliser la récupération automatique.
+ Réparation manuelle des applications impossible à réparer par la scalabilité et la récupération automatiques.
**Avantages liés au respect de cette bonne pratique :** La réparation automatique réduit le temps moyen de récupération et garantit la disponibilité de la charge de travail même si la charge de travail ne peut être déployée qu'à un seul emplacement à la fois.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Utilisez des groupes Auto Scaling pour déployer des niveaux dans une charge de travail. La scalabilité automatique peut effectuer une autoréparation sur les applications sans état et ajouter ou supprimer de la capacité.
+ [Fonctionnement d'AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implémentez la récupération automatique sur les instances EC2 dont les applications déployées ne peuvent pas être déployées dans plusieurs emplacements et qui peuvent tolérer le redémarrage en cas de défaillance. La récupération automatique peut être utilisée pour remplacer du matériel défaillant et redémarrer l'instance lorsque l'application ne peut pas être déployée sur plusieurs emplacements. Les métadonnées de l'instance et les adresses IP associées sont conservées, tout comme le sont les volumes Amazon EBS et les points de montage sur Elastic File Systems ou sur File Systems for Lustre et Windows.
+ [Récupération automatique Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Qu'est-ce qu'Amazon FSx for Lustre ?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Qu'est-ce qu'Amazon FSx for Windows File Server ?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Avec AWS OpsWorks, vous pouvez configurer la réparation automatique des instances EC2 au niveau de la couche.
+ [AWS OpsWorks : utilisation de la réparation automatique pour remplacer des instances défectueuses](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implémentez la récupération automatique à l'aide d'AWS Step Functions et d'AWS Lambda lorsque vous ne pouvez pas utiliser la mise à l'échelle automatique ou la récupération automatique, ou lorsque la récupération automatique échoue. Lorsque vous ne pouvez pas utiliser la scalabilité automatique, que vous ne pouvez pas utiliser la récupération automatique ou que la récupération automatique échoue, vous pouvez automatiser la réparation à l'aide d'AWS Step Functions et d'AWS Lambda.
+ [Qu'est-ce qu'AWS Step Functions ?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Qu'est-ce qu'AWS Lambda ?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge peut être utilisé pour surveiller et filtrer les événements tels que les alarmes CloudWatch ou les changements d'état dans d'autres services AWS. En fonction des informations d'événement, il peut ensuite déclencher AWS Lambda (ou d'autres cibles) pour exécuter une logique de correction personnalisée sur votre charge de travail.
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à automatiser votre tolérance aux pannes](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace : produits pouvant être utilisés pour la tolérance aux pannes](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks : utilisation de la réparation automatique pour remplacer des instances défectueuses](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Récupération automatique Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Fonctionnement d'AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce qu'AWS Lambda ?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Qu'est-ce qu'AWS Step Functions ?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Qu'est-ce qu'Amazon FSx for Lustre ?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Qu'est-ce qu'Amazon FSx for Windows File Server ?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Vidéos connexes :**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : implémentation de la surveillance de l'état et gestion des dépendances pour améliorer la fiabilité](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 S'appuyer sur le plan de données et non sur le plan de contrôle pendant la récupération
Le plan de contrôle est utilisé pour configurer les ressources et le plan de données fournit les services. Les plans de données ont généralement des objectifs de conception de disponibilité plus élevés que les plans de contrôle et sont généralement moins complexes. Lors de la mise en œuvre de réponses de récupération ou d'atténuation à des événements susceptibles d'avoir un impact sur la résilience, l'utilisation des opérations du plan de contrôle peut réduire la résilience globale de votre architecture. Par exemple, vous pouvez compter sur le plan de données Amazon Route 53 pour acheminer de manière fiable les requêtes DNS en fonction des contrôles de l'état, mais la mise à jour des politiques de routage Route 53 utilise le plan de contrôle. Ne comptez donc pas sur lui pour la récupération.
Les plans de données Route 53 répondent aux requêtes DNS et effectuent et évaluent les vérifications de l'état. Ils sont distribués dans le monde entier et conçus pour un [accord de niveau de service (SLA) de 100 % de disponibilité.](https://aws.amazon.com/route53/sla/) Les API et consoles de gestion Route 53 dans lesquelles vous créez, mettez à jour et supprimez des ressources Route 53 s'exécutent sur des plans de contrôle conçus pour donner la priorité à la cohérence forte et à la durabilité dont vous avez besoin lors de la gestion du DNS. Pour ce faire, les plans de contrôle sont situés dans une seule région, US East (N. Virginia). Bien que les deux systèmes soient conçus pour être très fiables, les plans de contrôle ne sont pas inclus dans le SLA. Dans de rares cas, la conception résiliente du plan de données permet de maintenir la disponibilité alors que les plans de contrôle ne le font pas. Pour les mécanismes de reprise après sinistre et de basculement, utilisez les fonctions du plan de données pour assurer la meilleure fiabilité possible.
Pour plus d'informations sur les plans de données, les plans de contrôle et la manière dont AWS crée des services pour atteindre les objectifs de haute disponibilité, consultez le livre blanc sur la [stabilité statique avec les zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) et la bibliothèque [Amazon Builders' Library.](https://aws.amazon.com/builders-library/)
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Appuyez-vous sur le plan de données et non sur le plan de contrôle lors de l'utilisation d'Amazon Route 53 pour la reprise après sinistre. 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 de contrôles de 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.
+ [Qu'est-ce que Route 53 Application Recovery Controller ?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Création de mécanismes de reprise après sinistre à l'aide d'Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [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/)
+ [Création d'applications hautement résilientes à l'aide d'Amazon Route 53 Application Recovery Controller, partie 2 : pile multirégion](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Comprendre quelles opérations relèvent du plan de données et quelles opérations relèvent du plan de contrôle
+ [L'Amazon Builders' Library : éviter la surcharge des systèmes distribués en plaçant sous contrôle le plus petit service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (plan de contrôle et plan de données)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Exécutions AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (réparties entre le plan de contrôle et le plan de données)
+ [Exécutions AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (réparties entre le plan de contrôle et le plan de données)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à automatiser votre tolérance aux pannes](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace : produits pouvant être utilisés pour la tolérance aux pannes](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [L'Amazon Builders' Library : éviter la surcharge des systèmes distribués en plaçant sous contrôle le plus petit service](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (plan de contrôle et plan de données)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [Exécutions AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (réparties entre le plan de contrôle et le plan de données)
+ [Plan de données AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [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/)
+ [Création d'applications hautement résilientes à l'aide d'Amazon Route 53 Application Recovery Controller, partie 2 : pile multirégion](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Création de mécanismes de reprise après sinistre à l'aide d'Amazon Route 53](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Qu'est-ce que Route 53 Application Recovery Controller ?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Exemples connexes :**
+ [Qu'est-ce qu'Amazon Route 53 Application Recovery Controller ?](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux
Un comportement bimodal survient lorsque votre charge de travail adopte un comportement différent en mode normal et en mode de défaillance, par exemple, en s'appuyant sur le lancement de nouvelles instances en cas de défaillance d'une zone de disponibilité. Pour éviter ce type de comportement, vous devez créer des charges de travail stables statiquement et qui fonctionnent dans un seul mode. : dans ce cas, mettez en service suffisamment d'instances dans chaque zone de disponibilité pour gérer la charge de travail si une zone de disponibilité venait à être supprimée, puis utilisez les vérifications de l'état d'Elastic Load Balancing ou d'Amazon Route 53 pour déplacer la charge à distance des instances compromises.
La stabilité statique du déploiement de calcul (par exemple, des conteneurs ou des instances EC2) garantit une fiabilité optimale. Celle-ci doit être pondérée par rapport aux problèmes de coût. Il est moins coûteux d'allouer une capacité de calcul inférieure et de compter sur le lancement de nouvelles instances en cas de défaillance. Toutefois, pour les défaillances à grande échelle (par exemple, une défaillance de zone de disponibilité), cette approche est moins efficace, car elle repose sur la réaction aux défaillances à mesure qu'elles se produisent, plutôt que sur la préparation à contrer ces défaillances avant leur occurrence. Votre solution doit évaluer la fiabilité par rapport aux besoins en termes de coûts de votre charge de travail. En augmentant le nombre de zones de disponibilité utilisées, vous réduisez la quantité de calcul supplémentaire dont vous avez besoin pour la stabilité statique.
![\[Diagramme illustrant la stabilité statique des instances EC2 dans les zones de disponibilité\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/static-stability.png)
Une fois le trafic déplacé, utilisez AWS Auto Scaling pour remplacer de manière asynchrone les instances de la zone défaillante et les lancer dans les zones saines.
Autre exemple de comportement bimodal : un délai d'expiration du réseau peut amener un système à tenter d'actualiser l'état de configuration de l'ensemble du système. Cette tentative ajoute une charge inattendue à un autre composant, ce qui peut entraîner un échec et déclencher d'autres conséquences imprévues. Cette boucle de rétroaction négative a un impact sur la disponibilité de votre charge de travail. Vous devriez donc créer des systèmes stables statiquement et fonctionnant dans un seul mode. Une conception statiquement stable consisterait à effectuer un travail constant et à toujours actualiser l'état de la configuration selon une cadence fixe. Lorsqu'un appel échoue, la charge de travail utilise la valeur précédemment mise en cache et déclenche une alarme.
Un autre exemple de comportement bimodal consiste à autoriser les clients à contourner votre cache de charge de travail lorsque des défaillances se produisent. Cette solution peut répondre aux besoins des clients, mais ne doit pas être autorisée, car elle modifie considérablement les demandes sur votre charge de travail et risque d'entraîner des défaillances.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Utilisez la stabilité statique pour éviter les comportements bimodaux. Un comportement bimodal survient lorsque votre charge de travail adopte un comportement différent en mode normal et en mode de défaillance, par exemple, en s'appuyant sur le lancement de nouvelles instances en cas de défaillance d'une zone de disponibilité.
+ [Minimiser les dépendances dans un plan de reprise après sinistre](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [L'Amazon Builders' Library : stabilité statique avec les zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Pour éviter ce type de comportement, vous devez créer des systèmes stables statiquement et qui fonctionnent dans un seul mode. Dans ce cas, allouez suffisamment d'instances dans chaque zone pour gérer la charge de travail en cas de suppression d'une AZ, puis utilisez les vérifications de l'état d'Elastic Load Balancing ou d'Amazon Route 53 pour déplacer la charge des instances dégradées.
+ Un autre exemple de comportement bimodal consiste à autoriser les clients à contourner votre cache de charge de travail lorsque des défaillances se produisent. Quoiqu'elle semble répondre aux besoins des clients, cette solution ne devrait pas être autorisée, car elle modifie considérablement les exigences de votre charge de travail et peut être à l'origine de défaillances.
## Ressources
**Documents connexes :**
+ [Minimiser les dépendances dans un plan de reprise après sinistre](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [L'Amazon Builders' Library : stabilité statique avec les zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Vidéos connexes :**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Envoyer des notifications lorsque des événements affectent la disponibilité
Des notifications sont envoyées lors de la détection d'événements importants, même si le problème provoqué par l'événement a été automatiquement résolu.
La réparation automatique garantit la fiabilité de votre charge de travail. Cependant, elle peut également masquer les problèmes sous-jacents à résoudre. Implémentez une surveillance et des événements appropriés afin de pouvoir détecter les schémas de problèmes, y compris ceux résolus par la réparation automatique, afin de pouvoir résoudre les problèmes de cause racine. Des alarmes Amazon CloudWatch peuvent être déclenchées en fonction des pannes qui se produisent. Elles peuvent également être déclenchées lors de l’exécution d’actions de réparation automatisées. Les alarmes CloudWatch peuvent être configurées pour envoyer des e-mails afin de consigner des incidents dans des systèmes tiers de suivi des incidents à l'aide de l'intégration d'Amazon SNS.
**Anti-modèles courants :**
+ Envoi d'alarmes sur lesquelles personne n'agit.
+ Automatisation de la réparation automatique sans notification indiquant que la réparation était nécessaire.
**Avantages liés au respect de cette bonne pratique :** Les notifications d'événements de récupération vous permettront de ne pas ignorer les problèmes qui se produisent peu fréquemment.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Alarmes au niveau des KPI lorsqu'ils dépassent un seuil bas : avoir une alarme de seuil bas au niveau des KPI de votre entreprise vous aide à déterminer quand votre charge de travail est indisponible ou non fonctionnelle.
+ [Création d’une alarme CloudWatch basée sur un seuil statique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Alarme au niveau des événements qui appellent l'automatisation de la réparation : vous pouvez appeler directement une API SNS pour envoyer des notifications avec n'importe quelle automatisation que vous créez.
+ [Qu'est-ce qu'Amazon Simple Notification Service ?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Ressources
**Documents connexes :**
+ [Création d’une alarme CloudWatch basée sur un seuil statique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce qu'Amazon Simple Notification Service ?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 Comment tester la fiabilité ?
Une fois que vous avez conçu votre charge de travail pour qu'elle soit résiliente aux sollicitations de la production, les tests sont le seul moyen de s'assurer qu'elle fonctionne comme prévu et d'obtenir la résilience voulue.
**Topics**
+ [REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 Effectuer une analyse post-incident](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 Tester les exigences fonctionnelles](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 Tester les exigences de mise à l'échelle et de performance](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 Tester la résilience à l'aide de l'ingénierie du chaos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 Organiser régulièrement des tests de simulation de panne](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 Utiliser des playbooks pour enquêter sur les causes des défaillances
Consignez le processus d'enquête dans des playbooks afin de faciliter l'application de réponses cohérentes et rapides face aux scénarios de défaillance qui ne sont pas bien compris. Les playbooks sont les étapes prédéfinies suivies pour identifier les facteurs adjuvants à un scénario défaillance. Les résultats des étapes du processus sont utilisés pour déterminer les prochaines mesures à prendre jusqu'à ce que la question soit identifiée ou remontée.
Le playbook est une planification proactive que vous devez appliquer afin de pouvoir prendre efficacement des mesures réactives. Lorsque des scénarios de défaillance ne figurant pas dans le playbook sont rencontrés en production, commencez par résoudre le problème (éteindre l’incendie). Procédez ensuite à une rétrospective en examinant les étapes suivies pour résoudre le problème et utilisez-les pour ajouter une nouvelle entrée dans le playbook.
Notez que les playbooks sont utilisés en réponse à des incidents spécifiques, tandis que les runbooks le sont pour obtenir des résultats spécifiques. En règle générale, les runbooks sont employés pour les activités de routine et les playbooks pour répondre à des événements non réguliers.
**Anti-modèles courants :**
+ Planification du déploiement d'une charge de travail sans connaître les processus permettant de diagnostiquer les problèmes ou de répondre aux incidents.
+ Décisions imprévues sur les systèmes à partir desquels peut se faire la collecte des journaux et métriques lors de l'examen d'un événement.
+ Non-conservation des métriques et événements pendant suffisamment longtemps pour pouvoir récupérer les données.
**Avantages liés au respect de cette bonne pratique :** La capture des playbooks garantit que les processus peuvent être suivis de manière cohérente. La codification de vos playbooks limite l'introduction d'erreurs à partir de l'activité manuelle. L'automatisation des playbooks accélère le temps de réponse à un événement en évitant aux membres de l'équipe d’intervenir ou en leur fournissant des informations supplémentaires lorsque leur intervention commence.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Utilisez des playbooks pour identifier les problèmes. Les playbooks sont des processus documentés pour enquêter sur les problèmes. Mettez en œuvre des réponses cohérentes et rapides aux échecs en documentant les processus dans des playbooks. Les playbooks doivent contenir les informations et les instructions nécessaires pour permettre à une personne compétente de recueillir les informations pertinentes, identifier les causes potentielles de défaillance, isoler les pannes et déterminer les facteurs adjuvants (c'est-à-dire effectuer une analyse post-incident).
+ Mettez en œuvre les playbooks en tant que code Effectuez vos opérations en tant que code scriptant vos playbooks afin d'en assurer la cohérence et de limiter les erreurs causées par les processus manuels. Les playbooks peuvent être composés de plusieurs scripts représentant les différentes étapes qui pourraient être nécessaires pour identifier les facteurs contribuant à un problème. Les activités Runbook peuvent être déclenchées ou effectuées dans le cadre d'activités playbook, ou peuvent demander l'exécution d'un playbook en réponse à des événements identifiés.
+ [Automatisez vos playbooks opérationnels avec AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Qu'est-ce qu'AWS Lambda ?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressources
**Documents connexes :**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [Automatisez vos playbooks opérationnels avec AWS Systems Manager](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce qu'AWS Lambda ?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**Exemples connexes :**
+ [Automatisation des opérations avec les playbooks et les runbooks](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 Effectuer une analyse post-incident
Passez en revue les événements ayant un impact sur le client et identifiez les facteurs adjuvants et les mesures préventives. Utilisez ces informations pour prendre des mesures d'atténuation afin de limiter ou de remédier aux problèmes. Développez des procédures pour fournir des réponses rapides et efficaces. Publiez, le cas échéant, les facteurs adjuvants et les mesures correctives adaptées au public ciblé. Vous devez disposer d'une méthode pour communiquer ces causes à d'autres si nécessaire.
Évaluez pourquoi les tests existants n'ont pas permis de résoudre le problème. Ajoutez des tests pour ce cas si aucun test correspondant n’existe.
**Anti-modèles courants :**
+ Trouver des facteurs adjuvants sans pour autant continuer à chercher plus en profondeur d'autres problèmes et approches potentiels pour atténuer les risques.
+ Identification limitée aux causes d'erreur humaine et sans formation ou automatisation pouvant empêcher les erreurs humaines.
**Avantages liés au respect de cette bonne pratique :** Une analyse post-incident et le partage des résultats permettent à d'autres charges de travail d'atténuer les risques si elles ont mis en œuvre les mêmes facteurs adjuvants. Elle permet aussi de mettre en œuvre l'atténuation des risques ou la récupération automatisée avant qu'un incident ne se produise.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Définissez une norme pour votre analyse post-incident. Une bonne analyse post-incident permet de proposer des solutions courantes pour les problèmes avec des modèles d'architecture utilisés dans d'autres compartiments de vos systèmes.
+ Assurez-vous que les facteurs adjuvants sont honnêtes et irréprochables.
+ Vous ne pouvez pas corriger vos problèmes si vous ne les documentez pas.
+ Veillez à ce que l'analyse post-incident soit irréprochable afin que vous puissiez proposer des mesures correctives objectives et promouvoir une auto-évaluation et une collaboration honnête au sein de vos équipes d'application.
+ Utilisez un processus pour déterminer les facteurs adjuvants. Disposez d'un processus pour identifier et documenter les facteurs adjuvants d'un événement, développez des mesures d'atténuation pour limiter ou empêcher sa récurrence, et développez des procédures de réponses rapides et efficaces. Communiquez, le cas échéant, les facteurs adjuvants sur mesure en fonction du public ciblé.
+ [Qu'est-ce que l'analytique des journaux ?](https://aws.amazon.com/log-analytics/)
## Ressources
**Documents connexes :**
+ [Qu'est-ce que l'analytique des journaux ?](https://aws.amazon.com/log-analytics/)
+ [Pourquoi mettre en place la correction des erreurs (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 Tester les exigences fonctionnelles
Utilisez des techniques telles que les tests unitaires et les tests d'intégration qui valident les fonctionnalités requises.
Vous obtenez les meilleurs résultats lorsque ces tests sont exécutés automatiquement dans le cadre d'actions de génération et de déploiement. Par exemple, grâce à AWS CodePipeline, les développeurs valident les modifications apportées à un référentiel source dans lequel CodePipeline détecte automatiquement les modifications. Ces modifications sont générées et des tests sont exécutés. Une fois les tests terminés, le code généré est déployé sur des serveurs intermédiaires à des fins de test. Depuis le serveur intermédiaire, CodePipeline exécute d'autres tests, tels que des tests d'intégration ou de chargement. Une fois ces tests terminés avec succès, CodePipeline déploie le code testé et approuvé sur les instances de production.
De plus, l'expérience montre que les tests de transactions synthétiques (également appelés *tests canary*à ne pas confondre avec les déploiements canary) qui peuvent exécuter et simuler le comportement des clients font partie des processus de test les plus importants. Exécutez ces tests en permanence sur vos points de terminaison de charge de travail à partir de divers emplacements distants. Amazon CloudWatch Synthetics vous permet de [créer des scripts Canari](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) pour surveiller vos points de terminaison et vos API.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Testez les exigences fonctionnelles. Il s'agit, entre autres, des tests unitaires et des tests d'intégration qui valident les fonctionnalités requises.
+ [Utilisez CodePipeline avec AWS CodeBuild pour tester le code et exécuter des générations](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline ajoute la prise en charge des tests unitaires et des tests d'intégration personnalisés avec AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Livraison et intégration continues (CI/CD)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Automatisation des tests logiciels](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant faciliter l'implémentation d'un pipeline d'intégration continue](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline ajoute la prise en charge des tests unitaires et des tests d'intégration personnalisés avec AWS CodeBuild](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace : produits pouvant être utilisés pour une intégration continue](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Livraison et intégration continues (CI/CD)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Automatisation des tests logiciels](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Utilisez CodePipeline avec AWS CodeBuild pour tester le code et exécuter des générations](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 Tester les exigences de mise à l'échelle et de performance
Utilisez des techniques telles que les tests de charge pour valider que la charge de travail répond aux exigences de mise à l'échelle et de performances.
Dans le cloud, vous pouvez créer un environnement de test à la demande à l'échelle de la production pour votre charge de travail. Si vous exécutez ces tests sur une infrastructure réduite, vous devez mettre vos résultats observés à l'échelle en fonction de ce que vous pensez qu'il se produira en production. Les tests de charge et de performances peuvent également être réalisés en production si vous veillez à ne pas affecter les utilisateurs réels et à baliser vos données de test afin qu'elles ne correspondent pas aux données utilisateur réelles et ne corrompent pas les statistiques d'utilisation ni les rapports de production.
Utilisez les tests pour vous assurer que vos ressources de base, vos paramètres de mise à l'échelle, vos quotas de service et votre conception de la résilience fonctionnent comme prévu sous charge.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Testez les exigences de mise à l'échelle et de performance. Effectuez un test de charge pour vérifier que la charge de travail répond aux exigences de mise à l'échelle et de performance.
+ [Test de charge distribuée sur AWS : simulation de milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ Déployez votre application dans un environnement identique à votre environnement de production et effectuez un test de charge.
+ Utilisez les concepts d'Infrastructure as Code pour créer un environnement aussi similaire que possible à votre environnement de production.
## Ressources
**Documents connexes :**
+ [Test de charge distribuée sur AWS : simulation de milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 Tester la résilience à l'aide de l'ingénierie du chaos
Exécutez des expériences de chaos dans des environnements dont les conditions se rapprochent autant que possible de la production pour comprendre comment nos systèmes réagissent à des conditions défavorables.
** Résultat souhaité : **
La résilience de la charge de travail est régulièrement vérifiée en appliquant l'ingénierie du chaos sous la forme d'expériences d'injection de défaillances ou de charge inattendue, en plus des tests de résilience qui confirment le comportement attendu connu de votre charge de travail lors d'un événement. Associez l'ingénierie du chaos aux tests de résilience pour avoir l'assurance que votre charge de travail peut résister en cas de défaillance des composants et récupérer suite à des perturbations inattendues avec peu ou pas d'impact.
** Anti-modèles courants : **
+ Conception à des fins de résilience, mais pas de vérification du fonctionnement de la charge de travail dans son ensemble en cas de défaillances.
+ Pas d'expériences dans des conditions concrètes et pour la charge prévue.
+ Pas de traitement de vos expériences en tant que code ou de maintenance de vos expériences tout au long du cycle de développement.
+ Pas d'exécution d'expériences de chaos dans le cadre de votre pipeline CI/CD, ainsi qu'en dehors des déploiements.
+ Pas d'utilisation des analyses passées post-incident pour déterminer les défaillances à tester.
** Avantages liés au respect de cette bonne pratique :** L'injection de défaillances pour vérifier la résilience de votre charge de travail vous permet d'avoir l'assurance que les procédures de récupération de votre conception résiliente fonctionneront en cas de défaillances réelles.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyen
## Directives d'implémentation
L'ingénierie du chaos offre la possibilité à vos équipes d'injecter en continu des perturbations concrètes (simulations) de manière contrôlée au niveau du fournisseur de services, de l'infrastructure, de la charge de travail et des composants, avec peu ou pas d'impact pour vos clients. Ainsi, vos équipes tirent les leçons de ces défaillances et observent, mesurent et améliorent la résilience de vos charges de travail, tout en confirmant que les alertes se déclenchent et que les équipes sont informées en cas d'événement.
Une pratique de l'ingénierie du chaos en continu peut mettre en évidence des défaillances dans vos charges de travail qui, si elles ne sont pas résolues, peuvent impacter de manière négative la disponibilité et le fonctionnement.
**Note**
L'ingénierie du chaos est la discipline d'expérimentation d'un système. Elle permet de s'assurer de la capacité du système à résister à des conditions de production difficiles. – [Principes de l'ingénierie du chaos](https://principlesofchaos.org/)
Si un système est capable de résister à ces perturbations, l'expérience de chaos doit être maintenue en tant que test de régression automatisé. De cette façon, les expériences de chaos doivent être réalisées dans le cadre de votre cycle de développement des systèmes et de votre pipeline CI/CD.
Pour veiller à ce que votre charge de travail résiste en cas de défaillance des composants, injectez des événements concrets dans le cadre de vos expériences. Par exemple, expérimentez une perte des instances Amazon EC2 ou un basculement de l'instance de base de données Amazon RDS principale, puis vérifiez que votre charge de travail n'est pas impactée (ou très peu). Utilisez plusieurs défaillances des composants pour simuler des événements capables de causer une perturbation dans une zone de disponibilité.
Pour les défaillances de niveau application (telles que les plantages), commencez par des tests de stress comme l'épuisement de la mémoire et du processeur.
Afin de valider les [solutions de secours ou les mécanismes de basculement](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) pour les dépendances externes dues aux pannes réseau intermittentes, vos composants doivent simuler un tel événement en bloquant l'accès aux fournisseurs tiers pendant une durée spécifiée pouvant aller de quelques secondes à plusieurs heures.
D'autres modes de dégradation peuvent entraîner des fonctionnalités limitées et ralentir les réponses, ce qui se traduit par une perturbation de vos services. Généralement, cette dégradation résulte d'une latence accrue sur les services critiques et d'une communication réseau peu fiable (perte de paquets). Les expériences avec ces défaillances, dont les effets de mise en réseau tels que la latence, les messages supprimés et les défaillances DNS, peuvent inclure l'incapacité de résoudre un nom, d'atteindre un service DNS ou de se connecter aux services dépendants.
**Outils de l'ingénierie du chaos :**
AWS Fault Injection Service (AWS FIS) est un service entièrement géré permettant l'exécution d'expériences d'injection de défaillances qui peuvent être utilisées dans le cadre de votre pipeline CD, ou en dehors du pipeline. AWS FIS s'impose donc comme un choix judicieux lors des tests de simulation de pannes. Il prend en charge de manière simultanée l'injection de défaillances sur différents types de ressources dont Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon RDS. Ces défaillances incluent l'arrêt des ressources, les basculements forcés, le stress du processeur ou de la mémoire, la limitation, la latence et la perte de paquets. Comme il est intégré aux alarmes Amazon CloudWatch, vous pouvez définir des conditions d'arrêt comme barrières de protection pour annuler une expérience si elle provoque un impact inattendu.
![\[Schéma montrant qu'AWS Fault Injection Service s'intègre aux ressources AWS pour vous permettre d'exécuter des expériences d'injection de défaillances pour vos charges de travail.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
Il existe également plusieurs options tierces pour les expériences d'injection de défaillances. Il existe notamment des outils open source tels que [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)et [Litmus Chaos](https://litmuschaos.io/), ainsi que des options commerciales comme Gremlin. Pour élargir le champ des défaillances pouvant être injectées sur AWS, AWS FIS [prend désormais en charge Chaos Mesh et Litmus Chaos](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/), ce qui vous permet de coordonner les flux de travail d'injection des défaillances entre plusieurs outils. Par exemple, vous pouvez exécuter un test de stress sur un processeur de pod à l'aide des défaillances Chaos Mesh ou Litmus, tout en arrêtant un pourcentage de nœuds de cluster sélectionné de façon aléatoire grâce aux actions des défaillances AWS FIS.
## Étapes d'implémentation
+ Déterminer les défaillances à utiliser pour les expériences.
Évaluez la conception de votre charge de travail à des fins de résilience. De telles conceptions (créées à l'aide des bonnes pratiques de [Le cadre AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)) tiennent compte des risques en se basant sur des dépendances critiques, des événements passés, des erreurs connues et des exigences de conformité. Répertoriez chaque élément de la conception destiné à maintenir la résilience et les défaillances qu'il entend réduire. Pour plus d'informations sur la création de telles listes, consultez le [livre blanc Examens de disponibilité opérationnelle](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) qui vous guidera dans la création d'un processus capable de prévenir la répétition des incidents précédents. Le processus de Failure Modes and Effects Analysis (FMEA) ou d'analyse des modes de défaillance et de leurs effets vous propose un framework pour réaliser une analyse de niveau composant des défaillances et de leur impact sur votre charge de travail. Le processus FMEA est décrit plus en détail par Adrian Cockcroft dans l'article [Failure Modes and Continuous Resilience (modes de défaillance et résilience continue)](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ Attribuer une priorité à chaque défaillance.
Commencez par définir une classification grossière telle que élevée, moyenne et basse. Pour évaluer les priorités, tenez compte de la fréquence de la défaillance et de son impact sur la charge de travail dans son ensemble.
Lors de la prise en compte de la fréquence d'une défaillance donnée, analysez les données passées de cette charge de travail, le cas échéant. Si aucune donnée passée n'est disponible, utilisez les données des autres charges de travail s'exécutant dans un environnement semblable.
Lors de la prise en compte de l'impact d'une défaillance donnée, souvenez-vous qu'en général plus le champ de la défaillance est large, plus grand est l'impact. Tenez compte également de la conception de la charge de travail et de son objectif. Par exemple, la capacité à accéder aux magasins de données sources est essentielle pour une charge de travail effectuant des transformations et de l'analyse de données. Dans ce cas, vous donnerez la priorité aux expériences liées aux défaillances d'accès ainsi qu'aux accès limités et à l'insertion de la latence.
Les analyses post-incident constituent une excellente source de données pour comprendre à la fois la fréquence et l'impact des modes de défaillance.
Utilisez la priorité attribuée pour déterminer les défaillances à expérimenter en premier lieu, puis l'ordre dans lequel développer de nouvelles expériences d'injection de défaillances.
+ Suivre le volant d'inertie de l'ingénierie du chaos et de la résilience continue pour chaque expérience réalisée.
![\[Schéma du volant d'inertie de l'ingénierie du chaos et de la résilience continue montrant les phases Améliorer, État stable, Hypothèse, Exécuter de l'expérience et Vérifier.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ Définir l'état stable comme le résultat mesurable d'une charge de travail qui indique un comportement normal.
Votre charge de travail présente un état stable si elle fonctionne de manière fiable et comme prévu. Par conséquent, confirmez que charge de travail est saine avant de définir un état stable. L'état stable ne signifie pas forcément sans impact pour la charge de travail en cas de défaillance, car un certain pourcentage des défaillances n'excède pas des limites supportables. L'état stable constitue le repère que vous observerez pendant l'expérience, qui mettra en évidence des anomalies si votre hypothèse formulée dans l'étape suivante ne donne pas les résultats escomptés.
Par exemple, un état stable d'un système de paiements peut être défini comme le traitement de 300 TPS avec un taux de réussite de 99 % et un temps de transmission aller-retour de 500 ms.
+ Formuler une hypothèse sur la façon dont la charge de travail réagira à la défaillance.
Une bonne hypothèse repose sur la façon dont la charge de travail est destinée à réduire la défaillance pour maintenir l'état stable. L'hypothèse indique que vu qu'il s'agit d'une défaillance d'un type particulier, le système ou la charge de travail maintiendra un état stable, car la charge de travail a été conçue avec une atténuation des risques spécifique. Le type particulier de défaillance et d'atténuation des risques doit être spécifié dans l'hypothèse.
Le modèle suivant peut être utilisé pour l'hypothèse (mais une autre formulation est aussi acceptable) :
**Note**
Si *défaillance spécifique* se produit, la charge de travail *nom de la charge de travail* va *décrire les contrôles pour atténuer les risques* afin de limiter *impact métier ou technique*.
Par exemple :
+ Si 20 % des nœuds du node-group Amazon EKS sont supprimés, l'API Transaction Create API continue de répondre au 99e centile des demandes en moins de 100 ms (état stable). Les nœuds Amazon EKS seront opérationnels dans les cinq minutes, et les pods seront planifiés et traiteront le trafic huit minutes après le début de l'expérience. Les alertes se déclencheront sous trois minutes.
+ En cas de défaillance d'une seule instance Amazon EC2, la surveillance de l'état Elastic Load Balancing du système de commandes permet à Elastic Load Balancing d'envoyer uniquement des demandes aux instances saines restantes, tandis qu'Amazon EC2 Auto Scaling remplace l'instance en échec, tout en maintenant une augmentation des erreurs (5xx) côté serveur (état stable) inférieure à 0,01 %.
+ Si l'instance de base de données Amazon RDS principale échoue, la charge de travail de collecte des données Chaîne d'approvisionnement basculera et se connectera à l'instance de base de données Amazon RDS de secours pour maintenir les erreurs de lecture ou d'écriture de base de données (état stable) inférieures à 1 minute.
+ Exécuter l'expérience en injectant la défaillance.
Une expérience doit par défaut être sécurisée et tolérée par la charge de travail. Si vous savez que la charge de travail va échouer, n'exécutez pas l'expérience. L'ingénierie du chaos doit être utilisée pour rechercher les risques connus ou inconnus. *Les risques connus* sont les choses dont vous êtes conscient mais que vous ne comprenez pas bien, et les *risques inconnus* sont les choses dont vous n'êtes pas conscient ou que vous ne comprenez pas bien. Exécuter une expérience sur une charge de travail que vous savez défaillante ne vous apportera rien de plus. Votre expérience doit être soigneusement préparée, disposer d'un champ d'impact défini et fournir un mécanisme de protection pouvant être appliqué en cas de perturbations inattendues. Si votre vérification préalable indique que votre charge de travail doit résister à l'expérience, exécutez cette dernière. Il existe plusieurs moyens d'injecter les défaillances. Pour les charges de travail sur AWS, [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) propose de nombreuses simulations de défaillances prédéfinies appelées [des mesures](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). Vous pouvez également définir des actions personnalisées qui s'exécutent dans AWS FIS à l'aide des [documents AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
Nous déconseillons l'utilisation de scripts personnalisés pour les expériences de chaos, sauf si ces derniers sont capables de comprendre l'état actuel de la charge de travail, d'émettre des journaux, de fournir des mécanismes de protection pour annuler une expérience et des conditions d'arrêt dans la mesure du possible.
Un framework ou des outils efficaces capables de prendre en charge l'ingénierie du chaos doivent suivre l'état actuel d'une expérience, émettre des journaux et fournir des mécanismes de protection pour prendre en charge l'exécution contrôlée d'une expérience. Commencez par un service établi comme AWS FIS qui vous permet d'exécuter des expériences avec un champ clairement défini et des mécanismes de sécurité capables de protéger l'expérience en cas de perturbations inattendues. Pour découvrir plusieurs expériences utilisant AWS FIS, consultez également l' [atelier Applications résilientes et Well-Architected avec l'ingénierie du chaos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). Par ailleurs, [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) analysera votre charge de travail et créera des expériences que vous pourrez choisir d'implémenter et d'exécuter dans AWS FIS.
**Note**
Pour chaque expérience, vous devez bien comprendre le champ et son impact. Nous recommandons que les défaillances soient d'abord simulées sur un environnement hors production avant d'être exécutées en production.
Les expériences doivent s'exécuter en production sous une charge concrète à l'aide des [déploiements canary](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) qui mettent en place des déploiements de système de contrôles et d'expériences, sous réserve de faisabilité. L'exécution d'expériences pendant les heures creuses est une bonne pratique pour réduire l'impact potentiel de la première expérience en production. De plus, si l'utilisation du trafic client réel s'avère trop risquée, vous pouvez exécuter des expériences à l'aide du trafic synthétique sur l'infrastructure de production pour des déploiements de système de contrôles et d'expériences. Lorsqu'une exécution en production n'est pas possible, exécutez les expériences dans des environnements de pré-production aussi proches que possible de la production.
Vous devez définir des barrières de protection pour veiller à ce que l'expérience n'impacte pas le trafic de la production ou d'autres systèmes au-delà des limites acceptables. Définissez des conditions d'arrêt pour stopper une expérience si elle atteint le seuil d'une métrique de barrière protection défini par vos soins. Ces conditions doivent inclure les métriques de l'état stable de la charge de travail, ainsi que celles sur les composants dans lesquels vous injectez la défaillance. A [surveillance synthétique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (également appelée un utilisateur canary) est une métrique que vous devez généralement inclure en tant que proxy utilisateur. [Les conditions d'arrêt pour AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) sont prises en charge dans le cadre d'un modèle de test, autorisant jusqu'à cinq conditions d'arrêt par modèle.
L'un des principes de l'ingénierie du chaos est de minimiser le champ de l'expérience et son impact :
Bien qu'un impact négatif à court terme soit autorisé, l'ingénieur du chaos a la responsabilité et l'obligation de minimiser et de maîtriser les conséquences des expériences.
Pour vérifier le champ et l'impact potentiel, vous pouvez dans un premier temps exécuter l'expérience dans un environnement hors production, en vérifiant que les seuils des conditions d'arrêt s'activent comme prévu pendant l'expérience et que l'observabilité est en place pour détecter une exception, plutôt que d'exécuter l'expérience directement en production.
Lorsque vous exécutez des expériences d'injection de défaillances, vérifiez que toutes les parties responsables sont bien informées. Communiquez avec les équipes appropriées, telles que les équipes en charge des opérations, les équipes chargées de la fiabilité du service et le service client pour leur indiquer quand les expériences seront exécutées et à quoi ils doivent s'attendre. Donnez à ces équipes les outils de communication nécessaires pour informer les personnes en charge de l'exécution de l'expérience si elles constatent des effets négatifs.
Vous devez restaurer la charge de travail et ses systèmes sous-jacents dans leur état fonctionnel et connu d'origine. En général, la conception résiliente de la charge de travail lui permet de s'auto-réparer. Cependant, certaines conceptions défaillantes ou échecs d'expériences peuvent laisser votre charge de travail dans un état d'échec inattendu. À la fin de l'expérience, vous devez en être conscient et restaurer la charge de travail et les systèmes. Avec AWS FIS, vous pouvez définir une configuration de barrière de protection (également appelée post action) dans les paramètres d'action. Une post action restaure la cible dans l'état dans lequel elle se trouvait avant l'exécution de l'action. Qu'elles soient automatisées (comme lorsque vous utilisez AWS FIS) ou manuelles, ces post actions doivent faire partie d'un playbook décrivant la façon de détecter et de gérer les échecs.
+ Vérifier l'hypothèse.
[Principes de l'ingénierie du chaos](https://principlesofchaos.org/) donne des conseils sur la façon de vérifier l'état stable de votre charge de travail :
Concentrez-vous sur le résultat mesurable d'un système, plutôt que sur les attributs internes du système. Les mesures de ce résultat sur une courte période de temps constituent un proxy pour l'état stable du système. Le débit général du système, les taux d'erreur et les centiles de latence peuvent tous être des métriques d'intérêt représentant un comportement d'état stable. En se focalisant sur les modèles de comportement systémique pendant les expériences, l'ingénierie du chaos vérifie que le système fonctionne, au lieu d'essayer de confirmer qu'il fonctionne.
Dans nos deux exemples précédents, nous incluons la métrique de l'état stable inférieure à 0,01 % d'augmentation des erreurs (5xx) côté serveur et la métrique inférieure à 1 minute d'erreurs de lecture ou d'écriture de base de données.
Les erreurs 5xx constituent une bonne métrique, car elles sont une conséquence du mode de défaillance dont le client de la charge de travail fera l'expérience directement. La mesure des erreurs de base de données est correcte en tant que conséquence directe de la défaillance, mais doit être également complétée par une mesure d'impact, telle que les échecs de demandes client ou les erreurs remontées. Par ailleurs, incluez une surveillance synthétique (également appelée utilisateur canary) sur n'importe quelle API ou URI directement accessible par le client de votre charge de travail.
+ Améliorer la conception de la charge de travail à des fins de résilience.
Si l'état stable n'a pas été maintenu, enquêtez sur les moyens d'améliorer la conception de la charge de travail afin de réduire la défaillance, tout en appliquant les bonnes pratiques du [pilier Fiabilité du cadre AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). Des conseils et ressources supplémentaires sont disponibles dans la [bibliothèque des créateurs AWS](https://aws.amazon.com/builders-library/), qui héberge des articles sur la façon d' [améliorer vos surveillances de l'état](https://aws.amazon.com/builders-library/implementing-health-checks/) ou [utiliser de nouvelles tentatives avec interruption dans votre code d'application](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), entre autres.
Une fois ces changements implémentés, exécutez de nouveau l'expérience (illustrée par la ligne pointillée dans le volant d'inertie de l'ingénierie du chaos) pour déterminer son efficacité. Si l'étape de vérification indique que l'hypothèse est vraie, alors la charge de travail sera en état stable et le cycle continuera.
+ Exécuter régulièrement des expériences.
Une expérience de chaos est un cycle, et les expériences doivent être exécutées régulièrement dans le cadre de l'ingénierie du chaos. Lorsqu'une charge de travail correspond à l'hypothèse d'une expérience, cette dernière doit être automatisée pour s'exécuter en continu en tant que test de régression de votre pipeline CI/CD. Pour savoir comment faire, consultez ce blog sur [l'exécution d'expériences AWS FIS en utilisant AWS CodePipeline](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/). Cet atelier sur les expériences [AWS FIS récurrentes dans un pipeline CI/CD](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) vous permet de mettre la main à la pâte.
Les expériences d'injection de défaillance font également partie des tests de simulation de pannes (consultez [REL12-BP06 Organiser régulièrement des tests de simulation de panne](rel_testing_resiliency_game_days_resiliency.md)). Les tests de simulation de pannes simulent une défaillance ou un événement pour vérifier les systèmes, les processus et la réponse de l'équipe. L'objectif est d'effectuer les actions que l'équipe effectuerait si un événement exceptionnel se produisait.
+ Enregistrer et stocker les résultats des expériences.
Les résultats des expériences d'injection de défaillance doivent être enregistrés et conservés. Incluez toutes les données nécessaires (telles que l'heure, la charge de travail et les conditions) afin de pouvoir analyser ultérieurement les résultats de l'expérience et les tendances. Les exemples de résultats peuvent inclure des captures d'écran des tableaux de bord, des fichiers CSV de la base de données de votre/vos métriques ou un registre manuscrit des événements et observations pendant l'expérience. [La journalisation des expériences avec AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) peut faire partie de la collecte des données.
## Ressources
**Bonnes pratiques associées :**
+ [REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement](rel_tracking_change_management_resiliency_testing.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 :**
+ [Qu'est-ce qu'AWS Fault Injection Service ?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [Qu'est-ce qu'AWS Resilience Hub ?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principes de l'ingénierie du chaos](https://principlesofchaos.org/)
+ [Ingénierie du chaos : préparation de votre première expérience](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Ingénierie de résilience : apprendre à intégrer les pannes](https://queue.acm.org/detail.cfm?id=2371297)
+ [Témoignages d'utilisation de l'ingénierie du chaos](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [Éviter les solutions de secours dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [Déploiement canary pour des expériences de chaos](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**Vidéos connexes :**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : test de la résilience d'Amazon EC2, Amazon RDS et Amazon S3](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Atelier L'ingénierie du chaos dans AWS](https://chaos-engineering.workshop.aws/en/)
+ [atelier Applications résilientes et Well-Architected avec l'ingénierie du chaos](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Atelier Chaos sans serveur](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Atelier Mesurer et améliorer la résilience de votre application avec AWS Resilience Hub](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** Outils associés : **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace : [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 Organiser régulièrement des tests de simulation de panne
Utilisez des tests de simulation de panne pour exercer régulièrement vos procédures de réponse aux événements et aux défaillances aussi près que possible de la production (y compris dans les environnements de production) avec les personnes qui seront impliquées dans les scénarios de défaillance réels. Les tests de simulation de panne appliquent des mesures pour s'assurer que les événements de production n'affectent pas les utilisateurs.
Ils simulent une défaillance ou un événement pour tester les systèmes, les processus et la réponse de l'équipe. L'objectif est d'effectuer les actions que l'équipe effectuerait si un événement exceptionnel se produisait. Cela vous aidera à comprendre où apporter des améliorations et à développer une expérience de gestion des événements au sein de votre organisation. Des tests de simulation de panne doivent être effectués régulièrement afin que votre équipe se forge une *« mémoire musculaire »* quant à la façon de réagir.
Une fois votre conception de résilience en place et testée dans des environnements non liés à la production, un test de simulation de panne permet de s'assurer que tout fonctionne comme prévu en production. Un test de simulation de pannes, particulièrement le premier, est une activité « exploitant toutes les ressources ». L’intégralité des ingénieurs et des opérations est informée de ce qui se passera et quand. Les playbooks sont en place. Des événements simulés sont exécutés, y compris des événements de défaillance possibles, dans les systèmes de production de la manière prescrite, et l'impact est évalué. Si tous les systèmes fonctionnent comme prévu, la détection et l'auto-réparation se produiront avec peu, voire aucun impact. En revanche, si un impact négatif est observé, le test est annulé et les problèmes de charge de travail sont résolus, manuellement au besoin (à l'aide du runbook). Étant donné que les tests de simulation de pannes se déroulent souvent en production, toutes les précautions doivent être prises pour s'assurer de l'absence d’impact sur la disponibilité pour vos clients.
**Anti-modèles courants :**
+ Documenter vos procédures sans jamais les exercer.
+ Non-inclusion des décideurs commerciaux dans les exercices de test.
**Avantages liés au respect de cette bonne pratique :** L'organisation régulière de tests de simulation de panne a un double avantage. D'une part, elle permet de s'assurer que tout le personnel suit les stratégies et les procédures lorsqu'un incident réel se produit. D'autre part, elle facilite la validation de l'adéquation de ces stratégies et procédures.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Planifiez des tests de simulation de panne pour tester régulièrement vos runbooks et vos playbooks. Les tests de simulation de panne doivent impliquer tous ceux qui seraient affectés par une interruption de production : le propriétaire de l'entreprise, les développeurs, le personnel d'exploitation et les équipes d'interventions.
+ Effectuez vos tests de charge ou de performances et mettez en œuvre l'injection de défaillances.
+ Recherchez des anomalies dans vos runbooks et des possibilités de test de vos playbooks.
+ Si vous vous écartez de vos runbooks, affinez-les ou corrigez le comportement. Lors des tests de votre playbook,, identifiez les runbooks qui auraient dû être utilisés ou créez-en de nouveaux.
## Ressources
**Documents connexes :**
+ [Qu'est-ce qu'AWS GameDay ?](https://aws.amazon.com/gameday/)
**Vidéos connexes :**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**Exemples connexes :**
+ [AWS Well-Architected Labs - Testing Resiliency](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# 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)