# 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)