# FIA 10. Comment utiliser l’isolation des pannes pour protéger votre charge de travail ?
L’isolation des défaillances limite l’impact de la défaillance d’un composant ou d’un système à une limite définie. Si l’isolation est correcte, les composants situés en dehors de cette limite ne sont pas affectés par la défaillance. L’exécution de votre charge de travail au-delà de plusieurs limites d’isolation des défaillances peut la rendre plus résistante aux défaillances.
**Topics**
+ [REL10-BP01 Déploiement de la charge de travail sur plusieurs emplacements](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 Automatiser la récupération des composants limités à un seul emplacement](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 Utiliser des architectures cloisonnées pour limiter la portée de l’impact](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 Déploiement de 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.
L’un des principes fondamentaux de la conception de services dans AWS est d’éviter les points de défaillance uniques, y compris l’infrastructure physique sous-jacente. AWS fournit des ressources et des services de cloud computing à l’échelle mondiale, sur plusieurs sites géographiques appelés [régions](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html). Chaque région est physiquement et logiquement indépendante et se compose de trois [zones de disponibilité (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) ou plus. Les zones de disponibilité sont géographiquement proches les unes des autres, mais sont physiquement séparées et isolées. La répartition de vos charges de travail entre les zones de disponibilité et les régions vous permet de réduire le risque de menaces telles que les incendies, les inondations, les catastrophes météorologiques, les tremblements de terre et les erreurs humaines.
Créez une stratégie de localisation pour assurer une haute disponibilité adaptée à vos charges de travail.
**Résultat escompté :** les charges de travail de production sont réparties entre plusieurs zones de disponibilité (AZ) ou régions afin de garantir la tolérance aux pannes et la haute disponibilité.
**Anti-modèles courants :**
+ Votre charge de travail de production n’existe que dans une seule zone de disponibilité.
+ Vous mettez en œuvre une architecture multirégionale alors qu’une architecture multi-AZ répondrait aux exigences.
+ Vos déploiements ou vos données sont désynchronisés, ce qui entraîne une dérive de la configuration ou une sous-réplication des données.
+ Vous ne tenez pas compte des dépendances entre les composants de l’application si les exigences en matière de résilience et de multi-localisation diffèrent entre ces composants.
**Avantages liés au respect de cette bonne pratique :**
+ Votre charge de travail est plus résiliente face aux incidents, tels que les pannes d’alimentation, les défaillances de contrôle environnemental, les catastrophes naturelles, les pannes de service en amont ou les problèmes réseau affectant une zone de disponibilité ou une région entière.
+ Vous pouvez accéder à un inventaire plus large d’instances Amazon EC2 et réduire le risque d’exceptions InsufficientCapacityExceptions (ICE) lors du lancement de types d’instances EC2 spécifiques.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Déployez et gérez toutes les charges de travail de production dans au moins deux zones de disponibilité (AZ) d’une région.
**Utilisation de plusieurs zones de disponibilité**
Les zones de disponibilité sont des lieux d’hébergement de ressources qui sont physiquement séparés les uns des autres afin d’éviter les défaillances corrélées dues à des risques tels que les incendies, les inondations et les tornades. Chaque zone de disponibilité possède une infrastructure physique indépendante comprenant des connexions électriques, des sources d’alimentation de secours, des services mécaniques et une connectivité réseau. Cette disposition limite les défaillances d’un de ces composants à la seule zone de disponibilité affectée. Par exemple, si un incident à l’échelle de la zone de disponibilité rend les instances EC2 indisponibles dans la zone de disponibilité affectée, vos instances situées dans une autre zone de disponibilité restent disponibles.
Bien que physiquement séparées, les zones de disponibilité situées dans la même Région AWS sont suffisamment proches pour fournir une mise en réseau à haut débit et à faible latence (moins de dix millisecondes). Vous pouvez répliquer les données de manière synchrone entre les zones de disponibilité pour la plupart des charges de travail sans affecter de manière significative l’expérience utilisateur. Cela signifie que vous pouvez utiliser les zones de disponibilité d’une région dans une configuration active/active ou active/veille.
Tous les calculs associés à votre charge de travail doivent être répartis entre les différentes zones de disponibilité. Cela inclut les instances [Amazon EC2](https://aws.amazon.com/ec2/), les tâches [AWS Fargate](https://aws.amazon.com/fargate/) et les fonctions [AWS Lambda](https://aws.amazon.com/lambda/) associées au VPC. Les services de calcul AWS, notamment [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/), [Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/) et [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), vous permettent de lancer et de gérer les calculs sur l’ensemble des zones de disponibilité. Configurez-les pour remplacer automatiquement les calculs selon les besoins dans une autre zone de disponibilité afin de maintenir la disponibilité. Pour diriger le trafic vers les zones de disponibilité disponibles, placez un équilibreur de charge devant vos ressources de calcul, tel qu’un Application Load Balancer ou un Network Load Balancer. Les équilibreurs de charge AWS peuvent rediriger le trafic vers les instances disponibles en cas d’altération de la zone de disponibilité.
Vous devez également répliquer les données pour votre charge de travail et les rendre disponibles dans plusieurs zones de disponibilité. Certains services de données AWS gérés, tels qu’[Amazon S3](https://aws.amazon.com/s3/), [Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/), [Amazon Aurora](https://aws.amazon.com/aurora/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/) et [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) répliquent les données dans plusieurs zones de disponibilité par défaut et résistent à l’altération de la zone de disponibilité. Avec d’autres services de données AWS gérés, tels qu’[Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/), [Amazon Redshift](https://aws.amazon.com/redshift/) et [Amazon ElastiCache](https://aws.amazon.com/elasticache/), vous devez activer la réplication multi-AZ. Une fois l’option activée, ces services détectent automatiquement une altération de la zone de disponibilité, redirigent les demandes vers une zone de disponibilité disponible et répliquent à nouveau les données selon les besoins après reprise, sans intervention du client. Familiarisez-vous avec le guide de l’utilisateur de chaque service de données AWS géré que vous utilisez pour comprendre ses fonctionnalités, ses comportements et son fonctionnement multi-AZ.
Si vous utilisez un stockage autogéré, tel que les volumes [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) ou le stockage d’instances Amazon EC2, vous devez gérer vous-même la réplication multi-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és. L’ELB est également déployé dans les trois zones.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/multi-tier-architecture.png)
**Utilisation de plusieurs Régions AWS**
Si vos charges de travail nécessitent une résilience extrême (telles qu’une infrastructure critique, des applications liées à la santé ou des services répondant à des exigences strictes de disponibilité imposées par le client ou par le législateur), vous pouvez avoir besoin d’une disponibilité supérieure à ce qu’une Région AWS unique peut fournir. Dans ce cas, vous devez déployer et exploiter votre charge de travail sur au moins deux Régions AWS (en supposant que vos exigences en matière de résidence des données le permettent).
Les Régions AWS sont situées dans différentes régions géographiques du monde et sur plusieurs continents. Les Régions AWSprésentent une séparation physique et une isolation encore plus importantes que les zones de disponibilité. À quelques exceptions près, les services AWS profitent de cette conception pour fonctionner de manière totalement indépendante entre les différentes régions (on parle alors de *services régionaux*). Un service Région AWSal est conçu de manière à ce qu’une défaillance n’ait pas d’impact sur le service dans une autre région.
Lorsque vous gérez votre charge de travail dans plusieurs régions, vous devez prendre en compte des exigences supplémentaires. Les ressources des différentes régions étant séparées et indépendantes les unes des autres, vous devez dupliquer les composants de votre charge de travail dans chaque région. Cela inclut l’infrastructure de base, telle que les VPC, en plus des services de calcul et de données.
**REMARQUE :** Lorsque vous envisagez une conception multirégionale, vérifiez que votre charge de travail est capable de s’exécuter dans une région unique. Si vous créez des dépendances entre des régions de manière à ce qu’un composant d’une région repose sur des services ou des composants d’une autre région, vous pouvez augmenter le risque de défaillance et affaiblir considérablement votre position en matière de fiabilité.
Pour faciliter les déploiements multirégionaux et maintenir la cohérence, [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) peut répliquer l’ensemble de votre infrastructure AWS entre plusieurs régions. [AWS CloudFormation](https://aws.amazon.com/cloudformation/) peut également détecter une dérive de configuration et vous informer lorsque vos ressources AWS d’une région ne sont pas synchronisées. De nombreux services AWS proposent la réplication multirégionale des ressources de charge de travail importantes. Par exemple, [EC2 Image Builder](https://aws.amazon.com/image-builder/) peut publier vos images de machine EC2 (AMI) après chaque génération dans chaque région que vous utilisez. [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) peut répliquer vos images de conteneur dans les régions que vous avez sélectionnées.
Vous devez également répliquer vos données dans chacune des régions que vous avez choisies. De nombreux services de données AWS gérés offrent une capacité de réplication interrégionale, notamment Amazon S3, Amazon DynamoDB, Amazon RDS, Amazon Aurora, Amazon Redshift, Amazon Elasticache, et Amazon EFS. Les [tables globales Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) acceptent les écritures dans toute région prise en charge et répliqueront les données entre toutes vos autres régions configurées. Pour les autres services, vous devez désigner une région principale pour les écritures, car les autres régions contiennent des réplicas en lecture seule. Consultez le guide de l’utilisateur et le manuel du développeur de chaque service de données AWS géré utilisé par votre charge de travail pour comprendre ses capacités et ses limites multirégionales. Accordez une attention particulière à l’endroit où les écritures doivent être dirigées, aux capacités et aux limites transactionnelles, à la manière dont la réplication est effectuée et à la manière de surveiller la synchronisation entre les régions.
AWS permet également d’acheminer de façon très flexible le trafic de demandes vers vos déploiements régionaux. Par exemple, vous pouvez configurer vos enregistrements DNS à l’aide d’[Amazon Route 53](https://aws.amazon.com/route53/) pour diriger le trafic vers la région disponible la plus proche de l’utilisateur. Vous pouvez également configurer vos enregistrements DNS dans une configuration active/en veille, dans laquelle vous désignez une région comme principale et ne vous rabattez sur un réplica régional que si la région principale devient défectueuse. Vous pouvez configurer la [surveillance de l’état Route 53](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) pour détecter les points de terminaison défectueux et effectuer un basculement automatique. Vous pouvez également utiliser [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) pour fournir un contrôle de routage hautement disponible permettant de réacheminer manuellement le trafic selon les besoins.
Même si vous choisissez de ne pas opérer dans plusieurs régions pour des raisons de haute disponibilité, considérez plusieurs régions dans le cadre de votre stratégie de reprise après sinistre (DR). Si possible, répliquez les composants et les données de l’infrastructure de votre charge de travail dans une configuration de *secours à chaud* ou d’*environnement en veille* dans une région secondaire. Dans cette conception, vous répliquez l’infrastructure de base de la région principale, telle que les VPC, les groupes Auto Scaling, les orchestrateurs de conteneurs et d’autres composants, mais vous configurez les composants de taille variable dans la région de secours (tels que le nombre d’instances EC2 et de réplicas de base de données) de manière à ce qu’ils aient une taille minimale exploitable. Vous organisez également une réplication continue des données de la région principale vers la région de secours. En cas d’incident, vous pouvez augmenter horizontalement ou accroître les ressources de la région de secours, puis la promouvoir en région principale.
### Étapes d’implémentation
1. Travaillez avec les parties prenantes de l’entreprise et les experts en résidence des données pour déterminer les Régions AWS qui peuvent être utilisées pour héberger vos ressources et vos données.
1. Travaillez avec les parties prenantes techniques et commerciales pour évaluer votre charge de travail et déterminer si ses besoins de résilience peuvent être satisfaits par une approche multi-AZ (une seule Région AWS) ou s’ils nécessitent une approche multirégionale (si plusieurs régions sont autorisées). L’utilisation de plusieurs régions permet de bénéficier d’une plus grande disponibilité, mais peut entraîner une complexité et des coûts supplémentaires. Tenez compte des facteurs suivants dans votre évaluation :
1. **Objectifs commerciaux et exigences des clients** : quelle est la durée d’indisponibilité autorisée en cas d’incident affectant la charge de travail dans une zone de disponibilité ou une région ? Évaluez vos objectifs de point de récupération tels qu’ils sont présentés dans [REL13-BP01 Définir les objectifs de reprise en termes de durée d’indisponibilité et de perte de données](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).
1. **Exigences relatives à la reprise après sinistre (DR)** : contre quel type de sinistre potentiel souhaitez-vous vous assurer ? Envisagez la possibilité d’une perte de données ou d’une indisponibilité à long terme à différents niveaux d’impact, d’une simple zone de disponibilité à une région entière. Si vous répliquez des données et des ressources entre des zones de disponibilité et qu’une seule zone de disponibilité connaît une défaillance prolongée, vous pouvez récupérer le service dans une autre zone de disponibilité. Si vous répliquez des données et des ressources entre plusieurs régions, vous pouvez récupérer le service dans une autre région.
1. Déployez vos ressources de calcul dans plusieurs zones de disponibilité.
1. Dans votre VPC, créez plusieurs sous-réseaux dans des zones de disponibilité différentes. Configurez chacune d’elles de manière à ce qu’elle soit suffisamment grande pour accueillir les ressources nécessaires pour répondre à la charge de travail, même en cas d’incident. Pour plus d’informations, consultez [REL02-BP03 S’assurer que l’allocation des sous-réseaux IP tient compte de l’expansion et de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html).
1. Si vous utilisez des instances Amazon EC2, utilisez [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) pour gérer vos instances. Spécifiez les sous-réseaux que vous avez choisis à l’étape précédente lorsque vous créez vos groupes Auto Scaling.
1. Si vous utilisez le calcul AWS Fargate pour [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) ou [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html), sélectionnez les sous-réseaux que vous avez choisis à la première étape lors de la création d’un service ECS, lancez une tâche ECS ou créez un [profil Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) pour EKS.
1. Si vous utilisez des fonctions AWS Lambda qui doivent être exécutées dans votre VPC, sélectionnez les sous-réseaux que vous avez choisis à la première étape lors de la création de la fonction Lambda. Pour toutes les fonctions qui n’ont pas de configuration VPC, AWS Lambda gère automatiquement la disponibilité pour vous.
1. Placez des redirecteurs de trafic tels que des équilibreurs de charge devant vos ressources de calcul. Si l’équilibrage de charge entre zones est activé, les équilibreurs [AWS Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) et [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) détectent quand des cibles telles que des instances et des conteneurs EC2 sont inaccessibles en raison d’une altération de la zone de disponibilité et redirigent le trafic vers des cibles situées dans des zones de disponibilité saines. Si vous désactivez l’équilibrage de charge entre zones, utilisez Amazon Application Recovery Controller (ARC) pour fournir une fonctionnalité de changement de zone. Si vous utilisez un équilibreur de charge tiers ou si vous avez implémenté vos propres équilibreurs de charge, configurez-les avec plusieurs front ends répartis dans différentes zones de disponibilité.
1. Répliquez les données de votre charge de travail sur plusieurs zones de disponibilité.
1. Si vous utilisez un service de données AWS géré tel qu’Amazon RDS, Amazon ElastiCache ou Amazon FSx, étudiez son guide de l’utilisateur pour comprendre ses capacités de réplication de données et de résilience. Activez la réplication et le basculement entre zones de disponibilité si nécessaire.
1. Si vous utilisez des services de stockage AWS gérés tels qu’Amazon S3, Amazon EFS et Amazon FSx, évitez d’utiliser des configurations mono-AZ ou à zone unique pour des données qui requièrent une durabilité élevée. Utilisez une configuration multi-AZ pour ces services. Consultez le guide de l’utilisateur du service correspondant pour déterminer si la réplication multi-AZ est activée par défaut ou si vous devez l’activer.
1. Si vous exécutez une base de données, une file d’attente ou un autre service de stockage autogéré, organisez la réplication multi-AZ conformément aux instructions ou aux bonnes pratiques de l’application. Familiarisez-vous avec les procédures de basculement de votre application.
1. Configurez votre service DNS pour détecter une altération de la zone de disponibilité et rediriger le trafic vers une zone de disponibilité saine. Amazon Route 53, lorsqu’il est utilisé en combinaison avec des Elastic Load Balancers, peut le faire automatiquement. Route 53 peut également être configuré avec des enregistrements de basculement qui utilisent la surveillance de l’état pour répondre aux requêtes avec uniquement des adresses IP saines. Pour tous les enregistrements DNS utilisés pour le basculement, spécifiez une faible valeur de durée de vie (TTL) (par exemple, 60 secondes ou moins) afin d’éviter que la mise en cache des enregistrements n’entrave la reprise (les enregistrements d’alias Route 53 fournissent des durées de vie (TTL) appropriées pour vous).
**Étapes supplémentaires lors de l’utilisation de plusieurs Régions AWS**
1. Répliquez l’ensemble du code d’application et de système d’exploitation (OS) utilisé par votre charge de travail dans les régions que vous avez sélectionnées. Répliquez les images Amazon Machine Image (AMI) utilisées par vos instances EC2, si nécessaire, à l’aide de solutions telles qu’Amazon EC2 Image Builder. Répliquez les images de conteneur stockées dans des registres à l’aide de solutions telles que la réplication entre régions Amazon ECR. Activez la réplication régionale pour tous les compartiments Amazon S3 utilisés pour stocker les ressources d’application.
1. Déployez vos ressources de calcul et vos métadonnées de configuration (telles que les paramètres stockés dans AWS Systems Manager Parameter Store) dans plusieurs régions. Utilisez les mêmes procédures que celles décrites dans les étapes précédentes, mais répliquez la configuration pour chaque région que vous utilisez pour votre charge de travail. Utilisez des solutions d’infrastructure en tant que code, telles qu’AWS CloudFormation pour reproduire uniformément les configurations entre les régions. Si vous utilisez une région secondaire dans une configuration d’environnement en veille pour la reprise après sinistre, vous pouvez réduire le nombre de vos ressources de calcul à une valeur minimale afin de réduire les coûts, avec une augmentation correspondante du temps de reprise.
1. Répliquez vos données de votre région principale vers vos régions secondaires.
1. Les tables globales Amazon DynamoDB fournissent des réplicas globaux de vos données sur lesquels vous pouvez écrire depuis n’importe quelle région prise en charge. Avec d’autres services de données AWS gérés, tels qu’Amazon RDS, Amazon Aurora et Amazon Elasticache, vous désignez une région principale (lecture/écriture) et des régions de réplica (lecture seule). Consultez les guides de l’utilisateur et les manuels du développeur des services respectifs pour plus de détails sur la réplication régionale.
1. Si vous exécutez une base de données autogérée, organisez la réplication multirégionale conformément aux instructions ou aux bonnes pratiques de l’application. Familiarisez-vous avec les procédures de basculement de votre application.
1. Si votre charge de travail utilise AWS EventBridge, vous devrez peut-être transférer certains événements de votre région principale vers vos régions secondaires. Pour ce faire, spécifiez les bus d’événements dans vos régions secondaires comme cibles pour les événements correspondants dans votre région principale.
1. Déterminez si et dans quelle mesure vous souhaitez utiliser des clés de chiffrement identiques entre les régions. Une approche standard conciliant sécurité et facilité d’utilisation consiste à utiliser des clés régionales pour les données et l’authentification locales d’une région, et à utiliser des clés globales pour le chiffrement des données répliquées entre différentes régions. [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) prend en charge les [clés multirégionales](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) pour répartir en toute sécurité et protéger les clés partagées entre les régions.
1. Envisagez d’utiliser AWS Global Accelerator pour améliorer la disponibilité de votre application en dirigeant le trafic vers les régions qui contiennent des points de terminaison sains.
## Ressources
**Bonnes pratiques associées :**
+ [REL02-BP03 S’assurer que l’allocation des sous-réseaux IP tient compte de l’expansion et de la disponibilité](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)
+ [REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [REL13-BP01 Définir les objectifs de reprise en termes de durée d’indisponibilité et de perte de données](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)
**Documents connexes :**
+ [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure)
+ [Livre blanc : Limites d’isolation des défaillances des services AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html)
+ [Résilience dans Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html)
+ [Amazon EC2 Auto Scaling : exemple : répartition des instances entre les zones de disponibilité](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Fonctionnement d’EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution)
+ [Comment Amazon ECS place les tâches sur les instances de conteneur (y compris Fargate)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
+ [Résilience dans AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html)
+ [Amazon S3 : présentation de la réplication d’objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Réplication d’images privées sur Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)
+ [Tables globales : réplication multirégion avec DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Elasticache for Redis OSS : réplication entre Régions AWS à l’aide d’entrepôts de données globaux](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html)
+ [Résilience dans Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html)
+ [Utilisation de bases de données globales Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Manuel du développeur AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
+ [Clés multi-régions dans AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
+ [Amazon Route 53 : configuration du basculement DNS](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [Manuel du développeur Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Envoi et réception d’événements Amazon EventBridge entre régions Régions AWS](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.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/)
+ [Architecture de reprise après sinistre (DR) sur AWS, partie I : 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/)
+ [Architecture de reprise après sinistre sur AWS, partie III : 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/)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 Automatiser la récupération des 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, implémentez la capacité permettant d’effectuer une reconstruction complète de la charge de travail dans le cadre de vos objectifs de reprise définis.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
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 passer par [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, pour Amazon Redshift, il 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 provisionnés dans la même zone.
Pour les charges de travail basées sur des serveurs avec état déployés dans un centre de données sur site, vous pouvez utiliser AWS Elastic Disaster Recovery pour protéger vos charges de travail dans AWS. Si vous êtes déjà hébergé dans AWS, Elastic Disaster Recovery peut vous permettre de protéger votre charge de travail dans une autre zone de disponibilité ou région. Elastic Disaster Recovery utilise une réplication continue au niveau des blocs vers une zone de stockage légère afin de fournir une récupération rapide et fiable des applications sur site et dans le cloud.
**Étapes d’implémentation**
1. Implémentation de l’autorégénération Dans la mesure du possible, déployez vos instances ou vos conteneurs en utilisant la mise à l’échelle automatique. Si vous ne pouvez pas utiliser la mise à l’échelle 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 Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) 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.
+ Les données utilisateur du modèle 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 Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) pour les charges de travail nécessitant une seule adresse d’ID d’instance, une adresse IP privée, une adresse IP élastique et les métadonnées d’instance.
+ 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 Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ou les [événements Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) pour automatiser l’autoréparation lorsque la mise à l’échelle automatique ou la récupération de votre instance EC2 ne peuvent pas être utilisées.
+ Utilisez les événements pour invoquer le mécanisme vous permettant de réparer votre composant selon la logique de processus dont vous avez besoin.
+ Protégez les charges de travail avec état limitées à un seul emplacement à l’aide de [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html).
## Ressources
**Documents connexes :**
+ [Événements Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [Hooks de cycle de vie Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Récupération de votre instance.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Mise à l’échelle automatique des services](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [Qu’est-ce qu’Amazon EC2 Auto Scaling ?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
# REL10-BP03 Utiliser des architectures cloisonnées pour limiter la portée de l’impact
Mettez en œuvre des architectures de cloisonnement (également connues sous le nom d’architectures cellulaires) pour restreindre l’effet d’une panne au sein d’une charge de travail à un nombre limité de composants.
**Résultat escompté :** une architecture cellulaire utilise plusieurs instances isolées d’une charge de travail, chaque instance étant appelée cellule. Chaque cellule est indépendante, ne partage pas d’état avec les autres cellules et traite un sous-ensemble des demandes de la charge de travail globale. L’impact potentiel d’une défaillance, telle qu’une mauvaise mise à jour logicielle, sur une cellule individuelle et sur les demandes qu’elle traite est ainsi réduit. Si une charge de travail utilise 10 cellules pour traiter 100 demandes, lorsqu’une panne survient, 90 % des demandes globales ne sont pas affectées par la panne.
**Anti-modèles courants :**
+ Permettre aux cellules de se développer sans limites.
+ Appliquer des mises à jour ou des déploiements de code à toutes les cellules en même temps.
+ Partage de l’état ou des composants entre les cellules (à l’exception de la couche routeur).
+ Ajout d’une logique métier ou de routage complexe à la couche routeur.
+ Ne pas minimiser les interactions entre les cellules.
**Avantages liés au respect de cette bonne pratique :** avec les architectures cellulaires, de nombreux types de défaillances courants sont contenus dans la cellule elle-même, ce qui permet une isolation supplémentaire des pannes. Ces limites de défaillances peuvent apporter de la résilience face à des types de défaillances difficiles à contenir, tels que des déploiements de code infructueux ou des demandes corrompues ou invoquant un mode de défaillance spécifique (également appelées *demandes de pilules empoisonnées*).
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Sur un navire, les cloisons permettent de contenir une brèche dans la coque dans une seule section de la coque. Dans les systèmes complexes, ce modèle est souvent répliqué pour permettre d’isoler des pannes. Les limites isolées pour les défaillances restreignent l’effet d’une panne au sein d’une charge de travail à un nombre limité de composants. Les composants situés en dehors du périmètre ne sont pas affectés par la défaillance. En utilisant plusieurs périmètres d’isolation des pannes, vous pouvez limiter l’impact sur votre charge de travail. Sur AWS, les clients peuvent utiliser plusieurs zones de disponibilité et régions pour isoler des pannes, mais le concept d’isolement des pannes peut également être étendu à l’architecture de votre charge de travail.
La charge de travail globale est divisée en cellules par une clé de partition. Celle-ci doit s’aligner sur la base de *granularité* du service, ou sur la manière naturelle dont la charge de travail d’un service peut être subdivisée avec un minimum d’interactions entre les cellules. Des exemples de clés de partition sont l’ID du client, l’ID de la ressource ou tout autre paramètre facilement accessible dans la plupart des appels d’API. Une couche de routage des cellules distribue les requêtes aux cellules individuelles en fonction de la clé de partition et présente un point de terminaison unique aux clients.
![\[Diagramme illustrant une architecture cellulaire\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/framework/images/cell-based-architecture.png)
**Étapes d’implémentation**
Lors de la conception d’une architecture cellulaire, vous devez tenir compte de plusieurs éléments :
1. **Clé de partition** : une attention particulière doit être prise lors du choix de la clé de partition.
+ Celle-ci doit s’aligner sur la base de granularité du service, ou sur la manière naturelle dont la charge de travail d’un service peut être subdivisée avec un minimum d’interactions entre les cellules. Exemples : `customer ID` ou `resource ID`.
+ La clé de partition doit être disponible dans toutes les requêtes, soit directement, soit d’une manière qui pourrait être facilement déduite de façon déterministe par d’autres paramètres.
1. **Mappage cellulaire persistant** : les services en amont ne doivent interagir qu’avec une seule cellule pendant le cycle de vie de leurs ressources.
+ En fonction de la charge de travail, vous devrez peut-être concevoir une stratégie de migration de cellules pour faire migrer les données d’une cellule à l’autre. La migration d’une cellule peut s’avérer nécessaire si un utilisateur ou une ressource particulière de votre charge de travail devient trop importante et nécessite une cellule dédiée.
+ Les cellules ne doivent pas partager d’état ou de composants entre elles.
+ Par conséquent, les interactions entre cellules doivent être évitées ou réduites au minimum, car elles créent des dépendances entre les cellules et diminuent donc les bénéfices de l’isolement des défaillances.
1. **Couche routeur** : la couche routeur est un composant partagé entre les cellules et ne peut donc pas suivre la même stratégie de compartimentage qu’avec les cellules.
+ Nous recommandons de paramétrer la couche routeur pour distribuer les requêtes à des cellules individuelles à l’aide d’un algorithme de mappage de partition d’une manière efficace sur le plan des calculs. Par exemple, en combinant des fonctions de hachage cryptographiques et de l’arithmétique modulaire pour mapper les clés de partition aux cellules.
+ Pour éviter les impacts sur plusieurs cellules, la couche de routage doit rester le plus simple possible et être doté d’une capacité de mise à l’échelle horizontale optimale, ce qui nécessite d’éviter toute logique métier complexe au sein de cette couche. L’avantage supplémentaire est qu’il est facile de comprendre le comportement attendu à tout moment, ce qui permet de réaliser des tests approfondis. Comme l’explique Colm MacCárthaigh dans [Fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/), des conceptions simples et des modèles de travail constants produisent des systèmes fiables et réduisent la fragilité.
1. **Taille des cellules** : les cellules doivent avoir une taille maximale et ne doivent pas être autorisées à croître au-delà de cette taille.
+ La taille maximale doit être identifiée en effectuant des tests approfondis, jusqu’à ce que les points de rupture soient atteints et que des marges de fonctionnement sûres soient établies. Pour en savoir plus sur la mise en œuvre des pratiques de test, consultez [REL07-BP04 Testez votre charge de travail](rel_adapt_to_changes_load_tested_adapt.md)
+ La charge de travail globale doit se développer en ajoutant des cellules supplémentaires, ce qui lui permet de s’adapter à l’augmentation de la demande.
1. **Stratégies multi-AZ ou multi-régions** : plusieurs niveaux de résilience doivent être exploités pour se protéger contre différents domaines de défaillance.
+ 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 mise en œuvre d’une stratégie multi-ré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 multi-région peut être très complexe et n’est généralement pas requise pour la plupart des charges de travail. Pour en savoir plus, veuillez consulter [REL10-BP01 Déploiement de la charge de travail sur plusieurs emplacements](rel_fault_isolation_multiaz_region_system.md).
1. **Déploiement du code** : une stratégie de déploiement de code échelonnée doit être préférée au déploiement de modifications de code dans toutes les cellules en même temps.
+ Les risques de panne de plusieurs cellules sont ainsi réduits en raison d’un mauvais déploiement ou d’une erreur humaine. Pour en savoir plus, consulter [Automatiser un déploiement sûr et sans intervention](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/).
## Ressources
**Bonnes pratiques associées:**
+ [REL07-BP04 Testez votre charge de travail](rel_adapt_to_changes_load_tested_adapt.md)
+ [REL10-BP01 Déploiement de la charge de travail sur plusieurs emplacements](rel_fault_isolation_multiaz_region_system.md)
**Documents connexes :**
+ [Fiabilité, travail constant et une bonne tasse de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS et compartimentage ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [Isolation de la charge de travail à l’aide du partitionnement aléatoire](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+ [Automatiser un déploiement sûr et sans intervention](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Vidéos connexes :**
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ](https://www.youtube.com/watch?v=O8xLxNje30M)
+ [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)
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience ](https://www.youtube.com/watch?v=wUzSeSfu1XA)