# Fiabilité
**Topics**
+ [Bases](a-foundations.md)
+ [Architecture de charge de travail](a-workload-architecture.md)
+ [Gestion des modifications](a-change-management.md)
+ [Gestion des défaillances](a-failure-management.md)
# Bases
**Topics**
+ [REL 1 Comment gérer les quotas et les contraintes de service ?](w2aac19b9b5b5.md)
+ [REL 2 Comment planifier la topologie de votre réseau ?](w2aac19b9b5b7.md)
# REL 1 Comment gérer les quotas et les contraintes de service ?
Pour les architectures de charge de travail basées sur le cloud, il existe des quotas de service (aussi appelés Service Limits). Le rôle de ces quotas est d'empêcher la mise en service accidentelle de plus de ressources que nécessaire et de limiter les taux de demandes sur les opérations d'API afin de protéger les services contre les abus. Il existe également des contraintes de ressource. Par exemple, la vitesse à laquelle vous pouvez transmettre des bits sur un câble de fibre optique, ou la quantité de stockage sur un disque physique.
**Topics**
+ [REL01-BP01 Connaissance des quotas de service et des contraintes](rel_manage_service_limits_aware_quotas_and_constraints.md)
+ [REL01-BP02 Gérer les quotas de service entre les comptes et les régions](rel_manage_service_limits_limits_considered.md)
+ [REL01-BP03 Tenir compte des quotas et des contraintes de service fixes dans l'architecture](rel_manage_service_limits_aware_fixed_limits.md)
+ [REL01-BP04 Surveiller et gérer les quotas](rel_manage_service_limits_monitor_manage_limits.md)
+ [REL01-BP05 Automatiser la gestion des quotas](rel_manage_service_limits_automated_monitor_limits.md)
+ [REL01-BP06 Garantir un écart suffisant entre les quotas actuels et l'utilisation maximale pour permettre le basculement](rel_manage_service_limits_suff_buffer_limits.md)
# REL01-BP01 Connaissance des quotas de service et des contraintes
Vous connaissez vos quotas par défaut et les demandes d'augmentation de quota pour votre architecture de charge de travail. Vous savez également les contraintes de ressources – comme le disque ou le réseau – qui sont susceptibles d'avoir un impact.
Service Quotas est un service AWS qui vous aide à gérer vos quotas pour plus de 100 services AWS depuis un seul et même emplacement. En plus de rechercher les valeurs de quota, vous pouvez également demander et suivre les augmentations de quota à partir de la console Service Quotas ou via le kit SDK AWS. AWS Trusted Advisor propose un contrôle des quotas de service qui affiche votre utilisation et les quotas de différents aspects de certains services. Les quotas de service par défaut par service figurent également dans la documentation AWS de chaque service. Par exemple, consultez [Amazon VPC Quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html). Les limites de taux sur les API limitées sont définies dans API Gateway en configurant un plan d'utilisation. Les autres limites définies en tant que configuration sur leurs services respectifs incluent les IOPS provisionnés, le stockage RDS alloué et les allocations de volume EBS. Amazon Elastic Compute Cloud (Amazon EC2) dispose de son propre tableau de bord des limites de service qui peut vous aider à gérer votre instance, Amazon Elastic Block Store (Amazon EBS) et les limites d'adresses IP Elastic. Si vous possédez un cas d'utilisation pour lequel les quotas de service affectent les performances de votre application sans être ajustables à vos besoins, contactez AWS Support pour déterminer si des mesures d'atténuation peuvent être implémentées.
**Anti-modèles courants :**
+ Déploiement d'une charge de travail sans tenir compte des quotas de service pour les services AWS utilisés.
+ Conception d'une charge de travail sans examiner et s'adapter aux contraintes de conception des services AWS.
+ Déploiement d'une charge de travail avec une utilisation importante qui remplace une charge de travail existante connue sans contacter AWS Support à l'avance.
+ Planification d'un événement pour diriger le trafic vers votre charge de travail, mais sans configurer les quotas nécessaires ou sans contacter AWS Support à l'avance.
**Avantages liés au respect de cette bonne pratique :** Comme vous connaissez les quotas de service, les limites API et les contraintes de conception, vous pourrez en tenir compte dans la conception, l'implémentation et l'exploitation de la charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Vérification des quotas de service AWS dans la documentation publiée et Service Quotas
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ Identification de tous les services indispensables à votre charge de travail en prenant en compte le code de déploiement.
+ Optez pour AWS Config pour identifier toutes les ressources AWS utilisées dans vos Comptes AWS.
+ [AWS Config : types de ressources et relations de ressources AWS](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)
+ Vous pouvez également utiliser votre AWS CloudFormation pour déterminer vos ressources AWS utilisées. Examinez les ressources créées dans AWS Management Console ou via la commande list-stack-resources de l'interface de ligne de commande (CLI). Vous pouvez également voir les ressources configurées pour être déployées directement dans le modèle.
+ [Affichage des données et des ressources de la pile AWS CloudFormation sur AWS Management Console](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)
+ [AWS CLI pour CloudFormation : list-stack-resources](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/list-stack-resources.html)
+ Identifiez les quotas de service pertinents. Utilisez les informations accessibles par programmation par le biais de Service Quotas.
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor (voir la section Service Limits)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor sur AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP02 Gérer les quotas de service entre les comptes et les régions
Si vous utilisez plusieurs Comptes AWS ou Régions AWS, tâchez de demander les quotas appropriés dans tous les environnements dans lesquels vous exécutez vos charges de travail de production.
Les quotas de service sont suivis par compte. Sauf indication contraire, chaque quota est propre à une Région AWS. En plus des environnements de production, gérez également les quotas dans tous les autres environnements applicables, afin que les tests et le développement ne souffrent pas.
**Anti-modèles courants :**
+ Laisser l'utilisation des ressources dans une zone d'isolement se développer sans aucun mécanisme pour maintenir la capacité dans les autres zones.
+ Définition manuelle de tous les quotas de manière indépendante dans les zones d'isolement.
+ Absence de vérification que les déploiements isolés au niveau régional sont dimensionnés pour faire face à l'augmentation du trafic en provenance d'une autre région en cas de perte d'un déploiement.
**Avantages liés au respect de cette bonne pratique :** Le nombre d'erreurs peut réduire lors du basculement si vous vous assurez de pouvoir gérer votre charge actuelle si une zone d'isolement n'est pas disponible. Cette précaution vous permettra d'éviter de provoquer un déni de service pour vos clients.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Sélection des comptes et régions pertinents en fonction de vos exigences de services, de la latence, des exigences réglementaires et de reprise après sinistre (DR).
+ Identification des quotas de services dans l'ensemble des comptes, régions et zones de disponibilité pertinents. Les limites sont définies pour le compte et la région.
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor (voir la section Service Limits)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor sur AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP03 Tenir compte des quotas et des contraintes de service fixes dans l'architecture
Soyez conscient des quotas de service et des ressources physiques immuables et concevez l'architecture de sorte à éviter que ces quotas n'affectent la fiabilité.
Entre autres exemples figurent la bande passante réseau, la taille de la charge utile AWS Lambda, la limitation du taux de salves d'API Gateway et les connexions utilisateur simultanées à un cluster Amazon Redshift.
**Anti-modèles courants :**
+ Exécution de la définition de points de référence pendant une période trop courte en utilisant la limite de transmission en rafales, tout en s'attendant à ce que le service fonctionne à cette capacité pendant de longues périodes.
+ Choix d'une conception qui utilise une ressource d'un service par utilisateur ou client, sans savoir qu'il existe des contraintes de conception qui entraîneront l'échec de cette conception au fil des mises à l'échelle.
**Avantages liés au respect de cette bonne pratique :** Le suivi des offres fixes dans les services AWS et les contraintes dans d'autres parties de votre charge de travail, telles que les contraintes de connectivité, d'adresse IP et de services tiers, vous permet de détecter quand vous avez tendance à utiliser un quota et vous donne la possibilité de traiter le quota avant qu'il ne soit dépassé.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Être conscient des quotas de service fixes : tenez compte des contraintes et des quotas de services fixes lors de la conception de l'architecture.
+ [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor (voir la section Service Limits)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [AWS Limit Monitor sur AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP04 Surveiller et gérer les quotas
Évaluez votre utilisation potentielle et augmentez vos quotas de manière appropriée afin d'assurer une croissance planifiée de l'utilisation.
Pour les services supportés, vous pouvez gérer vos quotas en configurant des alarmes CloudWatch pour surveiller l'utilisation et vous avertir de l'approche des quotas. Ces alarmes peuvent être déclenchées à partir de Service Quotas ou de Trusted Advisor. Vous pouvez également utiliser des filtres de métriques sur CloudWatch Logs pour rechercher et extraire des modèles dans les journaux afin de déterminer si l'utilisation approche des seuils de quota.
**Anti-modèles courants :**
+ Configuration d'alarmes lorsque des Service Quotas sont sur le point d'être atteints, mais sans disposer de processus sur la façon de répondre à une alerte.
+ Configuration d'alarmes uniquement pour les services pris en charge par les Service Quotas, sans surveiller les autres services.
**Avantages liés au respect de cette bonne pratique :** Le suivi automatique des quotas de service AWS et la surveillance de votre utilisation par rapport à ces quotas vous permettent de voir quand vous vous rapprochez d'un quota. Vous pouvez également utiliser ces données de surveillance pour évaluer à quel moment vous pouvez réduire les quotas afin de réduire les coûts.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Surveiller et gérer les quotas : évaluez votre utilisation potentielle sur AWS, augmentez vos quotas de service régionaux comme il se doit et autorisez la croissance planifiée de l'utilisation.
+ Enregistrez la consommation des ressources actuelles (par exemple, les compartiments et les instances). Utilisez les opérations d'API de services, par exemple l'API DescribeInstances d'Amazon EC2, pour collecter les informations sur la consommation des ressources actuelle.
+ Capturez vos quotas actuels. Utilisez la documentation AWS Service Quotas, AWS Trusted Advisor et AWS.
+ Utilisez AWS Service Quotas, un service AWS qui vous aide à gérer vos quotas pour plus de 100 services AWS à partir d'un seul emplacement.
+ Utilisez les limites de service Trusted Advisor pour déterminer vos limites de service actuelles.
+ Utilisez les opérations d'API de service pour déterminer les limites de service actuelles, le cas échéant.
+ Garder un enregistrement des hausses de quota qui ont été demandées, et leur statut : une fois qu'une augmentation de quota a été approuvée, veillez à mettre à jour vos enregistrements pour refléter la modification de ce quota.
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor pour les limites de service](https://docs.aws.amazon.com/awssupport/latest/user/service-limits.html)
+ [AWS Limit Monitor sur AWS Answers](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Surveillance des Service Quotas avec les alarmes Amazon CloudWatch](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP05 Automatiser la gestion des quotas
Mettez en place des outils pour être informé à lorsque l'atteinte des seuils est proche. Vous pouvez automatiser les demandes d'augmentation de quota à l'aide des API AWS Service Quotas.
Si vous intégrez votre base de données de gestion de configuration (CMDB) ou votre système de tickets avec Service Quotas, vous pouvez automatiser le suivi des requêtes d'augmentation de quotas et des quotas actuels. En plus du kit SDK AWS, Service Quotas propose une automatisation avec AWS Command Line Interface (AWS CLI).
**Anti-modèles courants :**
+ Suivi des quotas et de l'utilisation dans les feuilles de calcul.
+ Exécution de rapports sur l'utilisation quotidienne, hebdomadaire ou mensuelle, puis comparaison de l'utilisation aux quotas.
**Avantages liés au respect de cette bonne pratique :** Le suivi automatisé des quotas de service AWS et la surveillance de votre utilisation par rapport à ce quota vous permettent de voir quand vous vous rapprochez d'un quota. Vous pouvez configurer l'automatisation pour vous aider à demander une augmentation de quota si nécessaire. Vous pouvez envisager de réduire certains quotas lorsque votre utilisation évolue dans le sens inverse pour profiter des avantages d'une réduction des risques (en cas d'informations d'identification corrompues) et des économies de coûts.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Configurer la surveillance automatisée : mettez en place des outils à l'aide de kits SDK pour être informé lorsque des seuils sont sur le point d'être atteints.
+ Utilisez les Service Quotas et complétez le service avec une solution automatisée de surveillance des quotas, tels qu'AWS Limit Monitor ou une offre sur AWS Marketplace.
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
+ [Surveillance des quotas sur AWS - Solution AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ Configurez des réponses déclenchées en fonction des seuils de quota, à l'aide des API Amazon SNS et AWS Service Quotas .
+ Testez l'automatisation.
+ Configurez les seuils de limites.
+ Intégrez les événements de modification provenant d'AWS Config, des pipelines de déploiement, d'Amazon EventBridge ou de tiers.
+ Définissez des seuils de limites artificiellement bas pour tester les réponses.
+ Configurez des déclencheurs pour prendre les mesures appropriées en cas de notifications et contactez AWS Support, le cas échéant
+ Déclenchez manuellement les événements de modifications.
+ Organisez un jeu de rôle pour tester le processus d'augmentation des quotas.
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires facilitant la gestion de la configuration](https://aws.amazon.com/partners/find/results/?keyword=Configuration+Management)
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor (voir la section Service Limits)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Surveillance des quotas sur AWS - Solution AWS](https://aws.amazon.com/answers/account-management/limit-monitor/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL01-BP06 Garantir un écart suffisant entre les quotas actuels et l'utilisation maximale pour permettre le basculement
En cas de panne d'une ressource, il est possible qu'elle continue d'être comptabilisée dans les quotas jusqu'à sa résiliation. Vérifiez que vos limites couvrent le chevauchement de toutes les ressources défaillantes avec des remplacements avant la résiliation des ressources défaillantes. Tenez compte du risque de défaillance d'une zone de disponibilité lors du calcul de cet écart.
**Anti-modèles courants :**
+ Définition de quotas de service en fonction des quotas actuels sans tenir compte des scénarios de basculement.
**Avantages liés au respect de cette bonne pratique :** Lorsque des événements ont un impact potentiel sur la disponibilité, le cloud vous permet de mettre en œuvre des stratégies pour atténuer ces événements ou s'en remettre. Ces stratégies incluent souvent la création de ressources supplémentaires pour remplacer celles qui ont échoué. Votre stratégie de quota doit tenir compte de ces ressources supplémentaires.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Vérifiez qu'il existe un écart suffisant entre votre quota de service et votre utilisation maximale pour permettre un basculement.
+ Identifiez les quotas de service en tenant compte de vos modèles de déploiement, de vos exigences en matière de disponibilité et de la croissance de votre consommation.
+ Demandez des augmentations de quota si nécessaire Prévoyez le temps nécessaire pour l'approbation des demandes d'augmentation des quotas.
+ Identifiez vos exigences de fiabilité.
+ Définissez vos scénarios de défaillance (par exemple, perte d'un composant, d'une zone de disponibilité ou d'une région).
+ Définissez votre méthodologie de déploiement (par exemple, canary, bleu/vert, rouge/noir ou par propagation).
+ Ajoutez une mémoire tampon appropriée (par exemple, 15 %) à la limite actuelle.
+ Anticipez la croissance de la consommation (par exemple, surveillance de vos tendances de consommation).
## Ressources
**Documents connexes :**
+ [AWS Marketplace : produits CMDB facilitant le suivi des limites](https://aws.amazon.com/marketplace/search/results?searchTerms=CMDB)
+ [AWS Service Quotas (anciennement appelés Service Limits)](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Vérifications des bonnes pratiques AWS Trusted Advisor (voir la section Service Limits)](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
+ [Amazon EC2 Service Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)
+ [Qu'est-ce que Service Quotas ?](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)
**Vidéos connexes :**
+ [AWS Live re:Inforce 2019 - Service Quotas](https://youtu.be/O9R5dWgtrVo)
# REL 2 Comment planifier la topologie de votre réseau ?
Les charges de travail existent souvent dans plusieurs environnements. Il s'agit notamment de plusieurs environnements cloud (accessibles publiquement et privés) et éventuellement de votre infrastructure de centre de données existante. Les plans doivent inclure des considérations réseau telles que la connectivité intrasystème et intersystème, la gestion des adresses IP publiques, la gestion des adresses IP privées et la résolution des noms de domaine.
**Topics**
+ [REL02-BP01 Utiliser une connectivité réseau hautement disponible pour vos points de terminaison publics de charge de travail](rel_planning_network_topology_ha_conn_users.md)
+ [REL02-BP02 Mettre en service une connectivité redondante entre les réseaux privés dans le cloud et les environnements sur site](rel_planning_network_topology_ha_conn_private_networks.md)
+ [REL02-BP03 S'assurer que l'allocation des sous-réseaux IP tient compte de l'expansion et de la disponibilité](rel_planning_network_topology_ip_subnet_allocation.md)
+ [REL02-BP04 Préférer les topologies en étoile au maillage « many-to-many »](rel_planning_network_topology_prefer_hub_and_spoke.md)
+ [REL02-BP05 Appliquer des plages d'adresses IP privées sans chevauchement dans tous les espaces d'adressage privés où ils sont connectés](rel_planning_network_topology_non_overlap_ip.md)
# REL02-BP01 Utiliser une connectivité réseau hautement disponible pour vos points de terminaison publics de charge de travail
Ces points de terminaison et leur routage doivent être hautement disponibles. Pour ce faire, utilisez le DNS hautement disponible, les réseaux de diffusion de contenu (CDN), API Gateway, l'équilibrage de charge ou les proxys inverses.
Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway et Elastic Load Balancing (ELB) fournissent tous des points de terminaison publics hautement disponibles. Vous pouvez également choisir d'évaluer des appliances logicielles AWS Marketplace pour l'équilibrage de charge et les proxys.
Les clients du service fourni par votre charge de travail, qu'il s'agisse d'utilisateurs finaux ou d'autres services, effectuent des requêtes sur ces points de terminaison de service. Plusieurs ressources AWS sont disponibles pour vous permettre de fournir des points de terminaison hautement disponibles.
Elastic Load Balancing assure l'équilibrage de charge entre les zones de disponibilité, effectue le routage de couche 4 (TCP) ou de couche 7 (http/https), s'intègre à AWS WAF et à AWS Auto Scaling pour faciliter la création d'une infrastructure d'auto-réparation et l'absorption des augmentations de trafic tout en libérant des ressources lorsque le trafic diminue.
Amazon Route 53 est un système de noms de domaine (DNS) évolutif et hautement disponible qui connecte efficacement les requêtes des utilisateurs à l'infrastructure s'exécutant dans AWS, notamment aux instances Amazon EC2, aux équilibreurs de charge Elastic Load Balancing ou aux compartiments Amazon S3. Ce service permet aussi de router les utilisateurs vers une infrastructure extérieure à AWS.
AWS Global Accelerator est un service de couche réseau utilisable pour diriger le trafic vers des points de terminaison optimaux sur le réseau mondial AWS.
Les attaques par déni de service distribué (DDoS) risquent d'interrompre le trafic légitime et de réduire la disponibilité pour vos utilisateurs. AWS Shield assure une protection automatique contre ces attaques sans frais supplémentaires pour les points de terminaison de service AWS sur votre charge de travail. Vous pouvez étendre ces fonctionnalités avec des appliances virtuelles de partenaires APN et d'AWS Marketplace pour répondre à vos besoins.
**Anti-modèles courants :**
+ Utilisation d'adresses Internet publiques sur des instances ou des conteneurs et gestion de la connectivité à ces dernières via DNS.
+ Utilisation d'adresses de protocole Internet au lieu de noms de domaine pour localiser les services.
+ Fourniture du contenu (pages Web, ressources statiques, fichiers multimédias) à une grande zone géographique sans utilisation d’un réseau de diffusion de contenu.
**Avantages liés au respect de cette bonne pratique :** L'implémentation de services à haute disponibilité dans votre charge de travail vous permet de mettre votre charge de travail à la disposition de vos utilisateurs.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
Assurez-vous que vous disposez d'une connectivité hautement disponible pour les utilisateurs de la charge de travail. Amazon Route 53, AWS Global Accelerator, Amazon CloudFront, Amazon API Gateway et Elastic Load Balancing (ELB) fournissent tous des points de terminaison publics hautement disponibles. Vous pouvez également choisir d'évaluer des appliances logicielles AWS Marketplace pour l'équilibrage de charge et les proxys.
+ Vérifiez que vous disposez d'une connexion hautement disponible pour vos utilisateurs.
+ Assurez-vous d'utiliser un DNS hautement disponible pour gérer les noms de domaine de vos points de terminaison d'application.
+ Si vos utilisateurs accèdent à votre application via Internet, utilisez les opérations d'API de service pour confirmer la bonne utilisation des passerelles Internet. Vérifiez également que les entrées des tables de routage pour les sous-réseaux hébergeant vos points de terminaison d'application sont bonnes.
+ [DescribeInternetGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInternetGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Vérifiez que vous utilisez un proxy inverse ou un équilibreur de charge hautement disponible devant votre application.
+ Si vos utilisateurs accèdent à votre application via votre environnement sur site, assurez-vous que la connectivité entre AWS et votre environnement sur site est hautement disponible.
+ Utilisez Route 53 pour gérer vos noms de domaine.
+ [Qu'est-ce qu'Amazon Route 53 ?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Utilisez un fournisseur DNS tiers qui répond à vos exigences.
+ Utilisez Elastic Load Balancing.
+ [Qu'est-ce qu'Elastic Load Balancing ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Utilisez une appliance AWS Marketplace qui répond à vos exigences.
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à planifier votre mise en réseau](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recommandations de résilience AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace pour l'infrastructure réseau](https://aws.amazon.com/marketplace/b/2649366011)
+ [Livre blanc sur les options de connectivité Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connectivité réseau haute disponibilité de plusieurs centres de données](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Utilisation de la boîte à outils Direct Connect Resiliency Toolkit pour démarrer](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Points de terminaison d'un VPC et services de point de terminaison de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Qu'est-ce qu'AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Qu'est-ce qu'Amazon VPC ?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Qu'est-ce que Transit Gateway ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Qu'est-ce que Amazon CloudFront ?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ [Qu'est-ce qu'Amazon Route 53 ?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Qu'est-ce qu'Elastic Load Balancing ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Utilisation des passerelles Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP02 Mettre en service une connectivité redondante entre les réseaux privés dans le cloud et les environnements sur site
Utilisez plusieurs connexions AWS Direct Connect ou tunnels VPN entre des réseaux privés déployés séparément. Utilisez plusieurs emplacements Direct Connect pour une plus haute disponibilité. Si vous utilisez plusieurs Régions AWS, assurez la redondance dans au moins deux d'entre elles. Il serait souhaitable d'évaluer les appliances AWS Marketplace qui mettent fin aux VPN. Si vous utilisez des appliances AWS Marketplace, déployez des instances redondantes pour une plus haute disponibilité dans différentes zones de disponibilité.
AWS Direct Connect est un service cloud qui permet d'établir facilement une connexion réseau dédiée depuis votre environnement sur site vers AWS. Grâce à la passerelle Direct Connect, votre centre de données sur site peut être connecté à plusieurs VPC AWS répartis sur plusieurs Régions AWS.
Cette redondance permet de faire face aux pannes possibles ayant un impact sur la résilience de la connectivité :
+ Comment allez-vous résister aux pannes dans votre topologie ?
+ Que se passe-t-il si un composant est mal configuré et perd sa connectivité ?
+ Pourrez-vous gérer une augmentation inattendue du trafic ou de l'utilisation de vos services ?
+ Serez-vous en mesure d'absorber une tentative d'attaque par déni de service distribué ?
Lors de la connexion de votre VPC à votre centre de données sur site via un VPN, tenez compte des exigences en matière de résilience et de bande passante lorsque vous sélectionnez le fournisseur et la taille d'instance dont vous avez besoin pour exécuter l'appliance. Si vous utilisez une appliance VPN qui n'est pas résiliente dans son implémentation, vous devez avoir une connexion redondante via une seconde appliance. Pour tous ces scénarios, vous devez définir les temps de récupération acceptables et faire des tests pour vous assurer que vous pouvez satisfaire ces exigences.
Si vous choisissez de connecter votre VPC à votre centre de données à l'aide d'une connexion Direct Connect et que vous avez besoin que cette connexion soit hautement disponible, vous devez disposer de connexions Direct Connect redondantes à partir de chaque centre de données. La connexion redondante doit utiliser une deuxième connexion Direct Connect à partir d'un emplacement différent de la première. Si vous avez plusieurs centres de données, assurez-vous que les connexions se terminent à différents emplacements. Utilisez la boîte à outils [Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) pour faciliter la mise en œuvre de cette configuration.
Si vous choisissez de basculer sur un VPN via Internet à l'aide d'un Site-to-Site VPN, il est important de comprendre qu'il prend en charge jusqu'à 1,25 Gbit/s de débit par tunnel VPN, mais pas le protocole ECMP (Equal Cost Multi Path) pour le trafic sortant dans le cas de plusieurs tunnels VPN gérés par AWS aboutissant à la même passerelle virtuelle. Nous vous déconseillons d'utiliser un VPN géré par AWS comme système de secours pour les connexions Direct Connect, sauf si vous pouvez tolérer des vitesses inférieures à 1 Gbit/s lors du basculement.
Vous pouvez également utiliser les points de terminaison d'un VPC pour connecter de manière privée votre VPC aux services AWS pris en charge et aux services de point de terminaison d'un VPC à technologie AWS PrivateLink sans traverser l'Internet public. Les points de terminaison sont des dispositifs virtuels. Il s'agit de composants VPC mis à l’échelle horizontalement, redondants et hautement disponibles. Ils permettent la communication entre les instances de votre VPC et les services sans imposer de risques de disponibilité ou de contraintes de bande passante sur votre trafic réseau.
**Anti-modèles courants :**
+ Un seul fournisseur de connectivité entre votre réseau sur site et AWS.
+ Utilisation des capacités de connectivité de votre connexion AWS Direct Connect, mais en ayant qu'une seule connexion.
+ Un seul chemin pour votre connectivité VPN.
**Avantages liés au respect de cette bonne pratique :** En implémentant une connectivité redondante entre votre environnement cloud et votre environnement d'entreprise/sur site, vous pouvez vous assurer que les services dépendants entre les deux environnements peuvent communiquer de manière fiable.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Élevé
## Directives d'implémentation
+ Assurez-vous que vous disposez d’une connectivité hautement disponible entre AWS et l'environnement sur site. Utilisez plusieurs connexions AWS Direct Connect ou tunnels VPN entre des réseaux privés déployés séparément. Utilisez plusieurs emplacements Direct Connect pour une plus haute disponibilité. Si vous utilisez plusieurs Régions AWS, assurez la redondance dans au moins deux d'entre elles. Il serait souhaitable d'évaluer les appliances AWS Marketplace qui mettent fin aux VPN. Si vous utilisez des appliances AWS Marketplace, déployez des instances redondantes pour une plus haute disponibilité dans différentes zones de disponibilité.
+ Assurez-vous que vous avez une connexion redondante à votre environnement sur site. Vous pouvez avoir besoin de connexions redondantes à plusieurs Régions AWS pour répondre à vos besoins de disponibilité.
+ [Recommandations de résilience AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [Utilisation de connexions VPN de site à site redondantes pour assurer le basculement](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ Utilisez des opérations d'API de service pour confirmer la bonne utilisation des circuits Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ S'il existe une seule connexion Direct Connect ou si vous n'en avez aucune, configurez des tunnels VPN redondants vers vos passerelles réseau privées virtuelles.
+ [Qu'est-ce qu'AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ Capturez votre connectivité actuelle (par exemple, Direct Connect, passerelles réseau privées virtuelles, appliances AWS Marketplace).
+ Utilisez des opérations d'API de service pour interroger la configuration des connexions Direct Connect.
+ [DescribeConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnections.html)
+ [DescribeConnectionsOnInterconnect](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeConnectionsOnInterconnect.html)
+ [DescribeDirectConnectGatewayAssociations](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAssociations.html)
+ [DescribeDirectConnectGatewayAttachments](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGatewayAttachments.htmll)
+ [DescribeDirectConnectGateways](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeDirectConnectGateways.html)
+ [DescribeHostedConnections](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeHostedConnections.html)
+ [DescribeInterconnects](https://docs.aws.amazon.com/directconnect/latest/APIReference/API_DescribeInterconnects.html)
+ Utilisez des opérations d'API de service pour collecter les passerelles réseau privées virtuelles là où les tables de routage les utilisent.
+ [DescribeVpnGateways](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpnGateways.html)
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
+ Utilisez des opérations d'API de service pour collecter les applications AWS Marketplace là où les tables de routage les utilisent.
+ [DescribeRouteTables](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeRouteTables.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à planifier votre mise en réseau](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [Recommandations de résilience AWS Direct Connect](https://aws.amazon.com/directconnect/resiliency-recommendation/)
+ [AWS Marketplace pour l'infrastructure réseau](https://aws.amazon.com/marketplace/b/2649366011)
+ [Livre blanc sur les options de connectivité Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connectivité réseau haute disponibilité de plusieurs centres de données](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Utilisation de connexions VPN de site à site redondantes pour assurer le basculement](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNConnections.html)
+ [Utilisation de la boîte à outils Direct Connect Resiliency Toolkit pour démarrer](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ [Points de terminaison d'un VPC et services de point de terminaison de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Qu'est-ce qu'Amazon VPC ?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Qu'est-ce que Transit Gateway ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Qu'est-ce qu'AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html)
+ [Utilisation des passerelles Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP03 S'assurer que l'allocation des sous-réseaux IP tient compte de l'expansion et de la disponibilité
Les plages d'adresses IP de Amazon VPC doivent être assez grandes pour répondre aux exigences de charges de travail, y compris en prévision d'une expansion et de l'allocation d'adresses IP aux sous-réseaux sur les zones de disponibilité. Cela inclut les équilibreurs de charge, les instances EC2 et les applications basées sur conteneur.
Lorsque vous planifiez votre topologie de réseau, la première étape consiste à définir l'espace d'adressage IP lui-même. Des plages d'adresses IP privées (conformément aux directives RFC 1918) doivent être allouées pour chaque VPC. Vous devez remplir les exigences suivantes dans le cadre de ce processus :
+ Autorisez un espace d'adressage IP pour plus d'un VPC par région.
+ Au sein d'un VPC, prévoyez de l'espace supplémentaire pour plusieurs sous-réseaux couvrant plusieurs zones de disponibilité.
+ Laissez toujours de l'espace de bloc CIDR non utilisé au sein d'un VPC pour une future expansion.
+ Assurez-vous qu'il existe un espace d'adressage IP pour répondre aux besoins de tout parc transitoire d'instances EC2 que vous pourriez utiliser, comme les parcs d'instances Spot pour Machine Learning, les clusters Amazon EMR ou Amazon Redshift.
+ Remarque : les quatre premières adresses IP et la dernière adresse IP dans le bloc CIDR de chaque sous-réseau sont réservées et ne peuvent pas être utilisées.
+ Vous devez planifier le déploiement de grands blocs CIDR pour votre VPC. Notez que le bloc CIDR initial du VPC alloué à votre VPC ne peut pas être modifié ou supprimé, mais vous pouvez ajouter des blocs CIDR non superposés au VPC. Les CIDR IPv4 de sous-réseau ne sont pas modifiables, mais les CIDR IPv6 le sont. Gardez à l'esprit que le déploiement du plus grand VPC possible (/16) représente plus de 65 000 adresses IP. Dans l'espace d'adressage IP 10.x.x.x de base uniquement, vous pouvez mettre en service 255 VPC de ce type. Par conséquent, il est préférable d’avoir un système surdimensionné que sous-dimensionné pour faciliter la gestion de vos VPC.
**Anti-modèles courants :**
+ Création de petits VPC.
+ Création de petits sous-réseaux, puis ajout de sous-réseaux aux configurations au fur et à mesure que vous développez.
+ Estimation incorrecte du nombre d'adresses IP qu'un Elastic Load Balancer peut utiliser.
+ Déploiement de nombreux équilibreurs de charge à trafic élevé dans les mêmes sous-réseaux.
**Avantages liés au respect de cette bonne pratique :** Ces tailles sont la garantie que vous pouvez prendre en charge la croissance de vos charges de travail et continuer à fournir une disponibilité au fur et à mesure de votre mise à l'échelle.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Planifiez votre réseau en prévision de votre croissance, de la conformité réglementaire et de son intégration avec d'autres composants. La croissance peut être sous-estimée, la conformité réglementaire peut changer, et les acquisitions ou les connexions à des réseaux privés peuvent être difficiles à implémenter sans une planification appropriée.
+ Sélectionnez les régions et Comptes AWS pertinents en fonction de vos exigences de services, de la latence, des exigences réglementaires et de reprise après sinistre (DR).
+ Identifiez vos besoins pour les déploiements VPC régionaux.
+ Identifiez la taille des VPC.
+ Déterminez si vous allez déployer une connectivité multi-VPC.
+ [Qu'est-ce que Transit Gateway ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
+ [Connectivité multi-VPC dans un seule région](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ Déterminez si vous avez besoin d'une mise en réseau séparée pour les exigences réglementaires.
+ Rendez vos VPC aussi larges que possible. Le bloc d'adresse CIDR du VPC initial alloué à votre VPC ne peut pas être modifié ou supprimé, mais vous pouvez ajouter des blocs d'adresse CIDR non superposés au VPC. Cela peut toutefois fragmenter vos plages d'adresses.
+ Rendez vos VPC aussi larges que possible. Le bloc d'adresse CIDR du VPC initial alloué à votre VPC ne peut pas être modifié ou supprimé, mais vous pouvez ajouter des blocs d'adresse CIDR non superposés au VPC. Cela peut toutefois fragmenter vos plages d'adresses.
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à planifier votre mise en réseau](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace pour l'infrastructure réseau](https://aws.amazon.com/marketplace/b/2649366011)
+ [Livre blanc sur les options de connectivité Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connectivité réseau haute disponibilité de plusieurs centres de données](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Connectivité multi-VPC dans un seule région](https://aws.amazon.com/answers/networking/aws-single-region-multi-vpc-connectivity/)
+ [Qu'est-ce qu'Amazon VPC ?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP04 Préférer les topologies en étoile au maillage « many-to-many »
Si plus de deux espaces d'adresses réseau (par exemple, des VPC et des réseaux sur site) sont connectés via l'appairage de VPC, AWS Direct Connect ou un VPN, utilisez un modèle en étoile, comme celui fourni par AWS Transit Gateway.
Si vous n'avez que deux réseaux de ce type, vous pouvez simplement les connecter l'un à l'autre, mais à mesure que le nombre de réseaux augmente, la complexité de ces connexions maillées devient intenable. AWS Transit Gateway fournit un modèle en étoile facile à gérer, permettant d'acheminer le trafic sur vos différents réseaux.
![\[Diagramme montrant la non-utilisation d'AWS Transit Gateway\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/without-transit-gateway.png)
![\[Diagramme montrant l'utilisation d'AWS Transit Gateway\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/with-transit-gateway.png)
**Anti-modèles courants :**
+ Utilisation de l'appairage de VPC pour connecter plus de deux VPC.
+ Établissement de plusieurs séances BGP pour chaque VPC afin d'établir une connectivité couvrant les Virtual Private Cloud (VPC) répartis sur plusieurs Régions AWS.
**Avantages liés au respect de cette bonne pratique :** La complexité de ces connexions maillées devient intenable au fur et à mesure que le nombre de réseaux augmente. AWSTransit Gateway fournit un modèle en étoile facile à gérer, permettant d'acheminer le trafic entre vos différents réseaux.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Préférez les topologies en étoile au maillage « many-to-many ». Si plus de deux espaces d'adresses réseau (par exemple, des VPC et des réseaux sur site) sont connectés via l'appairage de VPC, AWS Direct Connect ou un VPN, utilisez un modèle en étoile, comme celui fourni par AWS Transit Gateway.
+ Quand il s’agit de seulement deux de ces réseaux, vous pouvez simplement les connecter l'un à l'autre, mais à mesure que le nombre de réseaux augmente, la complexité de ces connexions maillées devient intenable. AWS Transit Gateway fournit un modèle en étoile facile à gérer, permettant d'acheminer le trafic sur vos différents réseaux.
+ [Qu'est-ce que Transit Gateway ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à planifier votre mise en réseau](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace pour l'infrastructure réseau](https://aws.amazon.com/marketplace/b/2649366011)
+ [Connectivité réseau haute disponibilité de plusieurs centres de données](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Points de terminaison d'un VPC et services de point de terminaison de VPC (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
+ [Qu'est-ce qu'Amazon VPC ?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Qu'est-ce que Transit Gateway ?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# REL02-BP05 Appliquer des plages d'adresses IP privées sans chevauchement dans tous les espaces d'adressage privés où ils sont connectés
Les plages d'adresses IP de chacun de vos VPC ne doivent pas se chevaucher lorsqu'elles sont appairées ou connectées via VPN. De même, vous devez éviter les conflits d'adresses IP entre un VPC et des environnements sur site, ou avec d'autres fournisseurs de cloud que vous utilisez. Vous devez également disposer d'un moyen d'allouer des plages d'adresses IP privées lorsque cela est nécessaire.
Un système de gestion des adresses IP (IPAM) peut vous y aider. Plusieurs IPAM sont disponibles sur AWS Marketplace.
**Anti-modèles courants :**
+ Utilisation de la même plage d'adresses IP dans votre VPC que sur site ou dans votre réseau d'entreprise.
+ Non suivi des plages d'adresses IP des VPC utilisés pour déployer vos charges de travail.
**Avantages liés au respect de cette bonne pratique :** La planification active de votre réseau garantit que vous n'avez pas plusieurs occurrences de la même adresse IP dans les réseaux interconnectés. Cela empêche les problèmes de routage de se produire dans certaines parties de la charge de travail qui utilisent les différentes applications.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Surveillez et gérez votre utilisation CIDR. Évaluez votre utilisation potentielle sur AWS, ajoutez des plages CIDR à des VPC existants et créez des VPC pour autoriser une croissance d'utilisation planifiée.
+ Capturez votre consommation CIDR actuelle (par exemple, les VPC et les sous-réseaux).
+ Utilisez des opérations d'API de service pour collecter la consommation CIDR actuelle.
+ Capturez l'utilisation actuelle de votre sous-réseau.
+ Utilisez des opérations d'API de service pour collecter les sous-réseaux par VPC dans chaque région.
+ [DescribeSubnets](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSubnets.html)
+ Enregistrez l'utilisation actuelle.
+ Déterminez si vous avez créé des plages d'adresses IP se chevauchant.
+ Calculez la capacité inutilisée.
+ Identifiez les plages d'adresses IP qui se chevauchent. Vous pouvez soit migrer vers une nouvelle plage d'adresses, soit utiliser les appliances de traduction de port et de réseau (NAT) d'AWS Marketplace si vous avez besoin de connecter les plages qui se chevauchent.
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à planifier votre mise en réseau](https://aws.amazon.com/partners/find/results/?keyword=network)
+ [AWS Marketplace pour l'infrastructure réseau](https://aws.amazon.com/marketplace/b/2649366011)
+ [Livre blanc sur les options de connectivité Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html)
+ [Connectivité réseau haute disponibilité de plusieurs centres de données](https://aws.amazon.com/answers/networking/aws-multiple-data-center-ha-network-connectivity/)
+ [Qu'est-ce qu'Amazon VPC ?](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
+ [Qu'est-ce qu'IPAM ?](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)](https://youtu.be/fnxXNZdf6ew)
+ [AWS re:Invent 2019: AWS Transit Gateway reference architectures for many VPCs (NET406-R1)](https://youtu.be/9Nikqn_02Oc)
# Architecture de charge de travail
**Topics**
+ [REL 3 Comment concevoir l'architecture de service de votre charge de travail ?](w2aac19b9b7b5.md)
+ [REL 4 Comment concevoir des interactions dans un système distribué pour éviter les défaillances ?](w2aac19b9b7b7.md)
+ [REL 5 Comment concevoir des interactions dans un système distribué pour atténuer ou résister aux défaillances ?](w2aac19b9b7b9.md)
# REL 3 Comment concevoir l'architecture de service de votre charge de travail ?
Créez des charges de travail hautement évolutives et fiables à l'aide d'une architecture orientée service (SOA) ou d'une architecture de microservices. La SOA consiste à rendre les composants logiciels réutilisables via les interfaces de service. L'architecture des microservices va plus loin, en particulier en rendant les composants plus petits et plus simples.
**Topics**
+ [REL03-BP01 Choisir comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Choisir comment segmenter votre charge de travail
La segmentation de la charge de travail est importante lorsqu'il s'agit de déterminer les exigences de résilience de votre application. L'architecture monolithique doit être évitée dans la mesure du possible. À la place, réfléchissez bien aux composants de l'application capables d'être divisés en microservices. Selon les exigences de votre application, il peut s'agir d'une combinaison d'une architecture orientée services et de microservices dans la mesure du possible. Les charges de travail capables d'absence d'état sont davantage en mesure d'être déployées en tant que microservices.
**Résultat souhaité :** Les charges de travail doivent être supportables, évolutives et aussi faiblement couplées que possible.
Lorsque vous choisissez comment segmenter votre charge de travail, comparez les avantages aux complexités. Ce qui convient pour un nouveau produit en course pour un premier lancement est différent de ce dont a besoin une charge de travail conçue pour augmenter d'échelle. Lors de la refactorisation d'une architecture monolithique existante, vous devez évaluer comment l'application prendra en charge une décomposition vers l'absence d'état. La division de services en microservices permet aux petites équipes bien définies de les développer et les gérer. Toutefois, les services plus petits peuvent créer des complexités dont une latence supérieure, un débogage plus complexe et une charge opérationnelle accrue.
**Anti-modèles courants :**
+ La version [microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) est une situation dans laquelle les composants atomiques deviennent si interdépendants que l'échec de l'un d'entre eux résulte en un échec encore plus important, ce qui rend les composants aussi rigides et fragiles qu'une architecture monolithique.
**Avantages liés au respect de cette pratique :**
+ L'utilisation de segments plus petits permet une plus grande agilité, une plus grande flexibilité organisationnelle et une évolutivité.
+ L'impact réduit des interruptions de service.
+ Les composants de l'application peuvent avoir différentes exigences de disponibilité, pouvant être pris en charge par une segmentation plus atomique.
+ Des responsabilités bien définies pour les équipes prenant en charge la charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Élevé
## Directives d'implémentation
Choisissez votre type d'architecture en fonction de la façon dont vous segmenterez votre charge de travail. Choisissez une architecture orientée service (SOA) ou une architecture de microservices (ou, dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer avec une architecture monolithe, vous devez vous assurer qu'elle est modulaire et peut évoluer vers une SOA ou vers des microservices à mesure que votre produit se développe avec son adoption par les utilisateurs. Une SOA et une architecture de microservices offrent une segmentation plus petite. Si elle est préférable en tant qu'architecture moderne évolutive et fiable, il faut prendre en compte des compromis, notamment lors du déploiement d'une architecture de microservices.
Le principal compromis est que vous avez maintenant une architecture pour le calcul distribué qui peut compliquer le respect des exigences en matière de latence des utilisateurs et qui complexifie le suivi et le débogage des interactions des utilisateurs. AWS X-Ray peut vous aider à résoudre ce problème. Un autre effet à prendre en compte est la hausse de la complexité opérationnelle à mesure que vous augmentez le nombre d'applications que vous gérez, ce qui nécessite le déploiement de plusieurs composants indépendants.
![\[Schéma comparant les architectures monolithique, orientée services et de microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Étapes d'implémentation
+ Déterminer l'architecture adaptée pour refactoriser ou créer votre application. SOA et les microservices offrent respectivement une segmentation plus petite, ce qui est préférable pour une architecture moderne évolutive et fiable. SOA peut constituer un bon compromis pour parvenir à une segmentation plus réduite tout en évitant certaines des complexités des microservices. Pour en savoir plus, voir [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si votre charge de travail est appropriée et que votre organisation peut la prendre en charge, vous devez utiliser une architecture de microservices pour obtenir la meilleure agilité et la meilleure fiabilité. Pour en savoir plus, voir [Implémentation des microservices sur AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenir compte du modèle [*Figuier étrangleur* pour](https://martinfowler.com/bliki/StranglerFigApplication.html) refactoriser une architecture monolithique en composants plus petits. Cela implique de remplacer petit à petit des composants d'une application spécifique par de nouveaux services et applications. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) agit comme le point de départ de la refactorisation incrémentielle. Pour en savoir plus, voir [Migrer sans interruption vers des charges de travail existantes sur site à l'aide d'un modèle Figuier étrangleur](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implémentation d'une architecture de microservices peut exiger un mécanisme de découverte de service pour permettre à ces services distribués de communiquer entre eux. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) peut être utilisé avec des architectures orientées service afin de fournir une découverte et un accès fiables aux services. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) peut également être utilisé pour la découverte dynamique de service basée sur un DNS.
+ Si vous migrez d'une architecture monolithique vers une architecture orientée service, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) peut combler le fossé en tant que bus de services lors de la reconception des applications existantes dans le cloud.
+ Pour les architectures monolithiques existantes avec une base de données partagée unique, choisissez comment réorganiser les données en segments plus petits. Vous pouvez les réorganiser par unité commerciale, modèle d'accès ou structure de données. À ce stade du processus de refactorisation, vous devez choisir d'utiliser un type de base de données relationnelle ou non relationnelle. Pour en savoir plus, voir [De SQL à NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Niveau d'effort du plan d'implémentation :** Élevé
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité](rel_service_architecture_business_domains.md)
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Qu'est-ce que l'architecture orientée service ?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Qu'est-ce qu'AWS App Mesh ?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemples connexes :**
+ [Atelier sur la modernisation itérative des applications](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vidéos connexes :**
+ [Offrir l'excellence avec l'architecture de microservices sur AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Créer des services axés sur des domaines d'activité et la fonctionnalité
Une architecture orientée services (SOA) crée des services avec des fonctions bien définies dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte délimité pour limiter ces éléments de façon à ce que chaque service fasse une seule chose. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permettent également une mise à l'échelle organisationnelle plus facile.
Lors de la conception d'une architecture de microservices, il est intéressant d'utiliser la conception pilotée par le domaine (DDD) pour modéliser le problème métier à l'aide d'entités. Par exemple, pour le site Amazon.com, les entités peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise. Ensuite, le modèle est subdivisé en modèles plus petits à l'aide du [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)dans lequel les entités qui partagent des fonctions et des attributs similaires sont regroupées. Par conséquent, si nous reprenons l'exemple Amazon.com, le colis, la livraison et le calendrier feraient partie du contexte d'expédition, tandis que le prix, la remise et la devise appartiendraient au contexte de tarification. La divisison en contextes permet de faire émerger un modèle de délimitation des microservices.
![\[Modèle expliquant comment délimiter les microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/building-services.png)
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Concevez votre charge de travail en fonction de vos domaines d'activité et de leurs fonctionnalités respectives. En vous concentrant sur des fonctionnalités spécifiques, vous pouvez différencier les exigences de fiabilité des différents services et cibler les investissements avec plus de précision. Un problème commercial concis et une petite équipe associée à chaque service permet également une mise à l'échelle organisationnelle plus facile.
+ Effectuez une analyse de domaine pour définir une conception orientée domaine (DDD) pour votre charge de travail. Ensuite, vous pouvez choisir un type d'architecture pour répondre aux besoins de votre charge de travail.
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Décomposez vos services en composants aussi petits que possible. Avec l'architecture de microservices, vous pouvez séparer votre charge de travail en composants ayant la fonctionnalité minimale favorisant une mise à l'échelle organisationnelle et l'agilité.
+ Définissez l'API pour la charge de travail ainsi que ses objectifs de conception, ses limites et toutes autres considérations liées à son utilisation.
+ Définissez l'API
+ La définition de l'API doit tenir compte de la croissance et prévoir des paramètres supplémentaires.
+ Définissez les disponibilités conçues.
+ Votre API peut avoir plusieurs objectifs de conception pour différentes fonctions.
+ Établir des limites
+ Utilisez des tests pour définir les limites des capacités de votre charge de travail.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans « Domain-Driven Design: Tackling Complexity in the Heart of Software »](https://www.amazon.com/gp/product/0321125215)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Fournir des contrats de service par API
Les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par la machine, des limites de taux et des attentes en matière de performance. Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts. Le déploiement peut se produire à tout moment, tant que le contrat n'est pas enfreint. L'équipe du fournisseur de services peut utiliser la pile technologique de son choix pour satisfaire aux clauses du contrat d'API. De même, le consommateur du service peut utiliser sa propre technologie.
Les microservices s'appuient sur le concept d'architecture orientée service (SOA) pour créer des services offrant un ensemble minimal de fonctionnalités. Chaque service publie une API et des objectifs de conception, des limites et d'autres considérations pour l'utilisation du service. L'ensemble forme un *contrat* avec les applications appelantes. Ce système permet d'obtenir trois principaux avantages :
+ Le service fait face à un problème commercial concis devant être géré et une petite équipe doit y remédier. Cela permet un meilleur scaling-up organisationnel.
+ L'équipe peut déployer à tout moment, tant qu'elle respecte les exigences de son API et de son autre contrat.
+ Elle peut utiliser la pile technologique de son choix, dès lors qu'elle respecte les exigences de son API et de son autre contrat.
Amazon API Gateway est un service totalement géré qui permet aux développeurs de créer, de publier, de gérer, de surveiller et de sécuriser facilement des API à n'importe quelle échelle. Il gère toutes les tâches liées à l'acceptation et au traitement de plusieurs centaines de milliers d'appels d'API simultanés, notamment la gestion du trafic, le contrôle des autorisations et des accès, la surveillance et la gestion de la version de l'API. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Fournir des contrats de service par API : les contrats de service sont des accords documentés entre les équipes sur l'intégration de service et incluent une définition d'API lisible par machine, des limites de taux et des attentes en termes de performances.
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Une stratégie de gestion des versions permet aux clients de continuer à utiliser l'API existante et de procéder à la migration de leurs applications vers la nouvelle API lorsqu'ils sont prêts.
+ Amazon API Gateway est un service entièrement géré qui permet aux développeurs de créer facilement des API à n'importe quelle échelle. Grâce à OpenAPI Specification (OAS), anciennement appelé Swagger Specification, vous pouvez définir votre contrat d'API et l'importer dans API Gateway. Avec API Gateway, vous pouvez ensuite gérer les versions et déployer les API.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : configuration d'une API REST à l'aide d'OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
# REL 4 Comment concevoir des interactions dans un système distribué pour éviter les défaillances ?
Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants comme des serveurs ou des services. Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence dans ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail. Ces bonnes pratiques empêchent les défaillances et améliorent le temps moyen entre les défaillances (MTBF).
**Topics**
+ [REL04-BP01 Identifier le type de système distribué requis](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implémenter des dépendances couplées faiblement](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Effectuer un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Rendre toutes les réponses idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identifier le type de système distribué requis
Les systèmes matériels distribués en temps réel exigent la fourniture des réponses de manière synchrone et rapide, alors que les systèmes en temps réel souples disposent d'une fenêtre de temps plus importante (en minutes ou plus). Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone. Les systèmes matériels distribués en temps réel ont les exigences de fiabilité les plus strictes.
Les [problèmes les plus complexes inhérents aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) concernent les systèmes distribués en temps réel stricts, également appelés services de requête/réponse. Ce qui les rend difficiles, c'est que les requêtes arrivent de façon imprévisible et que les réponses doivent être données rapidement (par exemple, le client attend activement la réponse). Les serveurs web front-end, le pipeline de commandes, les transactions par carte de crédit, chaque API AWS et la téléphonie en sont des exemples.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Identifiez le type de système distribué requis. Les défis posés par les systèmes distribués sont la latence, la mise à l'échelle, la compréhension des API de réseau, le regroupement et le dégroupement des données et la complexité des algorithmes tels que Paxos. Des cas jadis marginaux et théoriques deviennent monnaie courante au fur et à mesure que les systèmes deviennent de plus en plus grands et distribués.
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Des réponses données de manière synchrone et rapide sont nécessaires pour les systèmes matériels distribués en temps.
+ Les systèmes logiciels en temps réel ont un créneau de temps plus généreux de plusieurs minutes ou plus pour la réponse.
+ Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone.
+ Les systèmes matériels distribués en temps réel ont les exigences de fiabilité les plus strictes.
## Ressources
**Documents connexes :**
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implémenter des dépendances couplées faiblement
Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
Si les modifications apportées à un composant forcent également d'autres composants qui s'appuient sur lui à changer *couplés* lâchement. *Le couplage lâche* rompt cette dépendance de sorte que les composants dépendants n'ont besoin que de connaître l'interface publiée et sa version. La mise en œuvre d'un couplage lâche entre les dépendances permet d'isoler une défaillance dans l'une afin de ne pas en impacter une autre.
Le couplage lâche permet également d'ajouter du code ou des fonctions supplémentaires à un composant tout en minimisant les risques pour les composants qui en dépendent. La capacité de mise à l'échelle est également améliorée, car vous pouvez augmenter ou même modifier l'implémentation sous-jacente de la dépendance.
Pour améliorer encore la résilience par un couplage lâche, dans la mesure du possible, rendez asynchrones les interactions des composants. Ce modèle convient à toute interaction qui ne nécessite pas besoin une réponse immédiate et pour laquelle une confirmation de l’enregistrement d'une requête suffira. Il implique un composant qui génère des événements et un autre qui les consomme. Les deux composants ne s'intègrent pas via une interaction directe point à point, mais généralement via une couche de stockage durable intermédiaire, telle qu'une file d'attente SQS ou une plateforme de données de streaming comme Amazon Kinesis ou AWS Step Functions.
![\[Diagramme affichant les dépendances telles que des systèmes de file d'attente et des équilibreurs de charge couplés faiblement\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Les files d'attente Amazon SQS et les programmes Elastic Load Balancer ne sont que deux façons d'ajouter une couche intermédiaire pour un couplage lâche. Les architectures guidées par les événements peuvent également être conçues dans le AWS Cloud à l'aide d'Amazon EventBridge, qui peut extraire des clients (producteurs d'événements) des services sur lesquels ils s'appuient (clients d'événements). Amazon Simple Notification Service (Amazon SNS) est une solution efficace lorsque vous avez besoin d'une messagerie de type « many-to-many », à haut débit et en mode push. Grâce aux rubriques Amazon SNS, vos systèmes d'édition peuvent diffuser des messages vers un grand nombre de points de terminaison abonnés pour un traitement parallèle.
Bien que les files d'attente offrent plusieurs avantages, dans la plupart des systèmes en temps réel stricts, les requêtes antérieures à un seuil (souvent en secondes) sont considérées comme obsolètes (le client a abandonné et n'attend plus de réponse). En conséquence, elles ne sont pas traitées. De cette façon, les requêtes plus récentes (et probablement toujours valides) peuvent être traitées à la place.
**Anti-modèles courants :**
+ Déploiement d'un singleton dans le cadre d'une charge de travail.
+ Appel direct d'API entre les niveaux de charge de travail sans possibilité de basculement ou de traitement asynchrone de la demande.
**Avantages liés au respect de cette bonne pratique :** Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité. La défaillance d'un composant est isolée des autres.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Implémentez des dépendances couplées faiblement. Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge vous permet de créer des architectures pilotées par les événements, qui sont faiblement couplées et distribuées.
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Si les changements apportés à un composant obligent les autres composants qui en dépendent à changer également, c'est qu'ils sont étroitement liés. Le couplage faible rompt cette dépendance de sorte que les composants de dépendance n'ont besoin que de connaître l'interface publiée et déclinée en version.
+ Rendez les interactions des composants aussi asynchrones que possible. Ce modèle convient à toute interaction qui n'a pas besoin d'une réponse immédiate et pour laquelle un accusé de réception indiquant qu'une demande a été enregistrée suffira.
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Ressources
**Documents connexes :**
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Qu'est-ce qu'Amazon EventBridge ?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Qu'est-ce que Amazon Simple Queue Service ?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Effectuer un travail constant
Les systèmes peuvent échouer en cas de modifications importantes et rapides de la charge. Par exemple, si votre charge de travail effectue une surveillance de l'état de milliers de serveurs, elle doit envoyer chaque fois une charge utile de la même taille (un instantané complet de l'état actuel). Qu'aucun des serveurs ne présente de problème ou qu’ils en connaissent tous, le système de surveillance de l'état effectue un travail constant sans modifications importantes ni rapides.
Par exemple, si le système de vérification de l'état surveille 100 000 serveurs, la charge sur celui-ci est nominale sous le taux de défaillance normalement faible du serveur. En revanche, si un événement majeur rendait la moitié de ces serveurs défectueux, le système de vérification de l'état serait submergé en tentant de mettre à jour les systèmes de notification et de communiquer l'état à ses clients. Le système de vérification de l'état doit donc plutôt envoyer à chaque fois l'instantané complet de l'état actuel. 100 000 états d'intégrité du serveur, chacun représenté par un bit, ne seraient qu'une charge utile de 12,5 Ko. Qu'aucun des serveurs ne présente de problème ou qu'ils en connaissent tous, le système de vérification de l'état effectue un travail constant, et les modifications importantes et rapides ne menacent pas la stabilité du système. C'est ainsi qu'Amazon Route 53 gère les vérifications de l'état des points de terminaison (tels que les adresses IP) pour déterminer comment les utilisateurs finaux sont acheminés vers eux.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Faible
## Directives d'implémentation
+ Effectuer un travail constant : les systèmes peuvent échouer lorsque la charge connaît des changements rapides et importants.
+ Implémentez des dépendances couplées faiblement. Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage faible permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)](https://youtu.be/O8xLxNje30M?t=2482)
+ Pour l'exemple d'un système de vérification de l'état surveillant 100 000 serveurs, concevez les charges de travail de manière à ce que les tailles de charge utile restent constantes, quel que soit le nombre de réussites ou d'échecs.
## Ressources
**Documents connexes :**
+ [Amazon EC2 : garantir l'idempotence](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Rendre toutes les réponses idempotentes
Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande. Un service idempotent permet à un client d'implémenter plus facilement les nouvelles tentatives sans craindre qu'une demande soit traitée plusieurs fois par erreur. Pour ce faire, les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.
Dans un système distribué, il est facile d'effectuer une action au maximum une fois (le client n'effectue qu'une seule demande) ou au moins une fois (continuer à demander jusqu'à ce que le client reçoive la confirmation de la réussite). En revanche, il est difficile de garantir qu'une action est idempotente, c'est-à-dire exécutée une *seule* fois, de sorte que l'exécution de plusieurs demandes identiques a le même effet qu'une seule demande. En utilisant des jetons d'idempotence dans les API, les services peuvent recevoir une demande de mutation une ou plusieurs fois sans créer d'enregistrements dupliqués ou induire des effets secondaires.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Rendez toutes les réponses idempotentes. Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande.
+ Les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.
+ [Garantir l'idempotence Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Ressources
**Documents connexes :**
+ [Garantir l'idempotence Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [L'Amazon Builders' Library : défis liés aux systèmes distribués](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [L'Amazon Builders' Library : fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vidéos connexes :**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (inclut un couplage faible, un travail constant et une stabilité statique)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL 5 Comment concevoir des interactions dans un système distribué pour atténuer ou résister aux défaillances ?
Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants (tels que des serveurs ou des services). Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence sur ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail. Ces bonnes pratiques permettent aux charges de travail de résister aux contraintes ou aux défaillances, de s'en remettre plus rapidement et d'atténuer l'impact de ces déficiences. Il en résulte une amélioration du temps moyen de récupération (MTTR).
**Topics**
+ [REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limiter les demandes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Procéder à une interruption immédiate et limiter les files d'attente](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Définir les délais d'attente du client](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Rendre les services sans état dans la mesure du possible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Mettre en place des leviers d'urgence](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implémenter une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles
Lorsque les dépendances d'un composant ne sont pas saines, le composant lui-même peut continuer de fonctionner, même si de manière dégradée. Par exemple, lorsqu'un appel de dépendance échoue, basculez vers une réponse statique prédéterminée.
Prenons l'exemple d'un service B qui est appelé par le service A et qui, à son tour, appelle le service C.
![\[Schéma affichant le service C qui échoue lorsqu'il est appelé par le service B. Le service B renvoie une réponse dégradée au service A.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Lorsque le service B appelle le service C, il reçoit une erreur ou une expiration de délai. Le service B, sans réponse du service C (et des données qu'il contient) renvoie ce qu'il peut. Il peut s'agir de la dernière valeur correcte mise en cache, ou le service B peut remplacer une réponse statique prédéterminée par celle qu'il aurait reçue du service C. Il peut ensuite renvoyer une réponse dégradée à son mandataire, le service A. Sans cette réponse statique, la défaillance du service C se répercuterait entre les services B et A, ce qui entraînerait une perte de disponibilité.
Selon le facteur multiplicatif de l'équation de disponibilité des dépendances strictes (voir [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), toute diminution de la disponibilité de C a un impact important sur la disponibilité effective de B. En renvoyant la réponse statique, le service B atténue la panne de C et, bien que dégradée, fait en sorte que la disponibilité du service C ressemble à une disponibilité de 100 % (en supposant qu'il renvoie de manière fiable la réponse statique dans des conditions d'erreur). Notez que la réponse statique est une alternative simple au renvoi d'une erreur et n'est pas une tentative de recalcul de la réponse par différents moyens. Ces tentatives reposant sur un mécanisme totalement différent pour tenter d'obtenir le même résultat constituent un comportement de secours et un anti-modèle à éviter.
Un autre exemple de dégradation appropriée est le *modèle de coupe-circuit*. Les stratégies reposant sur de nouvelles tentatives doivent être utilisées lorsque la défaillance est transitoire. Lorsque ce n'est pas le cas et que l'opération est susceptible d'échouer, le modèle de coupe-circuit empêche le client d'exécuter une demande susceptible d'échouer. Lorsque les demandes sont traitées normalement, le disjoncteur est fermé et ne les bloque pas. Lorsque le système distant commence à renvoyer des erreurs ou présente une latence élevée, le coupe-circuit s'ouvre et la dépendance est ignorée ou les résultats sont remplacés par des réponses obtenues plus simplement mais moins complètes (il peut simplement s’agir d’un cache de réponse). De temps à autre, le système tente d'appeler la dépendance pour déterminer si elle est à nouveau disponible. Lorsque cela se produit, le disjoncteur est fermé.
![\[Schéma montrant le disjoncteur dans les états ouvert et fermé.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Outre les états fermés et ouverts affichés dans le diagramme, après une période de temps configurable à l'état ouvert, le coupe-circuit peut passer à l'état semi-ouvert. Dans cet état, il tente régulièrement d'appeler le service à un débit nettement inférieur à la normale. Cette sonde est utilisée pour vérifier l'état du service. Après un certain nombre de succès dans l'état semi-ouvert, le coupe-circuit passe à l’état fermé et les demandes normales reprennent.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Implémentez une dégradation appropriée pour transformer les dépendances matérielles applicables en dépendances logicielles. Lorsque les dépendances d'un composant ne sont pas saines, le composant lui-même peut continuer de fonctionner, même si de manière dégradée. Par exemple, lorsqu'un appel de dépendance échoue, basculez vers une réponse statique prédéterminée.
+ En renvoyant une réponse statique, votre charge de travail atténue les défaillances qui se produisent dans ses dépendances.
+ [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)
+ Détectez le moment auquel l'opération de nouvelle tentative est susceptible d'échouer et empêchez votre client d'effectuer des appels en échec avec le modèle de coupe-circuit.
+ [Coupe-circuit](https://martinfowler.com/bliki/CircuitBreaker.html)
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Coupe-circuit (présentation du coupe-circuit, ouvrage « Release It\$1 »)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard « Release It\$1 Design and Deploy Production-Ready Software »](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [L'Amazon Builders' Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L'Amazon Builders' Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**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)
# REL05-BP02 Limiter les demandes
Limiter les demandes : il s'agit d'un modèle d'atténuation permettant de répondre à une augmentation inattendue de la demande. Certaines demandes sont honorées, mais celles qui dépassent une limite définie sont rejetées et renvoient un message indiquant qu'elles ont été limitées. On attend des clients qu'ils renoncent à leur demande ou qu'ils essaient à nouveau à un taux plus lent.
Vos services doivent être conçus pour gérer une capacité connue de demandes que chaque nœud ou cellule peut traiter. Cette capacité peut être établie grâce à un test de charge. Vous devez ensuite suivre la fréquence d'arrivée des requêtes et si la fréquence d'arrivée temporaire dépasse cette limite, la réponse appropriée est de signaler que la demande a été limitée. Ceci permet à l'utilisateur de réessayer, potentiellement sur un autre nœud/une autre cellule susceptible d'avoir une capacité disponible. Amazon API Gateway fournit des méthodes pour la limitation des demandes. Amazon SQS et Amazon Kinesis peuvent mettre les demandes en mémoire tampon, lisser le taux de demande et réduire la nécessité de limiter les demandes pouvant être traitées de manière asynchrone.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Limiter les demandes. Il s'agit d'un modèle d'atténuation conçu répondre à une augmentation inattendue de la demande. Certaines demandes sont honorées, mais celles qui dépassent une limite définie sont rejetées et renvoient un message indiquant qu'elles ont été limitées. On attend des clients qu'ils renoncent à leur demande ou qu'ils essaient à nouveau à un taux plus lent.
+ Utilisez Amazon API Gateway
+ [Limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [L'Amazon Builders' Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Contrôler et limiter les appels de nouvelle tentative
Utilisez le backoff exponentiel pour réessayer après des intervalles progressivement plus longs. Introduisez l'instabilité pour randomiser ces intervalles de nouvelle tentative et limitez le nombre maximal de nouvelles tentatives.
Les composants types d'un système logiciel distribué incluent les serveurs, les équilibreurs de charge, les bases de données et les serveurs DNS. Ils peuvent tous commencer à générer des erreurs lorsqu’ils sont en fonctionnement et soumis à des défaillances. La technique par défaut de gestion des erreurs consiste à implémenter les nouvelles tentatives côté client. Cette technique augmente la fiabilité et la disponibilité de l'application. Cependant, à grande échelle (et si les clients tentent de relancer l'opération ayant échoué dès qu'une erreur se produit), le réseau peut rapidement devenir saturé par de nouvelles requêtes et mises hors service, chacune en concurrence pour la bande passante réseau. Cela peut entraîner une *tempête de nouvelles tentatives,* ce qui réduira la disponibilité du service. Ce modèle peut continuer de fonctionner jusqu'à une défaillance système complète.
Pour éviter de tels scénarios, des algorithmes de temporisation, comme une temporisation *exponentielle usuelle,* doivent être utilisés. Les algorithmes de temporisation exponentielle diminuent progressivement la vitesse à laquelle les nouvelles tentatives sont exécutées, ce qui évite la congestion du réseau.
Une multitude de kits SDK et de bibliothèques logicielles, y compris ceux d'AWS, permettent l'implémentation d'une version de ces algorithmes. Cependant, **ne supposez jamais qu'un algorithme de temporisation existe ; testez toujours et vérifiez que c'est le cas.**
Une temporisation simple ne suffit pas à elle seule, car dans les systèmes distribués, tous les clients peuvent s'interrompre simultanément, ce qui crée des clusters de rappels. Dans son billet de blog [Backoff exponentiel et instabilité](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)Marc Brooker explique comment modifier la fonction wait() dans la temporisation exponentielle pour empêcher les clusters de rappels. La solution consiste à ajouter de l' *instabilité* dans la fonction wait(). Pour éviter qu’une nouvelle tentative soit trop longue, les implémentations doivent limiter la temporisation à une valeur maximale.
Enfin, il est important de configurer un *nombre maximal de nouvelles tentatives* ou la durée après laquelle les nouvelles tentatives échoueront tout simplement. Les kits de développement logiciel (SDK) AWS mettent en œuvre cette approche par défaut et peuvent être configurés. Pour les services inférieurs dans la pile, une limite maximale de nouvelles tentatives définie sur zéro ou un limite le risque tout en étant efficace lors de la délégation des nouvelles tentatives aux services supérieurs dans la pile.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Contrôler et limiter les appels de nouvelle tentative. Utilisez le backoff exponentiel pour réessayer après des intervalles progressivement plus longs. Introduisez l'instabilité pour randomiser ces intervalles de nouvelle tentative et limitez le nombre maximal de nouvelles tentatives.
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Les kits SDK Amazon implémentent les nouvelles tentatives et le backoff exponentiel par défaut. Mettez en place une logique similaire dans votre couche de dépendance lors de l'appel de vos propres services dépendants. Déterminez quels sont les délais d'expiration et quand les nouvelles tentatives doivent s'arrêter en fonction de votre cas d'utilisation.
## Ressources
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [L'Amazon Builders' Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L'Amazon Builders' Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Procéder à une interruption immédiate et limiter les files d'attente
Si la charge de travail n'est pas en mesure de répondre avec succès à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et permet au service de récupérer s'il manque de ressources. Si la charge de travail est en mesure de répondre avec succès, mais que le taux de requêtes est trop élevé, utilisez plutôt une file d'attente pour mettre les requêtes en mémoire tampon. N'autorisez toutefois pas les files d'attente longues qui peuvent entraîner le traitement de requêtes obsolètes que le client a déjà abandonnées.
Cette bonne pratique s'applique côté serveur, ou récepteur, de la requête.
Sachez qu'il est possible de créer des files d'attente à différents niveaux d'un système. Elles peuvent également considérablement entraver la capacité de récupération rapide lorsque des demandes obsolètes (qui n'ont plus besoin d'une réponse) sont traitées avant d'apporter une réponse à des demandes plus récentes. Déterminez bien les endroits où se trouvent les files d'attente. Elles se cachent souvent dans les flux de travail ou dans les tâches enregistrées dans une base de données.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Procéder à une interruption immédiate et limiter les files d'attente. Si la charge de travail n'est pas en mesure de répondre avec succès à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et permet au service de récupérer s'il manque de ressources. Si la charge de travail est en mesure de répondre avec succès, mais que le taux de requêtes est trop élevé, utilisez plutôt une file d'attente pour mettre les requêtes en mémoire tampon. N'autorisez toutefois pas les files d'attente longues qui peuvent entraîner le traitement de requêtes obsolètes que le client a déjà abandonnées.
+ Procéder à une interruption immédiate lorsque le service est sous pression.
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limiter les files d'attente. Dans un système basé sur les files d'attente, la charge du message peut s'accumuler dans une longue file d'attente lorsque le traitement s'arrête mais que les messages continuent d'arriver, ce qui augmente le temps de traitement. Le travail peut être achevé trop tard pour que les résultats soient utiles, provoquant ainsi le problème de disponibilité que la file d'attente était censée permettre d'éviter.
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Ressources
**Documents connexes :**
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Interruption immédiate](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [L'Amazon Builders' Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L'Amazon Builders' Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Définir les délais d'attente du client
Définissez les délais d'expiration de manière appropriée, vérifiez-les systématiquement et ne comptez pas sur les valeurs par défaut, car elles sont généralement trop élevées.
Cette bonne pratique s'applique coté client, ou expéditeur, de la requête.
Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. Une valeur trop élevée réduit l'utilité du délai d'attente, car les ressources continuent d'être consommées pendant que le client attend l'expiration du délai. Une valeur trop faible peut générer un trafic accru sur le backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative.
Pour en savoir plus sur l'utilisation par Amazon des délais d'attente, des nouvelles tentatives et de l'interruption avec instabilité, consultez [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Définissez un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus. De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. Une valeur trop élevée réduit l'utilité du délai d'attente, car les ressources continuent d'être consommées pendant que le client attend l'expiration du délai. Une valeur trop faible peut générer un trafic accru sur le backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative.
+ [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Ressources
**Documents connexes :**
+ [Kits SDK AWS : nouvelles tentatives et délais d'attente](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Nouvelles tentatives après erreur et interruptions exponentielles dans AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [L'Amazon Builders' Library : délais d'attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vidéos connexes :**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Rendre les services sans état dans la mesure du possible
Les services ne doivent pas exiger d'état ou doivent décharger un état de telle sorte qu'entre les différentes demandes client, il n'y ait pas de dépendance vis-à-vis des données stockées localement sur disque et en mémoire. Cela permet aux serveurs d'être remplacés à volonté sans avoir d'impact sur la disponibilité. Amazon ElastiCache ou Amazon DynamoDB sont de bonnes destinations pour l'état déchargé.
![\[Dans cette application Web sans état, l'état de la session est déchargé vers Amazon ElastiCache.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Lorsque des utilisateurs ou des services interagissent avec une application, ils exécutent souvent une série d'interactions qui forment une session. Une session correspond aux données uniques des utilisateurs qui persistent entre les requêtes pendant l’utilisation de l'application. Une application sans état n'a pas besoin de connaître les interactions précédentes et ne stocke pas d'informations de session.
Lorsqu'une application est conçue pour être sans état, vous pouvez utiliser des services de calcul sans serveur, comme AWS Lambda ou AWS Fargate.
Outre le remplacement du serveur, les applications sans état ont également pour avantage de pouvoir être mises à l'échelle horizontalement, car toutes les ressources de calcul disponibles (telles que les instances EC2 et les fonctions AWS Lambda) peuvent répondre à n'importe quelle requête.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Rendre vos applications sans état. Les applications sans état permettent une mise à l'échelle horizontale et tolèrent la défaillance d'un nœud individuel.
+ Supprimez les états qui peuvent être stockés dans les paramètres de demande.
+ Après avoir vérifié si l'état est requis, déplacez n'importe quel suivi d'état vers un cache ou un magasin de données multizone résistant comme Amazon ElastiCache, Amazon RDS, Amazon DynamoDB ou une autre solution de données distribuée. Enregistrez un état qui n'a pas pu être déplacés vers des magasins de données résilient.
+ Certaines données (comme les cookies) peuvent être transmises dans les en-têtes ou les paramètres de requête
+ Réfactorisez afin de supprimer l'état qui peut rapidement être transmis dans les requêtes
+ Certaines données ne sont pas forcément nécessaires pour certaines requêtes et peuvent être récupérées à la demande.
+ Supprimez les données qui peuvent être récupérées de manière asynchrone.
+ Choisissez un magasin de donnée qui répond aux exigences relatives à l'état requis.
+ Pensez à avoir une base de données NoSQL pour les données non relationnelles.
## Ressources
**Documents connexes :**
+ [L'Amazon Builders' Library : éviter le basculement dans les systèmes distribués](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [L'Amazon Builders' Library : éviter les retards de file d'attente insurmontables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [L'Amazon Builders' Library : défis et stratégies de mise en cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Mettre en place des leviers d'urgence
Les leviers d'urgence sont des processus rapides qui peuvent réduire l'impact sur la disponibilité de votre charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Mettre en place des leviers d'urgence. Il s'agit de processus rapides qui peuvent atténuer l'impact sur la disponibilité de votre charge de travail. Ils peuvent être exploités en l'absence d'une cause racine. Un levier d'urgence idéal réduit à zéro la charge cognitive sur les résolveurs en fournissant des critères d'activation et de désactivation entièrement déterministes. Les leviers sont souvent manuels, mais ils peuvent également être automatisés.
+ Voici quelques exemples de leviers :
+ Bloquer tout le trafic des robots
+ Diffuser des pages statiques au lieu de dynamiques
+ Réduire la fréquence des appels vers une dépendance
+ Limiter les appels à partir des dépendances
+ Conseils pour implémenter et utiliser des leviers d'urgence
+ Lorsque les leviers sont activés, faites MOINS, pas plus.
+ Gardez la tâche simple, évitez les comportements bimodaux.
+ Testez régulièrement vos leviers.
+ Tels sont des exemples d'actions qui NE sont PAS des leviers d'urgence.
+ Ajouter de la capacité
+ Appelez les propriétaires de services des clients qui dépendent de votre service et demandez-leur de réduire les appels.
+ Apporter une modification au code et le diffuser
# Gestion des modifications
**Topics**
+ [REL 6 Comment surveiller les ressources de charges de travail ?](w2aac19b9b9b5.md)
+ [REL 7 Comment concevoir votre charge de travail pour qu'elle s'adapte aux évolutions de la demande ?](w2aac19b9b9b7.md)
+ [REL 8 Comment implémenter les modifications ?](w2aac19b9b9b9.md)
# REL 6 Comment surveiller les ressources de charges de travail ?
Les journaux et les métriques sont de puissants outils pour obtenir informations sur l'état de votre charge de travail. Vous pouvez configurer votre charge de travail de sorte à surveiller les journaux et les métriques et envoyer des notifications lorsque les seuils sont franchis ou que des événements significatifs se produisent. La surveillance permet à votre charge de travail de reconnaître quand des seuils de faible performance sont franchis ou quand des défaillances se produisent, en vue de sa reprise automatique.
**Topics**
+ [REL06-BP01 Surveiller tous les composants de la charge de travail (génération)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 Définir et calculer des métriques (agrégation)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL06-BP04 Automatiser les réponses (traitement et alarmes en temps réel)](rel_monitor_aws_resources_automate_response_monitor.md)
+ [REL06-BP05 Analytique](rel_monitor_aws_resources_storage_analytics.md)
+ [REL06-BP06 Procéder à des examens réguliers](rel_monitor_aws_resources_review_monitoring.md)
+ [REL06-BP07 Surveiller la traçabilité complète des demandes via votre système](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 Surveiller tous les composants de la charge de travail (génération)
Surveillez les composants de la charge de travail avec Amazon CloudWatch ou des outils tiers. Surveillez les services AWS avec le tableau de bord AWS Health.
Tous les composants de votre charge de travail doivent être surveillés, y compris le côté utilisateur, la logique métier et les niveaux de stockage. Au besoin, définissez des métriques clés, décrivez leur procédure d'extraction des journaux, puis spécifiez des seuils de déclenchement pour les événements d'alarme correspondants Assurez-vous que les métriques sont pertinentes pour les indicateurs clés de performance (KPI) de votre charge de travail, et utilisez des métriques et des journaux pour identifier les signes avant-coureurs de la dégradation du service. Par exemple, une métrique liée aux résultats commerciaux, telle que le nombre de commandes traitées avec succès par minute, peut indiquer des problèmes de charge de travail plus rapidement qu'une métrique technique, telle que l'utilisation du processeur. Utilisez le tableau de bord AWS Health pour obtenir une vue personnalisée des performances et de la disponibilité des services AWS sous-jacents à vos ressources AWS.
La surveillance dans le cloud offre de nouvelles opportunités. La plupart des fournisseurs de cloud ont développé des hooks personnalisables et peuvent fournir des informations pour vous aider à surveiller plusieurs couches de votre charge de travail. Des services AWS comme Amazon CloudWatch appliquent des algorithmes statistiques et de machine learning pour analyser en continu les métriques des systèmes et des applications, déterminer les points de référence normaux et détecter les anomalies avec une intervention minimale de l'utilisateur. Les algorithmes de détection d'anomalies tiennent compte de la saisonnalité et des changements de tendance des métriques.
AWS met à disposition une multitude d'informations de surveillance et de journalisation qui peuvent être utilisées pour définir des métriques spécifiques à la charge de travail et des processus de changement de la demande, et pour adopter des techniques de machine learning, quelle que soit l'expertise en ML.
En outre, surveillez l'ensemble de vos points de terminaison externes afin de vous assurer qu'ils sont indépendants de votre implémentation de base. Cette surveillance active peut être effectuée avec des transactions synthétiques (parfois appelées *tests canary utilisateur*, mais à ne pas confondre avec les déploiements canary), qui exécutent périodiquement plusieurs tâches communes correspondant aux actions effectuées par les clients de la charge de travail. Maintenez ces tâches de courte durée et veillez à ne pas surcharger votre charge de travail pendant les tests. Amazon CloudWatch Synthetics vous permet de [créer des tests canary synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) pour surveiller vos points de terminaison et vos API. Vous pouvez également combiner les nœuds de clients synthétiques Canari avec la console AWS X-Ray pour identifier les scripts Canari synthétiques qui rencontrent des erreurs, des pannes ou des taux de limitation au cours de la période sélectionnée.
**Résultat souhaité :**
Collectez et utilisez des métriques critiques de tous les composants de la charge de travail pour garantir la fiabilité de la charge de travail et une expérience utilisateur optimale. Détecter qu'une charge de travail n'atteint pas les résultats vous permet de déclarer rapidement un sinistre et de vous remettre d'un incident.
**Anti-modèles courants :**
+ Surveillance limitée aux interfaces externes de votre charge de travail.
+ Ne pas générer de métriques spécifiques à la charge de travail et s'appuyer uniquement sur les métriques qui vous sont fournies par les services AWS utilisés par votre charge de travail.
+ Utiliser uniquement des métriques techniques dans votre charge de travail et ne surveiller aucune métrique liée aux KPI non techniques auxquels la charge de travail contribue.
+ S'appuyer sur le trafic de production et de simples vérifications de l'état pour surveiller et évaluer l'état de la charge de travail.
**Avantages liés au respect de cette bonne pratique :** La surveillance à tous les niveaux de votre charge de travail vous permet d'anticiper et de résoudre plus rapidement les problèmes dans les composants qui constituent la charge de travail.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
1. **Activer la journalisation si disponible.** Les données de surveillance doivent être obtenues à partir de tous les composants des charges de travail. Activez la journalisation supplémentaire, telle que les journaux d'accès S3, et autorisez votre charge de travail à consigner des données qui lui sont spécifiques. Collectez des métriques pour les moyennes d'UC, d'E/S réseau et d'E/S disque à partir de services comme Amazon ECS, Amazon EKS, Amazon EC2, Elastic Load Balancing, AWS Auto Scaling et Amazon EMR. Consulter [Services AWS publiant des métriques CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) pour obtenir une liste des services AWS qui publient des métriques CloudWatch.
1. **Passez en revue toutes les métriques par défaut et explorez toutes les lacunes de collecte de données.** Chaque service génère des métriques par défaut. La collecte des métriques par défaut vous permet de mieux comprendre les dépendances entre les composants de charge de travail et sur la manière dont la fiabilité et les performances des composants affectent la charge de travail. Vous pouvez également créer et [publier vos propres métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) vers CloudWatch à l'aide d'AWS CLI ou d'une API. Évaluez
1. **toutes les métriques pour décider celles pour lesquelles envoyer des alertes pour chaque service AWS de votre charge de travail.** Vous pouvez choisir de sélectionner un sous-ensemble de métriques qui ont un impact majeur sur la fiabilité de la charge de travail. Se concentrer sur les métriques critiques et le seuil vous permet d'affiner le nombre [d'information](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) et peut aider à minimiser les faux positifs.
1. **Définissez des alertes et le processus de récupération de votre charge de travail après le déclenchement de l'alerte.** La définition d'alertes vous permet de notifier, de faire remonter et de suivre rapidement les étapes nécessaires pour vous remettre d'un incident et atteindre votre objectif de temps de récupération (RTO) prescrit. Vous pouvez utiliser [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) pour appeler des flux de travail automatisés et lancer des procédures de récupération en fonction de seuils définis.
1. **Explorez l'utilisation de transactions synthétiques pour collecter des données pertinentes sur l'état des charges de travail.** La surveillance synthétique suit les mêmes routes et effectue les mêmes actions qu'un client, ce qui vous permet de vérifier en permanence l'expérience client même lorsque vous n'avez aucun trafic client sur vos charges de travail. En utilisant [les transactions synthétiques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), vous pouvez découvrir les problèmes avant vos clients.
## Ressources
**Bonnes pratiques associées :**
+ [REL11-BP03 Automatiser la réparation sur toutes les couches](rel_withstand_component_failures_auto_healing_system.md)
**Documents connexes :**
+ [Premiers pas avec le tableau de bord AWS Health : état de votre compte](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [Services AWS publiant des métriques CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Journaux d'accès pour votre Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Journaux d'accès pour votre Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [Accès à Amazon CloudWatch Logs pour AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [Journalisation de l'accès au serveur Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Activer les journaux d'accès pour votre Classic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Exportation de données de journal vers Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [Installer l'agent CloudWatch sur une instance Amazon EC2](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [Publication des métriques personnalisées](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Fonctionnement des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Utilisation des métriques Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Que sont les Amazon CloudWatch Logs ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**Guides de l'utilisateur :**
+ [Création d'un journal d'activité](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [Surveillance des métriques de mémoire et de disque pour les instances Linux Amazon Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Utiliser CloudWatch Logs avec des instances de conteneur](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Journaux de flux VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Qu'est-ce qu'Amazon DevOps Guru ?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Qu'est-ce que AWS X-Ray ?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**Blogs connexes :**
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**Exemples et ateliers connexes :**
+ [Ateliers AWS Well-Architected : Excellence opérationnelle - Surveillance des dépendances](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Atelier sur l'observabilité](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 Définir et calculer des métriques (agrégation)
Stockez les données des journaux et appliquez des filtres si nécessaire pour calculer les métriques, en particulier le décompte d'un événement de journal spécifique ou la latence calculée à partir des horodatages des événements de journaux.
Amazon CloudWatch et Amazon S3 servent de couches principales pour l'agrégation et le stockage. Pour certains services, comme AWS Auto Scaling et Elastic Load Balancing, les métriques par défaut sont fournies par défaut pour la charge du processeur ou la latence moyenne des demandes au sein d'un cluster ou d'une instance. Pour les services de streaming, comme les journaux de flux VPC et AWS CloudTrail, les données d'événement sont transmises à CloudWatch Logs et vous devez définir et appliquer des filtres de métrique pour extraire des métriques à partir des données d'événement. Cela vous donne des données de séries chronologiques, qui peuvent servir d'entrées aux alarmes CloudWatch que vous définissez pour déclencher les alertes.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Définir et calculer des métriques (agrégation). Stockez les données des journaux et appliquez des filtres si nécessaire pour calculer les métriques, en particulier le décompte d'un événement de journal spécifique ou la latence calculée à partir des horodatages des événements de journaux
+ Les filtres de métrique définissent les termes et les modèles à rechercher dans les données de journal lorsqu'elles sont envoyées à CloudWatch Logs. CloudWatch Logs utilise ces filtres de métriques pour transformer les données de journal en métriques numériques CloudWatch que vous pouvez représenter graphiquement ou au niveau desquelles vous pouvez définir une alarme.
+ [Recherche et filtrage des données de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ Utiliser un agent tiers de confiance pour agréger les journaux
+ Suivez les instructions de l'agent tiers. La plupart des produits tiers s'intègrent à CloudWatch et Amazon S3.
+ Certains services AWS peuvent publier des journaux directement dans Amazon S3. Ainsi, si votre principale exigence pour les journaux est le stockage dans Amazon S3, vous pouvez facilement faire en sorte que le service produisant les journaux les envoie directement à Amazon S3 sans configurer d'infrastructure supplémentaire.
+ [Envoi des journaux directement à Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
## Ressources
**Documents connexes :**
+ [Exemples de requêtes Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [Recherche et filtrage des données de journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Envoi des journaux directement à Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP03 Envoyer des notifications (traitement et alarmes en temps réel)
Les organisations qui désirent être informées des événements significatifs reçoivent des notifications lorsque ceux-ci se produisent.
Des alertes également être envoyées à Amazon Simple Notification Service (Amazon SNS), puis être transmises à un certain nombre d'abonnés. Par exemple, Amazon SNS peut transmettre des alertes à un alias d'e-mail afin que les techniciens puissent répondre.
**Anti-modèles courants :**
+ Configuration d'alarmes à un seuil trop bas, ce qui entraîne l'envoi d'un trop grand nombre de notifications.
+ Non-archivage d'alarmes pour une exploration future.
**Avantages liés au respect de cette bonne pratique :** Les notifications (même pour les événements qui peuvent être traités et résolus automatiquement) vous permettent d'enregistrer les événements et de les traiter d'une manière différente à l'avenir.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Effectuer le traitement et l'envoi d'alarme en temps réel. Les organisations qui désirent être informées des événements significatifs reçoivent des notifications lorsque ceux-ci se produisent.
+ Les tableaux de bord Amazon CloudWatch sont des pages d'accueil personnalisables de la console CloudWatch que vous pouvez utiliser pour surveiller vos ressources dans une seule fenêtre, y compris les ressources réparties sur différentes régions.
+ [Fonctionnement des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Créer une alarme lorsque la métrique dépasse une limite.
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Ressources
**Documents connexes :**
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Utilisation des alarmes Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Fonctionnement des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Utilisation des métriques Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# REL06-BP04 Automatiser les réponses (traitement et alarmes en temps réel)
utilisez l'automatisation pour agir en cas de détection d'événement, par exemple, pour remplacer les composants défectueux.
Les alertes peuvent déclencher des événements AWS Auto Scaling, de sorte que les clusters réagissent aux évolutions de la demande. Les alertes peuvent être envoyées vers Amazon Simple Queue Service (Amazon SQS), qui peut servir de point d'intégration pour les systèmes de tickets tiers. AWS Lambda peut également s'abonner aux alertes et faire profiter les utilisateurs d'un modèle sans serveur asynchrone qui réagit au changement de façon dynamique. AWS Config surveille et enregistre en permanence vos configurations de ressources AWS. Il peut déclencher [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) pour résoudre les problèmes.
Amazon DevOps Guru peut surveiller automatiquement les ressources d'applications pour détecter les comportements anormaux et fournir des recommandations ciblées afin d'accélérer l'identification des problèmes et de réduire les temps de remédiation.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Utilisez Amazon DevOps Guru pour effectuer des actions automatisées. Amazon DevOps Guru peut surveiller automatiquement les ressources d'applications pour détecter les comportements anormaux et fournir des recommandations ciblées afin d'accélérer l'identification des problèmes et de réduire les temps de remédiation.
+ [Qu'est-ce qu'Amazon DevOps Guru ?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ Utilisez AWS Systems Manager pour effectuer des actions automatisées. AWS Config surveille et enregistre en permanence vos configurations de ressources AWS. Il peut déclencher AWS Systems Manager Automation pour résoudre les problèmes.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ Créez et utilisez des documents Systems Manager Automation. Ces documents définissent les actions exécutées par Systems Manager sur vos instances gérées et d'autres ressources AWS lorsqu'une action d'automatisation s'exécute.
+ [Utilisation des documents d'automatisation (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ Amazon CloudWatch envoie les événements de changement d'état de l'alarme à Amazon EventBridge. Créer des règles EventBridge pour automatiser les réponses
+ [Création d'une règle EventBridge qui se déclenche en cas d'événement provenant d'une ressource AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ Créer et exécuter un plan pour automatiser les réponses
+ Faire l'inventaire de toutes vos procédures de réponse aux alertes Vous devez planifier vos réponses d'alerte avant de classer les tâches.
+ Effectuez un inventaire de toutes les tâches avec les actions spécifiques devant être effectuées La plupart de ces actions sont documentées dans les runbooks. Vous devez également disposer de playbooks pour les alertes d'événements inattendus.
+ Examinez les runbooks et les playbooks à la recherche de toutes les actions pouvant être automatisées. En règle générale, toute action qui peut être définie a de grandes chances de pouvoir être automatisée.
+ Classez d'abord les activités sources d'erreurs ou chronophages. La suppression des sources d'erreurs et la réduction du temps de résolution sont plus avantageuses.
+ Établissez un plan pour effectuer l'automatisation. Disposez d'un plan actif pour automatiser les processus et mettre à jour l'automatisation.
+ Examinez les exigences manuelles liées aux possibilités d'automatisation. Remettez en question votre processus manuel et recherchez des possibilités d'automatisation.
## Ressources
**Documents connexes :**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Création d'une règle EventBridge qui se déclenche en cas d'événement provenant d'une ressource AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Qu'est-ce qu'Amazon DevOps Guru ?](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [Utilisation des documents d'automatisation (playbooks)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
# REL06-BP05 Analytique
collectez les fichiers journaux et les historiques de métriques, puis analysez-les pour obtenir des informations plus générales sur les tendances et la charge de travail.
Amazon CloudWatch Logs Insights prend en charge un [langage de requête simple et puissant](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) que vous pouvez utiliser pour analyser les données des journaux. Amazon CloudWatch Logs prend également en charge les abonnements qui permettent aux données de circuler en toute transparence vers Amazon S3, où vous pouvez utiliser Amazon Athena pour interroger les données. Il prend également en charge les requêtes dans une grande variétés de formats. Consulter [Formats de données et SerDes pris en charge](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html) dans le guide de l'utilisateur Amazon Athena pour plus d'informations. Pour analyser des ensembles de fichiers journaux volumineux, vous pouvez exécuter un cluster Amazon EMR pour exécuter des analyses à l'échelle du pétaoctet.
Il existe divers outils fournis par les partenaires AWS et les tiers qui permettent l'agrégation, le traitement, le stockage et l'analyse. Parmi ces outils figurent New Relic, Splunk, Loggly, Logstash, CloudHealth et Nagios. Cependant, la génération en dehors du système et des journaux d'applications est propre à chaque fournisseur de cloud, et généralement, spécifique à chaque service.
Un partie souvent négligée de la surveillance des processus concerne la gestion des données. Vous devez déterminer les exigences de rétention des données de surveillance, puis appliquer des stratégies de cycle de vie en conséquence. Amazon S3 prend en charge la gestion du cycle de vie au niveau du compartiment S3. Cette gestion du cycle de vie peut être appliquée différemment à d'autres chemins dans le compartiment. Vers la fin du cycle de vie, vous pouvez transférer des données dans Amazon Glacier pour un stockage à long terme, puis les laisser expirer une fois la fin de la période de rétention terminée. La classe de stockage S3 Intelligent-Tiering est conçue pour optimiser les coûts en transférant automatiquement les données vers le niveau d'accès le plus économique, sans impact sur les performances ni surcharge opérationnelle.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ CloudWatch Logs vous permet de rechercher et d'analyser de manière interactive vos données de journaux dans Amazon CloudWatch Logs.
+ [Analyse des données des journaux avec CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Exemples de requêtes Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Utiliser Amazon CloudWatch Logs pour envoyer des journaux vers Amazon S3 où vous pouvez les exploiter ou utiliser Amazon Athena pour interroger les données
+ [Comment analyser mes journaux d'accès au serveur Amazon S3 à l'aide d'Athena ?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ Créez une stratégie de cycle de vie S3 pour votre compartiment de journaux d'accès au serveur. Configurez la stratégie de cycle de vie de sorte à supprimer régulièrement les fichiers journaux. Cette suppression permet de réduire la quantité de données analysées par Athena pour chaque requête.
+ [Comment créer une stratégie de cycle de vie pour un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## Ressources
**Documents connexes :**
+ [Exemples de requêtes Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Analyse des données des journaux avec CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Comment créer une stratégie de cycle de vie pour un compartiment S3 ?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Comment analyser mes journaux d'accès au serveur Amazon S3 à l'aide d'Athena ?](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 Procéder à des examens réguliers
Examinez fréquemment comment la surveillance de la charge de travail est mise en œuvre et mettez-la à jour en fonction des événements et des modifications majeurs.
Une surveillance efficace repose sur des métriques commerciales clés. Assurez-vous que ces métriques sont prises en compte dans votre charge de travail au fur et à mesure que les priorités de l’entreprise évoluent.
Auditer votre surveillance vous permet de savoir avec certitude quand une application est conforme à ses objectifs de disponibilité. Pour pouvoir analyser les causes premières, il faut pouvoir découvrir ce qui se passe lorsque des défaillances se produisent. AWS fournit des services qui vous permettent de suivre l'état de vos services lors d'un incident :
+ **Amazon CloudWatch Logs :** vous pouvez stocker vos journaux dans ce service et inspecter leur contenu.
+ **Amazon CloudWatch Logs Insights** : service entièrement géré qui vous permet d'analyser des journaux volumineux en quelques secondes. Il permet des requêtes et des visualisations rapides et interactives.
+ **AWS Config :** permet de voir quelle infrastructure AWS a été utilisée à différents moments.
+ **AWS CloudTrail :** permet de voir quelles API AWS ont été appelées à quel moment et par quel mandataire.
Chez AWS, nous organisons des réunions hebdomadaires pour [examiner les performances opérationnelles](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) et partager les enseignements entre les équipes. Compte tenu du nombre conséquent d'équipes AWS, nous avons créé [The Wheel](https://aws.amazon.com/blogs/opensource/the-wheel/) pour choisir de façon aléatoire une charge de travail à examiner. Le respect d’un rythme régulier pour l’examen des performances opérationnelles et le partager des connaissances améliore la capacité de vos équipes opérationnelles à atteindre des performances supérieures.
**Anti-modèles courants :**
+ Collecte limitée aux métriques par défaut.
+ Définition d'une stratégie de surveillance et sans examen.
+ Absence de discussion relative à la surveillance lorsque des modifications majeures sont déployées.
**Avantages liés au respect de cette bonne pratique :** La vérification régulière de votre surveillance permet d'anticiper les problèmes potentiels, au lieu de réagir aux notifications lorsqu'un problème anticipé se produit réellement.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Créer plusieurs tableaux de bord pour la charge de travail. Vous devez disposer d'un tableau de bord de niveau supérieur qui contient les principales métriques commerciales, ainsi que les métriques techniques que vous avez identifiées comme étant les plus pertinentes pour l'état projeté de la charge de travail au fil de la variation de l'utilisation. Vous devez également avoir des tableaux de bord pour différents niveaux et dépendances d'application qui peuvent être inspectés.
+ [Fonctionnement des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ Planifier et effectuer des vérifications régulières des tableaux de bord de charge de travail. Effectuez une inspection régulière des tableaux de bord. Vous pouvez avoir des cadences différentes selon la profondeur à laquelle vous inspectez.
+ Inspecter les tendances dans les métriques. Comparez les valeurs des métriques aux valeurs historiques pour voir s'il existe des tendances qui peuvent indiquer que quelque chose doit faire l'objet d'une enquête. Voici quelques exemples : augmentation de la latence, diminution de la fonction principale de l'entreprise et augmentation des réponses aux échecs.
+ Inspecter les valeurs atypiques ou les anomalies dans vos métriques. Les moyennes ou les médianes peuvent masquer des valeurs atypiques et des anomalies. Observez les valeurs les plus élevées et les plus faibles pendant la période et examinez les causes des scores extrêmes. L'abaissement de votre définition de l'extrême vous permet de continuer à améliorer l'homogénéité des performances de votre charge de travail au fur et à mesure que vous continuez à éliminer ces causes.
+ Rechercher des changements importants de comportement. Un changement immédiat de quantité ou de direction d'une métrique peut indiquer qu'il y a eu un changement dans l'application ou la présence de facteurs externes pour le suivi desquels vous devez ajouter des métriques supplémentaires.
## Ressources
**Documents connexes :**
+ [Exemples de requêtes Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Fonctionnement des tableaux de bord Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
# REL06-BP07 Surveiller la traçabilité complète des demandes via votre système
Utilisez AWS X-Ray ou des outils tiers afin que les développeurs puissent plus facilement analyser et déboguer des systèmes distribués pour comprendre les performances de leurs applications et de leurs services sous-jacents.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Surveiller la traçabilité complète des demandes via votre système. AWS X-Ray est un service qui collecte des données sur les demandes servies par votre application et fournit des outils que vous pouvez utiliser pour afficher, filtrer et obtenir des informations sur ces données afin d'identifier les problèmes et les circonstances opportunes d'optimisation. Pour toute demande suivie envoyée à votre application, vous pouvez consulter des informations détaillées non seulement sur la demande et la réponse, mais également sur les appels effectués par votre application vers des ressources AWS en aval, des microservices, des bases de données et des API web HTTP.
+ [Qu'est-ce que AWS X-Ray ?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
## Ressources
**Documents connexes :**
+ [Débogage avec Amazon CloudWatch Synthetics et AWS X-Ray](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Un atelier sur l'observabilité](https://observability.workshop.aws/)
+ [L'Amazon Builders' Library : Instrumentation des systèmes distribués au profit de la visibilité opérationnelle](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Utilisation de scripts Canary (Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Qu'est-ce que AWS X-Ray ?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
# REL 7 Comment concevoir votre charge de travail pour qu'elle s'adapte aux évolutions de la demande ?
Une charge de travail évolutive fournit l'élasticité nécessaire pour ajouter ou supprimer automatiquement des ressources de telle sorte qu'elles correspondent étroitement à tout moment à la demande en cours.
**Topics**
+ [REL07-BP01 Utiliser l'automatisation lors de l'obtention des ressources ou de leur mise à l'échelle](rel_adapt_to_changes_autoscale_adapt.md)
+ [REL07-BP02 Obtenir des ressources après la détection d'un problème sur une charge de travail](rel_adapt_to_changes_reactive_adapt_auto.md)
+ [REL07-BP03 Obtenir des ressources après avoir réalisé qu'un plus grand nombre de ressources est nécessaire pour une charge de travail](rel_adapt_to_changes_proactive_adapt_auto.md)
+ [REL07-BP04 Effectuer un test de charge de votre charge de travail](rel_adapt_to_changes_load_tested_adapt.md)
# REL07-BP01 Utiliser l'automatisation lors de l'obtention des ressources ou de leur mise à l'échelle
Lorsque vous remplacez des ressources compromises ou que vous mettez à l'échelle votre charge de travail, automatisez le processus à l'aide de services AWS gérés comme Amazon S3 et AWS Auto Scaling. Vous pouvez également utiliser des outils tiers et les kits SDK AWS pour automatiser la mise à l'échelle.
Les services AWS gérés comprennent Amazon S3, Amazon CloudFront, AWS Auto Scaling, AWS Lambda, Amazon DynamoDB, AWS Fargate et Amazon Route 53.
AWS Auto Scaling vous permet de détecter et de remplacer les instances dégradées. Il offre également la possibilité de créer des plans de mise à l'échelle pour les ressources, notamment les instances [Amazon EC2](https://aws.amazon.com/ec2/) et les parcs Spot, les tâches [Amazon ECS](https://aws.amazon.com/ecs/) les tables et index [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) et les réplicas [Amazon Aurora](https://aws.amazon.com/aurora/) .
Lors de la mise à l'échelle d'instances EC2, veillez à utiliser plusieurs zones de disponibilité (de préférence au moins trois) et à ajouter ou supprimer de la capacité pour maintenir l'équilibre entre ces zones de disponibilité. Les tâches ECS ou les pods Kubernetes (lors de l'utilisation d'Amazon Elastic Kubernetes Service) doivent également être répartis sur plusieurs zones de disponibilité.
Lorsque vous utilisez AWS Lambda, la mise à l'échelle est automatique. Chaque fois qu'une notification d'événement est reçue pour votre fonction, AWS Lambda localise rapidement la capacité disponible dans son parc de calcul et exécute votre code jusqu'à la simultanéité allouée. Vous devez vous assurer que la simultanéité nécessaire est configurée sur la fonction Lambda spécifique et dans Service Quotas.
Amazon S3 se met automatiquement à l'échelle pour gérer les débits de requêtes élevés. Par exemple, votre application peut obtenir au moins 3 500 demandes PUT/COPY/POST/DELETE ou 5 500 requêtes GET/HEAD par seconde et par préfixe partitionné dans un compartiment. Le nombre de préfixes dans un compartiment est illimité. Vous pouvez augmenter vos performances de lecture ou d'écriture en parallélisant les lectures. Par exemple, si vous créez 10 préfixes dans un compartiment Amazon S3 pour paralléliser les lectures, vous pouvez mettre à l'échelle vos performances de lecture sur 55 000 requêtes de lecture par seconde.
Configurez et utilisez Amazon CloudFront ou un réseau de diffusion de contenus (CDN) de confiance Un CDN fournit des temps de réponse plus rapides à l'utilisateur final et répond aux demandes de contenu à partir du cache, ce qui vous évite (dans une certaine mesure) de devoir adapter votre charge de travail.
**Anti-modèles courants :**
+ Implémentation de groupes Auto Scaling pour la réparation automatique sans implémentation de l'élasticité
+ Utilisation de la mise à l'échelle automatique pour répondre aux pics importants du trafic.
+ Déploiement d'applications hautement dynamiques avec élimination de l'option d'élasticité.
**Avantages liés au respect de cette bonne pratique :** L'automatisation élimine le risque d'erreur manuelle lors du déploiement et de la mise hors service des ressources. Elle élimine aussi le risque de dépassement de coûts et de déni de service en raison d'une réponse lente aux besoins de déploiement ou de mise hors service.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Configurer et utiliser AWS Auto Scaling. AWS Auto Scaling permet de surveiller vos applications et d'ajuster automatiquement la capacité pour maintenir des performances stables et prévisibles au coût le plus bas possible. Avec AWS Auto Scaling, vous pouvez configurer la mise à l'échelle des applications pour plusieurs ressources sur plusieurs services.
+ [Qu'est-ce qu'AWS Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ Configurez Auto Scaling sur vos instances Amazon EC2 et vos parcs d'instances Spot, vos tâches Amazon ECS, vos tables et index Amazon DynamoDB, vos réplicas Amazon Aurora et vos appliances AWS Marketplace, le cas échéant.
+ [Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling.](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ Utiliser les opérations d'API de service pour spécifier les alarmes, les stratégies de mise à l'échelle, ainsi que les temps de montée et de baisse de charge
+ Utiliser Elastic Load Balancing. Les équilibreurs de charge peuvent répartir la charge par chemin d'accès ou par connectivité réseau.
+ [Qu'est-ce qu'Elastic Load Balancing ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ Les Application Load Balancers peuvent répartir la charge par chemin.
+ [Qu'est-ce qu'un Application Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ Configurer un Application Load Balancer pour répartir le trafic sur différentes charges de travail selon le chemin d'accès du nom de domaine
+ Les Application Load Balancers peuvent être utilisés pour répartir les charges d'une manière qui s'intègre à AWS Auto Scaling pour gérer la demande.
+ [Utiliser un équilibreur de charge avec un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ Les Network Load Balancers peuvent répartir la charge de travail par connexion.
+ [Qu'est-ce qu'un Network Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ Configurer un Network Load Balancer pour répartir le trafic sur différentes charges de travail à l'aide du TCP ou disposer constamment d'un jeu d'adresses IP pour votre charge de travail
+ Les Network Load Balancers peuvent être utilisés pour répartir les charges d'une manière qui s'intègre à AWS Auto Scaling pour gérer la demande.
+ Utiliser un fournisseur DNS à haut niveau de disponibilité. Les noms DNS permettent à vos utilisateurs de saisir des noms plutôt que des adresses IP pour accéder à vos charges de travail et distribuer ces informations sur une portée précise, en général mondiale, pour les utilisateurs de ces charges de travail.
+ Utiliser Amazon Route 53 ou un fournisseur DNS de confiance.
+ [Qu'est-ce qu'Amazon Route 53 ?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ Utilisez Route 53 pour gérer vos distributions CloudFront et vos équilibreurs de charge.
+ Déterminer les domaines et les sous-domaines que vous allez à gérer
+ Créez des jeux d'enregistrements appropriés à l'aide d'enregistrements ALIAS ou CNAME.
+ [Utilisation des enregistrements](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
+ Utilisez le réseau mondial AWS pour optimiser le chemin de vos utilisateurs vers vos applications. AWS Global Accelerator surveille en permanence l'état des points de terminaison de votre application et redirige le trafic vers des points de terminaison sains en moins de 30 secondes.
+ AWS Global Accelerator est un service qui améliore la disponibilité et les performances de vos applications auprès d'utilisateurs locaux ou internationaux. Il fournit des adresses IP statiques qui font office de point d'entrée fixe aux points de terminaison de votre application dans une ou plusieurs Régions AWS, telles que vos Application Load Balancers, vos Network Load Balancers ou vos instances Amazon EC2.
+ [Qu'est-ce qu'AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ Configurez et utilisez Amazon CloudFront ou un réseau de diffusion de contenus (CDN) de confiance Un réseau de diffusion de contenus peut fournir des temps de réponse des utilisateurs finaux plus rapides et traiter les requêtes de contenu susceptibles de causer une mise à l'échelle inutile de vos charges de travail.
+ [Qu'est-ce que Amazon CloudFront ?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html)
+ Configurez les distributions Amazon CloudFront pour vos charges de travail ou utilisez un CDN tiers.
+ Vous pouvez limiter l'accès à vos charges de travail de sorte qu'elles ne soient accessibles qu'à partir de CloudFront. Pour ce faire, vous pouvez utiliser les plages d'adresses IP pour CloudFront dans vos groupes de sécurité ou vos politiques d'accès des points de terminaison.
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à créer des solutions de calcul automatisées](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling : Fonctionnement des plans de mise à l'échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace : produits utilisables avec Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Utiliser un équilibreur de charge avec un groupe Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html)
+ [Qu'est-ce qu'AWS Global Accelerator ?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Qu'est-ce que Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [Qu'est-ce qu'AWS Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html)
+ [Qu'est-ce que Amazon CloudFront ?](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html?ref=wellarchitected)
+ [Qu'est-ce qu'Amazon Route 53 ?](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)
+ [Qu'est-ce qu'Elastic Load Balancing ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)
+ [Qu'est-ce qu'un Network Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)
+ [Qu'est-ce qu'un Application Load Balancer ?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)
+ [Utilisation des enregistrements](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)
# REL07-BP02 Obtenir des ressources après la détection d'un problème sur une charge de travail
Si la disponibilité est affectée, mettez à l'échelle les ressources de manière réactive si nécessaire, afin de restaurer la disponibilité de la charge de travail.
Vous devez commencer par configurer les vérifications de l'état et les critères de ces vérifications pour indiquer quand la disponibilité est affectée par le manque de ressources. Informez ensuite le personnel approprié qu’il doit mettre à l’échelle manuellement la ressource ou déclenchez l'automatisation pour procéder à une mise à l'échelle automatique.
La mise à l'échelle peut être ajustée manuellement en fonction de votre charge de travail. Par exemple, vous pouvez modifier le nombre d'instances EC2 dans un groupe Auto Scaling ou le débit d'une table DynamoDB via AWS Management Console ou l'interface AWS CLI. Toutefois, l'automatisation doit être utilisée à chaque fois que cela est possible (voir **Utiliser l'automatisation lors de l'obtention des ressources ou de leur mise à l'échelle**).
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Obtenir des ressources après la détection d'un problème sur une charge de travail. Si la disponibilité est affectée, mettez à l'échelle les ressources de manière réactive si nécessaire, afin de restaurer la disponibilité de la charge de travail.
+ Utilisez des plans de mise à l'échelle, qui sont le composant principal d'AWS Auto Scaling, pour configurer un ensemble d'instructions pour la mise à l'échelle de vos ressources. Si vous travaillez avec AWS CloudFormation ou que vous ajoutez des balises aux ressources AWS, vous pouvez configurer des plans de mise à l'échelle pour différents ensembles de ressources, par application. AWS Auto Scaling offre des recommandations de stratégies de mise à l'échelle personnalisées pour chaque ressource. Une fois que vous avez créé votre plan de mise à l'échelle, AWS Auto Scaling combine les méthodes de mise à l'échelle dynamique et prédictive pour prendre en charge votre stratégie de mise à l'échelle.
+ [AWS Auto Scaling : Fonctionnement des plans de mise à l'échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Amazon EC2 Auto Scaling vous permet de vous assurer que vous disposez du nombre adéquat d'instances Amazon EC2 disponibles pour gérer la charge de votre application. Vous créez des collections d'instances EC2 appelées groupes Auto Scaling. Vous pouvez spécifier le nombre minimal d'instances dans chaque groupe Auto Scaling. Amazon EC2 Auto Scaling garantit alors que votre groupe ne passe jamais en dessous de cette taille. Vous pouvez spécifier le nombre maximal d'instances dans chaque groupe Auto Scaling. Amazon EC2 Auto Scaling garantit alors que votre groupe ne passe jamais au-dessus de cette taille.
+ [Qu'est-ce que Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ La mise à l'échelle automatique d'Amazon DynamoDB utilise le service AWS Application Auto Scaling pour ajuster de manière dynamique la capacité de débit alloué en votre nom, en fonction des modèles de trafic réels. Cela permet à une table ou à un index secondaire global d'augmenter sa capacité de lecture et d'écriture allouée afin de gérer sans limitations les augmentations soudaines du trafic.
+ [Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à créer des solutions de calcul automatisées](https://aws.amazon.com/partners/find/results/?facets=%27Product%20:%20Compute%27)
+ [AWS Auto Scaling : Fonctionnement des plans de mise à l'échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace : produits utilisables avec Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Qu'est-ce que Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP03 Obtenir des ressources après avoir réalisé qu'un plus grand nombre de ressources est nécessaire pour une charge de travail
Mettez à l'échelle les ressources de manière proactive pour répondre à la demande et éviter l'impact sur la disponibilité.
De nombreux services AWS sont automatiquement mis à l'échelle pour répondre à la demande. Si vous utilisez des instances Amazon EC2 ou des clusters Amazon ECS, vous pouvez configurer la mise à l'échelle automatique de ces instances pour qu'elle intervienne en fonction des métriques d'utilisation qui correspondent à la demande de votre charge de travail. Pour Amazon EC2, l'utilisation moyenne du CPU, le nombre de requêtes de l'équilibreur de charge ou la bande passante du réseau peuvent être utilisés pour augmenter (ou diminuer) les instances EC2. Pour Amazon ECS, l'utilisation moyenne du CPU, le nombre de requêtes de l'équilibreur de charge et l'utilisation de la mémoire peuvent être utilisés pour augmenter (ou diminuer) les tâches ECS. En utilisant Target Auto Scaling sur AWS, l'Autoscaler agit comme un thermostat domestique, en ajoutant ou en supprimant des ressources pour maintenir la valeur cible (par exemple, 70 % d'utilisation du CPU) que vous spécifiez.
AWS Auto Scaling peut également exécuter [Predictive Auto Scaling](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/), qui s'appuie sur le machine learning pour analyser la charge de travail historique de chaque ressource et anticipe régulièrement la charge future des deux prochains jours.
Little's Law permet de calculer le nombre d'instances de calcul (instances EC2, fonctions Lambda simultanées, etc.) dont vous avez besoin.
*L* = *λW*
L = nombre d'instances (ou simultanéité moyenne dans le système)
λ = vitesse moyenne à laquelle les requêtes arrivent (demande/s.)
W = temps moyen que chaque requête passe dans le système (s.)
Par exemple, à 100 rps, si le traitement de chaque requête prend 0,5 seconde, vous aurez besoin de 50 instances pour prendre en charge la requête.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Obtenir des ressources après avoir réalisé qu'un plus grand nombre de ressources est nécessaire pour une charge de travail. Mettez à l'échelle les ressources de manière proactive pour répondre à la demande et éviter l'impact sur la disponibilité.
+ Déterminez le nombre de ressources de calcul dont vous aurez besoin (simultanéité de calcul) pour gérer un débit de demandes donné.
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ Configurez la mise à l'échelle planifiée pour Amazon EC2 Auto Scaling lorsque vous disposez d'un modèle d'utilisation historique.
+ [Mise à l'échelle planifiée pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ Utilisez la mise à l'échelle prédictive AWS.
+ [Scalabilité prédictive pour EC2 alimentée par le machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
## Ressources
**Documents connexes :**
+ [AWS Auto Scaling : Fonctionnement des plans de mise à l'échelle](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [AWS Marketplace : produits utilisables avec Auto Scaling](https://aws.amazon.com/marketplace/search/results?searchTerms=Auto+Scaling)
+ [Gestion automatique de la capacité de débit avec DynamoDB Auto Scaling](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/AutoScaling.html)
+ [Scalabilité prédictive pour EC2 alimentée par le machine learning](https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/)
+ [Mise à l'échelle planifiée pour Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html)
+ [Telling Stories About Little's Law](https://brooker.co.za/blog/2018/06/20/littles-law.html)
+ [Qu'est-ce que Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL07-BP04 Effectuer un test de charge de votre charge de travail
Adoptez une méthodologie de test de charge pour déterminer si la mise à l'échelle répond aux exigences de la charge de travail.
Il est important d'exécuter régulièrement des tests de charge. Les tests de charge devraient découvrir le point de rupture et tester les performances de votre charge de travail. AWS facilite la configuration d'environnements de test temporaires qui modélisent l'échelle de votre charge de travail de production. Dans le Cloud, vous pouvez créer un environnement d'essai à l'échelle de la production et à la demande, exécuter les tests, puis désactiver les ressources. Puisque vous ne payez l'environnement de test que lorsqu'il s'exécute, vous pouvez simuler votre environnement réel pour une fraction du coût d'un test sur site.
Les tests de charge en production doivent également être intégrés aux tests de simulation de pannes, lors desquels le système de production est mis sous tension pendant les périodes où le client est moins utilisé et tout le personnel est disponible pour interpréter les résultats et résoudre les problèmes qui surviennent.
**Anti-modèles courants :**
+ Exécution de tests de charge sur des déploiements qui ne n'ont pas la même configuration que votre production.
+ Effectuer un test de charge uniquement sur des éléments individuels de votre charge de travail, et non sur l'ensemble de la charge de travail.
+ Exécution de tests de charge avec un sous-ensemble de demandes et non un ensemble représentatif de demandes réelles.
+ Exécution de tests de charge avec un faible facteur de sécurité au-dessus de la charge prévue.
**Avantages liés au respect de cette bonne pratique :** Vous savez quels composants de votre architecture échouent sous charge et vous pouvez identifier les métriques à surveiller qui indiquent suffisamment à temps que vous approchez de cette charge pour que vous résolviez le problème et empêchiez ainsi l'impact de cette défaillance.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Exécutez des tests de charge pour identifier l'aspect de votre charge de travail qui indique que vous devez ajouter ou supprimer de la capacité. Les tests de charge doivent avoir un trafic représentatif similaire à ce que vous recevez en production. Augmentez la charge tout en surveillant les métriques que vous avez instrumentées pour déterminer quelle métrique indique quand vous devez ajouter ou supprimer des ressources.
+ [Test de charge distribuée sur AWS : simulation de milliers d'utilisateurs connectés](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ Identifiez le mélange de demandes. Comme vous pouvez avoir divers mélanges de demandes, vous devez examiner les différentes périodes lors de l'identification de la combinaison de trafic.
+ Implémentez un pilote de charge. Vous pouvez utiliser un code personnalisé, un logiciel open source ou un logiciel commercial pour implémenter un pilote de charge.
+ Effectuez un test de charge initial avec une faible capacité. Vous constatez des effets immédiats en entraînant une charge moindre, éventuellement aussi petite qu'une instance ou un conteneur.
+ Effectuez un test de charge par rapport à une capacité plus importante. Étant donné que les effets seront différents sur une charge distribuée, vous devez procéder à des essais dans un environnement aussi proche que possible de celui du produit.
## 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/)
# REL 8 Comment implémenter les modifications ?
Des modifications contrôlées sont nécessaires pour au moins deux raisons : déployer de nouvelles fonctionnalités et s'assurer que les charges de travail et l'environnement d'exploitation fonctionnent avec des logiciels connus et peuvent être corrigés ou remplacés de manière prévisible. Si les modifications ne sont pas contrôlées, il est difficile de prédire leur effet ou de résoudre les problèmes qui en découlent.
**Topics**
+ [REL08-BP01 Utiliser des runbooks pour les activités standard telles que le déploiement](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 Intégrer les tests fonctionnels dans le cadre de votre déploiement](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 Effectuer le déploiement à l'aide d'une infrastructure immuable](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 Déployer les modifications avec l'automatisation](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 Utiliser des runbooks pour les activités standard telles que le déploiement
Les runbooks sont les procédures prédéfinies destinées à parvenir à un résultat spécifique. Utilisez des runbooks pour effectuer des tâches manuelles ou automatiques standard. Il peut s'agir du déploiement d'une charge de travail, de l'application de correctifs à une charge de travail ou de la modification du DNS.
Par exemple, mettez en place des processus [pour assurer la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). Pour garantir la fiabilité d’un service, il est essentiel de s'assurer que vous pouvez restaurer un déploiement sans interruption pour vos clients.
Concernant les procédures de runbook, commencez par un processus manuel efficace valide, mettez-le en œuvre dans le code et, le cas échéant, déclenchez son exécution automatique.
Même pour les charges de travail sophistiquées hautement automatisées, les runbooks restent utiles pour [exécuter des tests de simulation de pannes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) ou répondre à des exigences rigoureuses en matière de rapports et d'audit.
Notez que les playbooks sont utilisés en réponse à des incidents spécifiques et que les runbooks le sont pour obtenir des résultats spécifiques. En règle générale, les runbooks sont destinés aux activités de routine, tandis que les playbooks sont utilisés pour répondre à des événements non réguliers.
**Anti-modèles courants :**
+ Exécution de modifications imprévues de la configuration en production.
+ Ignorer les étapes de votre plan afin d'accélérer le déploiement, ce qui entraîne un échec du déploiement.
+ Effectuez des modifications sans tester l'annulation de la modification.
**Avantages liés au respect de cette bonne pratique :** Une planification efficace des modifications augmente votre capacité à exécuter correctement la modification, car vous êtes conscient de tous les systèmes concernés. Vous gagnez en confiance si vous réussissez à valider des modifications que vous apportez aux environnements de test.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Obtenez des réponses cohérentes et rapides à des événements bien compris en documentant les procédures dans des runbooks.
+ [Concepts AWS Well-Architected Framework : runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ Utilisez le principe de l'infrastructure en tant que code pour définir votre infrastructure. En ayant recours à AWS CloudFormation ou à un tiers de confiance pour définir votre infrastructure, vous pouvez utiliser le contrôle de version et suivre les modifications apportées à la version du logiciel.
+ Utilisez AWS CloudFormation ou un fournisseur tiers de confiance pour définir votre infrastructure.
+ [Qu'est-ce qu'AWS CloudFormation ?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ Créez des modèles qui sont singuliers et découplés, en utilisant de bons principes de conception de logiciels.
+ Déterminez les autorisations, les modèles et les responsables de l'implémentation
+ [ Contrôle de l'accès avec Gestion des identités et des accès AWS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ Utilisez le contrôle de code source, comme AWS CodeCommit ou un outil tiers de confiance, pour le contrôle de version.
+ [Qu'est-ce qu'AWS CodeCommit ?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à créer des solutions de déploiement automatisées](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace : produits pouvant être utilisés pour automatiser vos déploiements](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Concepts AWS Well-Architected Framework : runbook](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [Qu'est-ce qu'AWS CloudFormation ?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Qu'est-ce qu'AWS CodeCommit ?](https://docs.aws.amazon.com/codecommit/latest/userguide/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/)
# REL08-BP02 Intégrer les tests fonctionnels dans le cadre de votre déploiement
Les tests fonctionnels sont exécutés dans le cadre du déploiement automatisé. Si les critères de réussite ne sont pas respectés, le pipeline est arrêté ou annulé.
Ces tests sont exécutés dans un environnement de préproduction, qui est mis en place avant la production dans le pipeline. Idéalement, cela s'effectue dans le cadre d'un pipeline de déploiement.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Débit
## Directives d'implémentation
+ Intégrez les tests fonctionnels dans le cadre de votre déploiement. Les tests fonctionnels sont exécutés dans le cadre du déploiement automatisé. Si les critères de réussite ne sont pas respectés, le pipeline est arrêté ou annulé.
+ Appelez AWS CodeBuild lors de « l'action de test » de vos pipelines de publication de logiciels modélisés dans AWS CodePipeline. Cette fonctionnalité vous permet d'exécuter facilement divers tests sur votre code, en particulier des tests unitaires, des analyses de code statique et des tests d'intégration.
+ [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/)
+ Utilisez les solutions AWS Marketplace pour exécuter des tests automatisés dans le cadre de votre pipeline de distribution de logiciels.
+ [Automatisation des tests logiciels](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## Ressources
**Documents connexes :**
+ [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/)
+ [Automatisation des tests logiciels](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [Qu'est-ce que AWS CodePipeline ?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 Intégrer les tests de résilience dans le cadre de votre déploiement
Les tests de résilience (basés sur les [principes de l'ingénierie du chaos](https://principlesofchaos.org/)) sont exécutés dans le cadre du pipeline de déploiement automatisé dans un environnement de préproduction.
Ces tests sont mis en place et exécutés dans le pipeline dans un environnement de préproduction. Ils doivent également être exécutés en production, mais dans le cadre des [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Intégrez les tests de résilience dans le cadre de votre déploiement. Utilisez l'ingénierie du chaos qui est la discipline d'expérimentation d'une charge de travail afin d'améliorer votre confiance en sa capacité à supporter des conditions instables en production.
+ Les tests de résilience injectent des défaillances ou une dégradation des ressources pour vérifier que votre charge de travail répond avec le niveau de résilience prévue à la conception.
+ [Atelier Well-Architected : niveau 300 : test de la résilience d’EC2 RDS et de S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ Ces tests peuvent être exécutés régulièrement dans des environnements de préproduction dans des pipelines de déploiement automatisés.
+ Ils doivent également être exécutés en production, dans le cadre des tests de simulation de panne.
+ Si vous utilisez les principes de l'ingénierie du chaos, proposez des hypothèses sur les performances de votre charge de travail dans différentes situations, puis testez vos hypothèses à l'aide de tests de résilience.
+ [Principes de l'ingénierie du chaos](https://principlesofchaos.org/)
## Ressources
**Documents connexes :**
+ [Principes de l'ingénierie du chaos](https://principlesofchaos.org/)
+ [Qu'est qu'AWS Fault Injection Simulator (AWS FIS) ?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**Exemples connexes :**
+ [Atelier Well-Architected : niveau 300 : test de la résilience d’EC2 RDS et de S3](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 Effectuer le déploiement à l'aide d'une infrastructure immuable
Une infrastructure immuable est un modèle qui exige qu'aucune mise à jour, aucune application de correctifs de sécurité ni aucun changement de configuration ne se produise sur place sur les charges de travail de production. Lorsqu'un changement est nécessaire, l'architecture est intégrée à la nouvelle infrastructure et déployée en production.
L'implémentation la plus courante du paradigme d'infrastructure immuable est le ***serveur immuable***. Cela signifie que si un serveur a besoin d'une mise à jour ou d'un correctif, de nouveaux serveurs sont déployés au lieu de mettre à jour ceux déjà utilisés. Ainsi, au lieu de se connecter au serveur via le protocole SSH et de mettre à jour la version logicielle, chaque modification de l'application commence par une transmission logicielle au référentiel de code, par exemple, git push. Les modifications n’étant pas autorisées dans une infrastructure immuable, vous pouvez être sûr de l'état du système déployé. Les infrastructures immuables sont, par nature, plus cohérentes, plus fiables et plus prévisibles. De plus, elles simplifient de nombreux aspects du développement et du fonctionnement des logiciels.
Utilisez un déploiement Canari ou bleu/vert lors du déploiement d'applications dans des infrastructures immuables.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) consiste à diriger un petit nombre de vos clients vers la nouvelle version, généralement exécutée sur une seule instance de service (la version Canari). Examinez ensuite en profondeur les modifications de comportement ou les erreurs générées. Vous pouvez supprimer le trafic du Canary si vous rencontrez des problèmes critiques et faire basculer les utilisateurs vers la version précédente. Si le déploiement est réussi, vous pouvez le continuer à la vitesse souhaitée, tout en surveillant les modifications (pour éviter les erreurs), jusqu’à ce qu’il soit terminé. AWS CodeDeploy peut être configuré avec une configuration de déploiement qui permettra un déploiement Canari.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) est semblable au déploiement Canari, si ce n'est qu'un parc complet de l'application est déployé en parallèle. Vos déploiements alternent entre deux piles (bleu et vert). Une fois encore, vous pouvez faire basculer le trafic vers la nouvelle version et revenir à l'ancienne si vous rencontrez des problèmes lors du déploiement. Généralement, tout le trafic est commuté en même temps. Vous pouvez toutefois également utiliser des fractions de votre trafic vers chaque version pour modifier l'adoption de la nouvelle version à l'aide des capacités de routage DNS pondéré d'Amazon Route 53. AWS CodeDeploy et AWS Elastic Beanstalk peuvent être configurés avec une configuration de déploiement qui permet un déploiement bleu/vert.
![\[Diagramme illustrant un déploiement bleu/vert avec AWS Elastic Beanstalk et Amazon Route 53\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
Avantages d'une infrastructure immuable :
+ **Réduction des dérives de configuration :** en remplaçant fréquemment les serveurs à partir d'une configuration de base connue et contrôlée par les versions, l'infrastructure est **réinitialisée** à un état connu, ce qui évite les dérives de configuration.
+ **Déploiements simplifiés**: les déploiements sont simplifiés, car ils n'ont pas besoin de prendre en charge les mises à niveau. Les mises à niveau sont simplement de nouveaux déploiements.
+ **Déploiements atomiques fiables :** les déploiements se terminent avec succès ou aucune modification n'est apportée. Le processus de déploiement est ainsi plus fiable.
+ **Déploiements plus sûrs avec des processus de restauration et de récupération rapides :** les déploiements sont plus sûrs, car la version de travail précédente n'est pas modifiée. Vous pouvez la restaurer si des erreurs sont détectées.
+ **Environnements de test et de débogage cohérents :** étant donné que tous les serveurs utilisent la même image, il n'y a pas de différence entre les environnements. Une version est déployée dans plusieurs environnements. Cela permet d’éviter les environnements incohérents tout en simplifiant les tests et le débogage.
+ **Capacité de mise à l'échelle accrue :** la capacité de mise à l'échelle automatique est négligeable, car les serveurs utilisent une image de base tout en étant cohérents et répétables.
+ **Chaîne d'outils simplifiée**: la chaîne d'outils est simplifiée. Vous pouvez en effet supprimer les outils de gestion de la configuration qui prennent en charge les mises à niveau des logiciels de production. Aucun outil ou agent supplémentaire n'est installé sur les serveurs. Les modifications sont apportées à l'image de base, testées et déployées.
+ **Sécurité accrue :** en refusant toutes les modifications apportées aux serveurs, vous pouvez désactiver le protocole SSH sur les instances et supprimer les clés. Cela vous permet de réduire le vecteur d'attaque tout en améliorant la sécurité de votre organisation.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Effectuez le déploiement à l'aide d'une infrastructure immuable. Une infrastructure immuable est un modèle dans le cadre duquel aucune mise à jour, aucun correctif de sécurité ni aucune modification de configuration n'est effectué *sur place* sur les systèmes de production. Si un changement est nécessaire, une nouvelle version de l'architecture est créée et déployée en production.
+ [Présentation d'un déploiement bleu/vert](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Déploiement progressif d'applications sans serveur](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastructure inaltérable : fiabilité, cohérence et confiance grâce à l'inaltérabilité](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## Ressources
**Documents connexes :**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Déploiement progressif d'applications sans serveur](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [Infrastructure inaltérable : fiabilité, cohérence et confiance grâce à l'inaltérabilité](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [Présentation d'un déploiement bleu/vert](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [L'Amazon Builders' Library : Garantir la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 Déployer les modifications avec l'automatisation
Les déploiements et l'application de correctifs sont automatisés pour éliminer l'impact négatif.
Les modifications apportées aux systèmes de production sont l'un des secteurs de risque les plus importants pour de nombreuses organisations. Nous considérons les déploiements comme un problème de premie ordre à résoudre, tout comme les problèmes opérationnels que le logiciel rencontre. Aujourd'hui, il convient d'appliquer l'automatisation dès que les opérations le permettent, y compris lors des tests et du déploiement de modifications, lors de l'ajout ou de la suppression de capacités et lors de la migration des données. AWS CodePipeline vous permet de gérer les étapes nécessaires à la libération de votre charge de travail. Cela englobe un état de déploiement utilisant AWS CodeDeploy pour automatiser le déploiement du code d'application sur les instances Amazon EC2, les instances sur site, les fonctions Lambda sans serveur ou les services Amazon ECS.
**Recommandations**
Bien que les principes traditionnels suggèrent de garder les interventions humaines dans la boucle des procédures opérationnelles les plus complexes, nous vous conseillons justement d'automatiser ces mêmes procédures pour cette raison.
**Anti-modèles courants :**
+ Modifications manuelles
+ Saut des étapes de votre automatisation via les flux de travail d'urgence.
+ Non suivi de vos plans.
**Avantages liés au respect de cette bonne pratique :** L'utilisation de l'automatisation pour déployer toutes les modifications élimine le risque d'introduction d'erreurs humaines et permet de tester avant de changer la production afin de s'assurer que vos plans sont suivis.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Moyenne entreprise
## Directives d'implémentation
+ Automatisez votre pipeline de déploiement. Le déploiement des pipelines vous permet d'une part d'invoquer des tests automatisés et la détection des anomalies et, d'autre part, d'arrêter le pipeline à une certaine étape avant le déploiement en production ou de restaurer automatiquement l'environnement d'avant la modification.
+ [L'Amazon Builders' Library : Garantir la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [L'Amazon Builders' Library : Aller plus vite avec la distribution continue](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ Utilisez AWS CodePipeline ou un produit tiers de confiance pour définir et exécuter vos pipelines.
+ Configurez le pipeline pour démarrer lorsqu'une modification est apportée à votre référentiel de code.
+ [Qu'est-ce qu'AWS CodePipeline ?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Utilisez Amazon Simple Notification Service (Amazon SNS) and Amazon Simple Email Service (Amazon SES) pour envoyer des notifications sur les problèmes dans le pipeline ou pour intégrer un outil de chat d'équipe, comme Amazon Chime.
+ [Qu'est-ce qu'Amazon Simple Notification Service ?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Qu'est-ce que Amazon SES ?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Qu'est-ce qu'Amazon Chime ?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automatisez les messages de chat avec les webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## Ressources
**Documents connexes :**
+ [Partenaire APN : partenaires pouvant vous aider à créer des solutions de déploiement automatisées](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace : produits pouvant être utilisés pour automatiser vos déploiements](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automatisez les messages de chat avec les webhooks.](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [L'Amazon Builders' Library : Garantir la sécurité des restaurations pendant les déploiements](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [L'Amazon Builders' Library : Aller plus vite avec la distribution continue](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [Qu'est-ce que AWS CodePipeline ?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [Qu'est-ce que CodeDeploy ?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [le gestionnaire de correctifs AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Qu'est-ce que Amazon SES ?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Qu'est-ce qu'Amazon Simple Notification Service ?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**Vidéos connexes :**
+ [AWS Summit 2019: CI/CD on AWS](https://youtu.be/tQcF6SqWCoY)
# 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)