Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # AWS types de services AWS gère trois catégories de services différentes en fonction de leur limite d'isolation des pannes : zonal, régional et mondial. Cette section décrit plus en détail comment ces différents types de services ont été conçus afin que vous puissiez déterminer l'impact des défaillances d'un service d'un certain type de service sur votre charge de travail AWS. Il fournit également des conseils de haut niveau sur la manière de concevoir vos charges de travail afin d'utiliser ces services de manière résiliente. Pour les services mondiaux, ce document fournit également des conseils prescriptifs [Annexe B - Guide de service global pour les réseaux Edge](appendix-b---edge-network-global-service-guidance.md) qui peuvent vous aider à éviter l'impact sur vos charges de travail des défaillances du plan de contrôle des AWS services, en vous aidant à assumer en toute sécurité votre dépendance à l'égard des services mondiaux tout en minimisant l'introduction de points de défaillance uniques. [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) **Topics** + [Services zonaux](zonal-services.md) + [Services régionaux](regional-services.md) + [Services mondiaux](global-services.md) # Services zonaux [https://aws.amazon.com/builders-library/static-stability-using-availability-zones/](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI) AWS permet de proposer des services zonaux, comme Amazon EC2 et AmazonEBS. Un service zonal est un service qui permet de spécifier dans quelle zone de disponibilité les ressources sont déployées. Ces services fonctionnent indépendamment dans chaque zone de disponibilité d'une région et, plus important encore, échouent également indépendamment dans chaque zone de disponibilité. Cela signifie que les composants d'un service dans une zone de disponibilité ne dépendent pas des composants d'autres zones de disponibilité. Nous pouvons le faire parce qu'un service zonal possède des plans de **données zonaux**. Dans certains cas, comme avecEC2, le service inclut également des plans de contrôle zonaux pour les opérations alignées par zone, telles que le lancement d'une EC2 instance. Pour ces services, fournit AWS également un point de terminaison du plan de contrôle régional pour faciliter l'interaction avec le service. Le plan de contrôle régional fournit également des fonctionnalités à portée régionale et sert de couche d'agrégation et de routage au-dessus des plans de contrôle zonaux. Cela est illustré dans la figure suivante. ![\[Cette image montre un service zonal avec des plans de contrôle et des plans de données isolés par zone\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-fault-isolation-boundaries/images/a-zonal-service-with-zonally-isolated-control-planes-and-data-planes.png) Les zones de disponibilité permettent aux clients de gérer des charges de travail de production plus hautement disponibles, tolérantes aux pannes et évolutives que ce qui serait possible à partir d'un seul centre de données. Lorsqu'une charge de travail utilise plusieurs zones de disponibilité, les clients sont mieux isolés et protégés contre les problèmes qui affectent l'infrastructure physique d'une seule zone de disponibilité. Cela permet aux clients de créer des services redondants dans toutes les zones de disponibilité et, s'ils sont correctement architecturés, de rester opérationnels même en cas de défaillance d'une zone de disponibilité. Les clients peuvent en tirer parti AZI pour créer des charges de travail hautement disponibles et résilientes. La mise AZI en œuvre dans votre architecture vous permet de récupérer rapidement après une défaillance isolée d'une zone de disponibilité, car vos ressources dans une zone de disponibilité minimisent ou éliminent l'interaction avec les ressources des autres zones de disponibilité. Cela permet de supprimer les dépendances entre les zones de disponibilité, ce qui simplifie l'évacuation des zones de disponibilité. Reportez-vous à la section [Modèles de résilience multi-AZ avancés](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html) pour plus de détails sur la création de mécanismes d'évacuation des zones de disponibilité. En outre, vous pouvez tirer davantage parti des zones de disponibilité en suivant certaines des meilleures pratiques AWS utilisées pour ses propres services, telles que le déploiement des modifications sur une seule zone de disponibilité à la fois ou la suppression d'une zone de disponibilité du service si une modification de cette zone de disponibilité se passe mal. La [stabilité statique](static-stability.md) est également un concept important pour les architectures de zones de disponibilité multiple. L'un des modes de défaillance que vous devez prévoir avec les architectures à zones de disponibilité multiples est la perte d'une zone de disponibilité, qui peut entraîner la perte de capacité d'une zone de disponibilité. Si vous n'avez pas préprovisionné suffisamment de capacité pour faire face à la perte d'une zone de disponibilité, votre capacité restante peut être submergée par la charge actuelle. En outre, vous devrez vous fier aux plans de contrôle des services zonaux que vous utilisez pour remplacer cette capacité perdue, ce qui peut être moins fiable qu'une conception statiquement stable. Dans ce cas, le pré-provisionnement d'une capacité supplémentaire suffisante peut vous aider à rester statiquement stable face à la perte d'un domaine de défaillance, tel qu'une zone de disponibilité, en étant en mesure de poursuivre vos opérations normales sans avoir besoin de modifications dynamiques. Vous pouvez choisir d'utiliser un groupe d'EC2instances à dimensionnement automatique déployé dans plusieurs zones de disponibilité pour effectuer une mise à l'échelle interne et descendante de manière dynamique, en fonction des besoins de votre charge de travail. La mise à l'échelle automatique fonctionne bien pour les changements graduels d'utilisation qui se produisent au fil des minutes, voire des dizaines de minutes. Cependant, le lancement de nouvelles EC2 instances prend du temps, en particulier si celles-ci nécessitent un amorçage (par exemple, l'installation d'agents, de fichiers binaires d'applications ou de fichiers de configuration). Pendant ce temps, votre capacité restante pourrait être dépassée par la charge actuelle. En outre, le déploiement de nouvelles instances par le biais d'une mise à l'échelle automatique repose sur le plan EC2 de contrôle. Cela présente un inconvénient : pour être statiquement stable face à la perte d'une seule zone de disponibilité, vous devez préapprovisionner suffisamment d'EC2instances dans les autres zones de disponibilité pour gérer la charge qui a été transférée hors de la zone de disponibilité affectée, au lieu de compter sur le dimensionnement automatique pour provisionner de nouvelles instances. Toutefois, le pré-provisionnement en capacité supplémentaire peut entraîner des coûts supplémentaires. Par exemple, en fonctionnement normal, supposons que votre charge de travail nécessite six instances pour traiter le trafic client dans trois zones de disponibilité. Pour garantir une stabilité statique en cas de défaillance d'une seule zone de disponibilité, vous devez déployer trois instances dans chaque zone de disponibilité, pour un total de neuf. Si une seule instance correspondant à une zone de disponibilité tombait en panne, il vous en resterait six et vous pourriez continuer à traiter le trafic de vos clients sans avoir à approvisionner et à configurer de nouvelles instances en cas de panne. La stabilité statique de votre EC2 capacité entraîne un coût supplémentaire, car dans ce cas, vous exécutez 50 % d'instances supplémentaires. Tous les services pour lesquels vous pouvez préprovisionner des ressources n'entraîneront pas de coûts supplémentaires, tels que le préprovisionnement d'un compartiment S3 ou d'un utilisateur. Vous devrez évaluer les inconvénients liés à la mise en œuvre de la stabilité statique par rapport au risque de dépassement du temps de restauration souhaité pour votre charge de travail. AWS Les Zones Locales et les Outposts rapprochent le plan de données de certains AWS services des utilisateurs finaux. Les plans de contrôle de ces services se trouvent dans la région parent. Votre instance de zone locale ou d'Outposts comportera des dépendances du plan de contrôle pour les services zonaux tels que EC2 et EBS sur la zone de disponibilité dans laquelle vous avez créé votre zone locale ou votre sous-réseau Outposts. Ils dépendront également des plans de contrôle régionaux pour les services régionaux tels qu'Elastic Load Balancing (ELB), les groupes de sécurité et le plan de contrôle Kubernetes géré par Amazon Elastic Kubernetes Service [(EKS](https://docs.aws.amazon.com/eks/latest/userguide/local-zones.html)Amazon) (si vous en utilisez). EKS Pour plus d'informations spécifiques aux Outposts, reportez-vous à la [documentation](https://docs.aws.amazon.com/outposts/latest/userguide/disaster-recovery-resiliency.html) et au [support et](https://aws.amazon.com/outposts/rack/faqs/) à la maintenance. FAQ Mettez en œuvre la stabilité statique lorsque vous utilisez des Zones Locales ou des Outposts pour améliorer la résilience en cas de défaillance du plan de contrôle ou d'interruption de la connectivité réseau avec la région parent. # Services régionaux Les services régionaux sont des services qui AWS s'appuient sur plusieurs zones de disponibilité afin que les clients n'aient pas à déterminer comment tirer le meilleur parti des services zonaux. Nous regroupons logiquement le service déployé dans plusieurs zones de disponibilité afin de présenter un point de terminaison régional unique aux clients. Amazon SQS et [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) sont des exemples de services régionaux. Ils utilisent l'indépendance et la redondance des zones de disponibilité pour minimiser les défaillances de l'infrastructure en tant que catégorie de risque de disponibilité et de durabilité. Amazon S3, par exemple, répartit les demandes et les données entre plusieurs zones de disponibilité et est conçu pour effectuer une restauration automatique en cas de défaillance d'une zone de disponibilité. Toutefois, vous n'interagissez qu'avec le point de terminaison régional du service. AWS estime que la plupart des clients peuvent atteindre leurs objectifs de résilience dans une seule région en utilisant des services régionaux ou des architectures multi-AZ qui s'appuient sur des services zonaux. Toutefois, certaines charges de travail peuvent nécessiter une redondance supplémentaire, et vous pouvez utiliser l'isolation de Régions AWS pour créer des architectures multirégionales à des fins de haute disponibilité ou de continuité des activités. La séparation physique et logique Régions AWS permet d'éviter les défaillances corrélées entre eux. En d'autres termes, comme si vous étiez EC2 client et que vous pouviez bénéficier de l'isolation des zones de disponibilité en les déployant sur plusieurs d'entre elles, vous pouvez bénéficier des mêmes avantages pour les services régionaux en les déployant dans plusieurs régions. Cela nécessite que vous implémentiez une architecture multirégionale pour votre application, ce qui peut vous aider à résister à la détérioration d'un service régional. Cependant, il peut être difficile de tirer parti des avantages d'une architecture multirégionale ; il faut travailler avec soin pour tirer parti de l'isolement régional sans rien annuler au niveau de l'application. Par exemple, si vous basculez une application entre régions, vous devez maintenir une séparation stricte entre vos piles d'applications dans chaque région, connaître toutes les dépendances entre les applications et basculer toutes les parties de l'application en même temps. Pour y parvenir, une architecture complexe basée sur des microservices comportant de nombreuses dépendances entre les applications nécessite une planification et une coordination entre de nombreuses équipes d'ingénierie et commerciales. Permettre aux charges de travail individuelles de prendre leurs propres décisions en matière de basculement simplifie la coordination, mais introduit un comportement modal en raison de la différence significative de latence entre les régions par rapport à l'intérieur d'une même région. AWS ne fournit pas de fonctionnalité de réplication synchrone entre régions pour le moment. Lorsque vous utilisez une banque de données répliquée de manière asynchrone (fournie par AWS) entre les régions, il existe un risque de perte de données ou d'incohérence lorsque vous basculez votre application entre les régions. Pour atténuer les éventuelles incohérences, vous avez besoin d'un processus de rapprochement des données fiable dans lequel vous pouvez avoir confiance et qui peut avoir besoin d'opérer sur plusieurs magasins de données au sein de votre portefeuille de charges de travail, ou vous devez être prêt à accepter une perte de données. Enfin, vous devez pratiquer le failover pour savoir qu'il fonctionnera quand vous en aurez besoin. La rotation régulière de votre application entre les régions pour pratiquer le basculement sur incident représente un investissement considérable en temps et en ressources. Si vous décidez d'utiliser une banque de données répliquée de manière synchrone entre plusieurs régions pour prendre en charge vos applications exécutées simultanément à partir de plusieurs régions, les caractéristiques de performance et de latence d'une telle base de données qui s'étend sur des centaines ou des milliers de kilomètres sont très différentes de celles d'une base de données fonctionnant dans une seule région. Cela vous oblige à planifier votre pile d'applications à partir de zéro pour tenir compte de ce comportement. Cela rend également la disponibilité des deux régions fortement dépendante, ce qui peut entraîner une diminution de la résilience de votre charge de travail. # Services mondiaux Outre les AWS services régionaux et zonaux, il existe un petit ensemble de AWS services dont les plans de contrôle et les plans de données n'existent pas indépendamment dans chaque région. *Comme leurs ressources ne sont pas spécifiques à une région, elles sont communément appelées « mondiales ».* Les AWS services globaux suivent toujours le schéma de AWS conception classique qui consiste à séparer le plan de contrôle du plan de données afin d'obtenir une stabilité statique. La différence significative pour la plupart des services mondiaux est que leur plan de contrôle est hébergé dans un *seul* Région AWS, tandis que leur plan de données est distribué dans le monde entier. Il existe trois types différents de services globaux et un ensemble de services qui peuvent sembler globaux en fonction de la configuration que vous avez sélectionnée. Les sections suivantes identifieront chaque type de service global et la manière dont leurs plans de contrôle et leurs plans de données sont séparés. Vous pouvez utiliser ces informations pour savoir comment créer des mécanismes fiables de haute disponibilité (HA) et de reprise après sinistre (DR) sans avoir à dépendre d'un plan de contrôle de service global. Cette approche permet d'éliminer les points de défaillance uniques de votre architecture et d'éviter les impacts potentiels entre régions, même lorsque vous opérez dans une région différente de celle où le plan de contrôle des services global est hébergé. Il vous aide également à mettre en œuvre en toute sécurité des mécanismes de basculement qui ne reposent pas sur des plans de contrôle de service mondiaux. ## Des services globaux uniques par partition Certains AWS services globaux existent dans chaque partition (désignés dans ce paper sous le nom de services *partitionnels*). Les services partitionnels fournissent leur plan de contrôle en une seule Région AWS fois. Certains services partitionnels, tels que AWS Network Manager, ne concernent que le plan de contrôle et orchestrent le plan de données d'autres services. D'autres services partitionnels, tels queIAM, possèdent leur propre plan de données qui est isolé et distribué sur l'ensemble de Régions AWS la partition. Les défaillances d'un service partitionnel n'ont aucune incidence sur les autres partitions. Dans la `aws` partition, le plan de contrôle du IAM service se trouve dans la `us-east-1` région, avec des plans de données isolés dans chaque région de la partition. Les services partitionnels disposent également de plans de contrôle et de plans de données indépendants dans les `aws-cn` partitions `aws-us-gov` et. La séparation du plan de contrôle et du plan de données pour IAM est illustrée dans le schéma suivant. ![\[Cette image illustre un plan de contrôle unique et un plan de données régionalisé IAM\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-fault-isolation-boundaries/images/iam-single-control-plane-and-regionalized-data-plane.png) Les services partitionnels et l'emplacement de leur plan de contrôle dans la `aws` partition sont les suivants : + AWS IAM (`us-east-1`) + AWS Organizations (`us-east-1`) + AWS Gestion de compte (`us-east-1`) + Route 53 Application Recovery Controller (ARC) (`us-west-2`) - Ce service n'est présent que dans la `aws` partition + AWS Gestionnaire de réseau (`us-west-2`) + Route 53 privée DNS (`us-east-1`) Si l'un de ces plans de contrôle de service présente un événement ayant une incidence sur la disponibilité, vous ne pourrez peut-être pas utiliser les opérations de CRUDL type -fournies par ces services. Ainsi, si votre stratégie de reprise dépend de ces opérations, un impact sur la disponibilité du plan de contrôle ou de la région hébergeant le plan de contrôle réduira vos chances de réussite du rétablissement. [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md)fournit des stratégies pour supprimer les dépendances vis-à-vis des plans de contrôle de service globaux lors de la restauration. ****Recommandation**** Ne vous fiez pas aux plans de contrôle des services partitionnels dans votre processus de restauration. Fiez-vous plutôt aux opérations du plan de données de ces services. Consultez [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) pour plus de détails sur la manière dont vous devez concevoir pour les services partitionnels. ## Des services mondiaux dans le réseau de pointe L'ensemble de AWS services mondiaux suivant possède un plan de contrôle dans la `aws` partition et héberge ses plans de données dans l'infrastructure [des points de présence](points-of-presence.md) mondiaux (PoP) (et potentiellement Régions AWS aussi). Les plans de données hébergés dans sont PoPs accessibles à partir des ressources de n'importe quelle partition ainsi que sur Internet. Par exemple, la Route 53 exploite son plan de contrôle dans la `us-east-1` région, mais son plan de données est distribué sur des centaines de sites dans PoPs le monde entier, ainsi que sur chacun d'entre eux Région AWS (pour prendre en charge la Route 53 publique et privée DNS dans la région). Les contrôles de santé de la Route 53 font également partie du plan de données et sont effectués à partir de huit Régions AWS points de la `aws` partition. Les clients peuvent résoudre leurs problèmes à DNS l'aide des zones hébergées publiques Route 53 depuis n'importe où sur Internet GovCloud, y compris d'autres partitions, ainsi que depuis un cloud privé AWS virtuel (VPC). Les services de réseau périphérique mondiaux et l'emplacement de leur plan de contrôle dans la `aws` partition sont les suivants : + Route 53 publique DNS (1`us-east-1`) + Amazon CloudFront (`us-east-1`) + AWS WAF Classique pour CloudFront (`us-east-1`) + AWS WAF pour CloudFront (`us-east-1`) + Amazon Certificate Manager (ACM) pour CloudFront (`us-east-1`) + AWSAccélérateur mondial (AGA) (`us-west-2`) + AWS Shield Advanced (`us-east-1`) Si vous utilisez des contrôles de AGA santé pour les EC2 instances ou les adresses IP élastiques, ceux-ci utilisent les contrôles de santé Route 53. La création ou AGA la mise à jour des bilans de santé dépendrait du plan de contrôle de la Route 53 intégré`us-east-1`. L'exécution des bilans de AGA santé utilise le plan de données des bilans de santé Route 53. Lors d'une panne affectant la région hébergeant les plans de contrôle de ces services, ou d'une panne affectant le plan de contrôle lui-même, il se peut que vous ne puissiez pas utiliser les opérations de CRUDL type -type fournies par ces services. Si vous avez intégré des dépendances à ces opérations dans votre stratégie de restauration, celle-ci a moins de chances de réussir que si vous vous fiez uniquement au plan de données de ces services. ****Recommandation**** Ne vous fiez pas au plan de contrôle des services du réseau périphérique dans votre processus de restauration. Fiez-vous plutôt aux opérations du plan de données de ces services. Consultez [Annexe B - Guide de service global pour les réseaux Edge](appendix-b---edge-network-global-service-guidance.md) pour plus de détails sur la façon de concevoir des services mondiaux dans le réseau de périphérie. ## Opérations mondiales dans une seule région La dernière catégorie est composée d'opérations de plan de contrôle spécifiques au sein d'un service ayant une portée globale, et non de services complets comme dans les catégories précédentes. Lorsque vous interagissez avec les services zonaux et régionaux de la région que vous spécifiez, certaines opérations dépendent d'une seule région différente de celle où se trouve la ressource. Ils sont différents des services qui ne sont fournis que dans une seule région ; consultez la liste de ces services. [Annexe C - Services d'une seule région](appendix-c---single-region-services.md) Lors d'une panne ayant un impact sur la dépendance globale sous-jacente, il se peut que vous ne puissiez pas utiliser les actions de CRUDL type des opérations dépendantes. Si vous avez intégré des dépendances à ces opérations dans votre stratégie de restauration, celle-ci a moins de chances de réussir que si vous vous fiez uniquement au plan de données de ces services. Vous devez éviter de dépendre de ces opérations dans le cadre de votre stratégie de restauration. Voici une liste de services dont d'autres services peuvent dépendre et qui ont une portée globale : + **Route 53** Plusieurs AWS services créent des ressources qui fournissent un ou plusieurs DNS noms spécifiques aux ressources. Par exemple, lorsque vous configurez un Elastic Load Balancer (ELB), le service crée des DNS dossiers publics et des bilans de santé dans Route 53 pour le. ELB Cela repose sur le plan de contrôle de la Route 53 intégré`us-east-1`. Les autres services que vous utilisez peuvent également avoir besoin de configurerELB, de créer des DNS enregistrements publics de Route 53 ou de créer des bilans de santé Route 53 dans le cadre de leurs flux de travail sur le plan de contrôle. Par exemple, le provisionnement d'une REST API ressource Amazon API Gateway, d'une base de données Amazon Relational Database Service (RDSAmazon) ou d'un domaine OpenSearch Amazon Service entraîne la DNS création d'enregistrements dans Route 53. Voici une liste des services dont le plan de contrôle dépend du plan de contrôle de la Route 53 `us-east-1` pour créer, mettre à jour ou supprimer des DNS enregistrements, héberger des zones et/ou créer des bilans de santé de la Route 53. Cette liste n'est pas exhaustive ; elle vise à mettre en évidence certains des services les plus couramment utilisés dont les actions du plan de contrôle pour créer, mettre à jour ou supprimer des ressources dépendent du plan de contrôle Route 53 : + Amazon API Gateway REST et HTTP APIs + RDSInstances Amazon + Bases de données Amazon Aurora + ELBÉquilibreurs de charge Amazon + AWS PrivateLink VPCpoints de terminaison + AWS Lambda URLs + Amazon ElastiCache + Amazon OpenSearch Service + Amazon CloudFront + Amazon MemoryDB + Amazon Neptune + Accélérateur Amazon DynamoDB () DAX + AGA + Amazon Elastic Container Service (AmazonECS) avec service Discovery DNS basé sur (qui utilise le AWS Cloud Map API pour gérer Route 53DNS) + Plan de contrôle Amazon EKS Kubernetes Il est important de noter que le VPC DNS service, [EC2par exemple, les noms d'hôtes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html) existent indépendamment dans chacun d'eux Région AWS et ne dépendent pas du plan de contrôle Route 53. Les enregistrements AWS créés pour EC2 des instances du VPC DNS service, telles que`ip-10-0-10.ec2.internal`, `ip-10-0-1-5.compute.us-west-2.compute.internal``i-0123456789abcdef.ec2.internal`, et`i-0123456789abcdef.us-west-2.compute.internal`, ne s'appuient pas sur le plan de contrôle Route 53 intégré`us-east-1`. ****Recommandation**** Ne vous fiez pas à la création, à la mise à jour ou à la suppression de ressources qui nécessitent la création, la mise à jour ou la suppression d'enregistrements de ressources Route 53, de zones hébergées ou de bilans de santé dans votre parcours de restauration. Préapprovisionnez ces ressources, par exempleELBs, pour éviter de dépendre du plan de contrôle Route 53 dans votre chemin de restauration. + **Amazon S3** Les opérations suivantes du plan de contrôle Amazon S3 dépendent `us-east-1` de la `aws` partition. Une panne affectant Amazon S3 ou d'autres services `us-east-1` pourrait perturber les actions de ces plans de contrôle dans d'autres régions : ``` PutBucketCors DeleteBucketCors PutAccelerateConfiguration PutBucketRequestPayment PutBucketObjectLockConfiguration PutBucketTagging DeleteBucketTagging PutBucketReplication DeleteBucketReplication PutBucketEncryption DeleteBucketEncryption PutBucketLifecycle DeleteBucketLifecycle PutBucketNotification PutBucketLogging DeleteBucketLogging PutBucketVersioning PutBucketPolicy DeleteBucketPolicy PutBucketOwnershipControls DeleteBucketOwnershipControls PutBucketAcl PutBucketPublicAccessBlock DeleteBucketPublicAccessBlock ``` Le plan de contrôle des points d'accès multirégionaux Amazon S3 (MRAP) est [hébergé uniquement dans](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html) cette région `us-west-2` et les demandes de création, de mise à jour ou de suppression MRAPs ciblent directement cette région. Le plan de contrôle de possède MRAP également des dépendances sous-jacentes sur AGA in`us-west-2`, Route 53 in `us-east-1` et ACM dans chaque région à partir de laquelle MRAP il est configuré pour diffuser du contenu. Vous ne devez pas dépendre de la disponibilité du plan de MRAP contrôle dans votre chemin de restauration ou dans les plans de données de vos propres systèmes. Cela se distingue des [contrôles de MRAP basculement](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapFailover.html) utilisés pour spécifier l'état de routage actif ou passif pour chacun de vos compartiments dans le. MRAP Ils APIs sont hébergés dans [cinq unités Régions AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MrapOperations.html#update-mrap-route-configuration) et peuvent être utilisés pour transférer efficacement le trafic à l'aide du plan de données du service. En outre, les [noms des compartiments Amazon S3 sont uniques à l'échelle mondiale](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html) `CreateBucket` et tous les appels vers la `aws` partition et `DeleteBucket` APIs dépendent `us-east-1` de celle-ci pour garantir l'unicité du nom, même si l'APIappel est dirigé vers la région spécifique dans laquelle vous souhaitez créer le compartiment. Enfin, si vos flux de travail de création de compartiments sont essentiels, vous ne devez pas vous fier à la disponibilité d'une orthographe spécifique pour le nom d'un bucket, en particulier ceux qui suivent un schéma perceptible. ****Recommandation**** Ne vous fiez pas à la suppression ou à la création de nouveaux compartiments S3 ou à la mise à jour de configurations de compartiments S3 dans le cadre de votre processus de restauration. Préapprovisionnez tous les compartiments S3 requis avec les configurations nécessaires afin de ne pas avoir à apporter de modifications pour récupérer après une panne. Cette approche s'applique MRAPs également à. + **CloudFront** Amazon API Gateway fournit des points de terminaison [optimisés pour les périphériques API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html#api-gateway-api-endpoint-types-edge-optimized). La création de ces points de terminaison dépend du plan CloudFront de contrôle utilisé `us-east-1` pour créer la distribution devant le point de terminaison de la passerelle. ****Recommandation**** Ne vous fiez pas à la création de nouveaux points de terminaison API Gateway optimisés pour les périphériques dans le cadre de votre processus de restauration. Préapprovisionnez tous les points de terminaison API Gateway requis. Toutes les dépendances abordées dans cette section sont des actions du plan de contrôle, et non des actions du plan de données. Si vos charges de travail sont configurées pour être statiquement stables, ces dépendances ne devraient pas avoir d'impact sur votre chemin de restauration, en gardant à l'esprit que la stabilité statique nécessite du travail ou des services supplémentaires à mettre en œuvre. ## Services utilisant des points de terminaison globaux par défaut Dans certains cas, les AWS services fournissent un point de terminaison global par défaut, tel que AWS Security Token Service ([AWS STS](https://docs.aws.amazon.com/general/latest/gr/sts.html)). D'autres services peuvent utiliser ce point de terminaison global par défaut dans leur configuration par défaut. Cela signifie qu'un service régional que vous utilisez peut avoir une dépendance globale à l'égard d'un service unique Région AWS. Les informations suivantes expliquent comment supprimer les dépendances involontaires sur les points de terminaison globaux par défaut afin de vous aider à utiliser le service de manière régionale. **AWS STS:** STS est un service Web qui vous permet de demander des informations d'identification temporaires à privilèges limités pour IAM les utilisateurs ou pour les utilisateurs que vous authentifiez (utilisateurs fédérés). STSl'utilisation depuis le kit de développement AWS logiciel (SDK) et l'interface de ligne de commande (CLI) est définie par défaut sur`us-east-1`. Le STS service fournit également des points de terminaison régionaux. Ces points de terminaison sont activés par défaut dans les régions qui le sont également par défaut. Vous pouvez en tirer parti à tout moment en configurant votre SDK ou en suivant les instructions CLI suivantes : Points de [terminaison AWS STS régionalisés](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html). L'utilisation de SigV4a [nécessite également des informations d'identification temporaires demandées à un point de terminaison régional STS](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#signature-versions). Vous ne pouvez pas utiliser le point de STS terminaison global pour cette opération. ****Recommandation**** Mettez à jour votre CLI configuration SDK et pour utiliser les STS points de terminaison régionaux. **Connexion au langage de balisage d'assertions de sécurité (SAML) :** SAML les services existent partout. Régions AWS Pour utiliser ce service, choisissez le point de SAML terminaison régional approprié, tel que [https://us-west-2.signin.aws.amazon.com/saml](https://us-west-2.signin.aws.amazon.com/saml). Vous devez mettre à jour les configurations de vos politiques de confiance et de votre fournisseur d'identité (IdP) pour utiliser les points de terminaison régionaux. Reportez-vous à la [AWS SAMLdocumentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) pour plus de détails. Si vous utilisez un IdP qui est également hébergé sur AWS, il existe un risque qu'il soit également impacté en cas de AWS panne. Cela peut vous empêcher de mettre à jour la configuration de votre IdP ou de vous opposer à une fédération complète. Vous devez pré-approvisionner les utilisateurs « break-glass » au cas où votre IdP serait défaillant ou indisponible. Reportez-vous à [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) pour plus de détails sur la façon de créer des utilisateurs break-glass de manière statiquement stable. ****Recommandation**** Mettez à jour vos politiques de confiance IAM dans les rôles pour accepter SAML les connexions provenant de plusieurs régions. En cas de panne, mettez à jour la configuration de votre IdP pour utiliser un point de SAML terminaison régional différent si votre point de terminaison préféré est altéré. Créez un ou plusieurs utilisateurs au cas où votre IdP serait défaillant ou indisponible. **AWS IAMIdentity Center :** Identity Center est un service basé sur le cloud qui facilite la gestion centralisée de l'accès par authentification unique aux applications cloud Comptes AWS et aux applications du client. Identity Center doit être déployé dans une seule région de votre choix. Toutefois, le comportement par défaut du service consiste à utiliser le point de SAML terminaison global ([https://signin.aws.amazon.com/saml](https://signin.aws.amazon.com/saml)), qui est hébergé dans`us-east-1`. Si vous avez déployé Identity Center dans un autre Région AWS, vous devez mettre à jour l'[état du relais](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtopermrelaystate.html) URL de chaque ensemble d'autorisations afin de cibler le même point de terminaison de console régional que votre déploiement d'Identity Center. [Par exemple, si vous avez déployé Identity Center dans`us-west-2`, vous devez mettre à jour l'état de relais de vos ensembles d'autorisations pour utiliser https://us-west-2.console.aws.amazon.com.](https://us-west-2.console.aws.amazon.com) Cela supprimera toute dépendance `us-east-1` à l'égard de votre déploiement d'Identity Center. En outre, étant donné qu'IAMIdentity Center ne peut être déployé que dans une seule région, vous devez pré-approvisionner les utilisateurs « révolutionnaires » au cas où votre déploiement serait perturbé. Reportez-vous à [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) pour plus de détails sur la façon de créer des utilisateurs break-glass de manière statiquement stable. ****Recommandation**** Définissez l'état URL de relais de vos ensembles d'autorisations dans IAM Identity Center pour qu'il corresponde à la région dans laquelle le service est déployé. Créez un ou plusieurs utilisateurs exceptionnels au cas où le déploiement de votre IAM Identity Center ne serait pas disponible. **Amazon S3 Storage Lens :** Storage Lens fournit un tableau de bord par défaut appelé default-account-dashboard. La configuration du tableau de bord et ses métriques associées sont stockées dans`us-east-1`. Vous pouvez créer des tableaux de bord supplémentaires dans d'autres régions en spécifiant la [région d'origine pour la](https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html#storage_lens_basics_home_region) configuration du tableau de bord et les données métriques. ****Recommandation**** Si vous avez besoin de données provenant du tableau de bord par défaut de S3 Storage Lens lors d'une panne affectant le service`us-east-1`, créez un tableau de bord supplémentaire dans une autre région d'origine. Vous pouvez également dupliquer tout autre tableau de bord personnalisé que vous avez créé dans d'autres régions. ## Récapitulatif des services mondiaux Les plans de données pour les services mondiaux appliquent des principes d'isolation et d'indépendance similaires à ceux AWS des services régionaux. Une défaillance ayant un impact sur le plan de données IAM d'une région n'affecte pas le fonctionnement du plan de IAM données dans une autre Région AWS région. De même, une panne affectant le plan de données de la Route 53 dans un PoP n'affecte pas le fonctionnement du plan de données Route 53 dans le reste du PoPs. Par conséquent, nous devons prendre en compte les événements de disponibilité du service qui affectent la région dans laquelle le plan de contrôle opère ou qui affectent le plan de contrôle lui-même. Comme il n'existe qu'un seul plan de contrôle pour chaque service global, une défaillance affectant ce plan de contrôle peut avoir des effets interrégionaux sur les opérations de CRUDL type (qui sont les opérations de configuration généralement utilisées pour installer ou configurer un service par opposition à l'utilisation directe du service). La méthode la plus efficace pour concevoir des charges de travail afin d'utiliser les services globaux de manière résiliente consiste à utiliser la stabilité statique. Lors d'un scénario de panne, concevez votre charge de travail de manière à ne pas avoir à apporter de modifications à un plan de contrôle pour atténuer l'impact ou à basculer vers un autre emplacement. Consultez [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) et obtenez [Annexe B - Guide de service global pour les réseaux Edge](appendix-b---edge-network-global-service-guidance.md) des conseils prescriptifs sur la manière d'utiliser ces types de services globaux afin de supprimer les dépendances au plan de contrôle et d'éliminer les points de défaillance uniques. Si vous avez besoin des données d'une opération du plan de contrôle à des fins de restauration, mettez ces données en cache dans un magasin de données accessible via son plan de données, tel qu'un paramètre de magasin de paramètres de [AWS Systems Manager](https://aws.amazon.com/systems-manager/) (SSMmagasin de paramètres), une table DynamoDB ou un compartiment S3. Pour des raisons de redondance, vous pouvez également choisir de stocker ces données dans une région supplémentaire. Par exemple, conformément aux [meilleures pratiques](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.html) pour Route 53 Application Recovery Controller (ARC), vous devez coder en dur ou ajouter vos cinq points de terminaison de cluster régional à vos favoris. Lors d'une panne, il se peut que vous ne puissiez pas accéder à certaines API opérations, notamment les ARC API opérations Route 53 qui ne sont pas hébergées sur le cluster de plans de données extrêmement fiable. Vous pouvez répertorier les points de terminaison de vos ARC clusters Route 53 en utilisant l'`DescribeCluster`APIopération. Voici un résumé de certaines des erreurs de configuration ou des anti-modèles les plus courants qui introduisent des dépendances sur les plans de contrôle des services globaux : + Apporter des modifications aux enregistrements Route 53, par exemple en mettant à jour la valeur d'un enregistrement A ou en modifiant les poids d'un ensemble d'enregistrements pondéré, pour effectuer un basculement. + Création ou mise à jour de IAM ressources, notamment de IAM rôles et de politiques, lors d'un basculement. Ce n'est généralement pas intentionnel, mais cela peut être le résultat d'un plan de basculement non testé. + S'appuyer sur IAM Identity Center pour permettre aux opérateurs d'accéder aux environnements de production en cas de panne. + En vous basant sur la configuration par défaut d'IAMIdentity Center pour utiliser la console `us-east-1` lorsque vous avez déployé Identity Center dans une autre région. + Modification de la pondération AGA du trafic pour effectuer manuellement un basculement régional. + Mettre à jour la configuration d'origine d'une CloudFront distribution pour qu'elle échoue à éliminer une origine altérée. + Provisionner des ressources de reprise après sinistre (DR), telles que ELBs des RDS instances en cas de panne, qui dépendent de la création d'DNSenregistrements dans Route 53. Ce qui suit est un résumé des recommandations fournies dans cette section pour utiliser les services mondiaux de manière résiliente afin de prévenir les anciens modèles anti-modèles courants. ****Résumé des recommandations**** Ne vous fiez pas aux plans de contrôle des services partitionnels dans votre processus de restauration. Fiez-vous plutôt aux opérations du plan de données de ces services. Consultez [Annexe A - Directives relatives aux services partitionnés](appendix-a---partitional-service-guidance.md) pour plus de détails sur la manière dont vous devez concevoir pour les services partitionnels. Ne vous fiez pas au plan de contrôle des services du réseau périphérique dans votre processus de restauration. Fiez-vous plutôt aux opérations du plan de données de ces services. Consultez [Annexe B - Guide de service global pour les réseaux Edge](appendix-b---edge-network-global-service-guidance.md) pour plus de détails sur la façon de concevoir des services mondiaux dans le réseau de périphérie. Ne vous fiez pas à la création, à la mise à jour ou à la suppression de ressources qui nécessitent la création, la mise à jour ou la suppression d'enregistrements de ressources Route 53, de zones hébergées ou de bilans de santé dans votre parcours de restauration. Préapprovisionnez ces ressources, par exempleELBs, pour éviter de dépendre du plan de contrôle Route 53 dans votre chemin de restauration. Ne vous fiez pas à la suppression ou à la création de nouveaux compartiments S3 ou à la mise à jour de configurations de compartiments S3 dans le cadre de votre processus de restauration. Préapprovisionnez tous les compartiments S3 requis avec les configurations nécessaires afin de ne pas avoir à apporter de modifications pour récupérer après une panne. Cette approche s'applique MRAPs également à. Ne vous fiez pas à la création de nouveaux points de terminaison API Gateway optimisés pour les périphériques dans le cadre de votre processus de restauration. Préapprovisionnez tous les points de terminaison API Gateway requis. Mettez à jour votre CLI configuration SDK et pour utiliser les STS points de terminaison régionaux. Mettez à jour vos politiques de confiance IAM dans les rôles pour accepter SAML les connexions provenant de plusieurs régions. En cas de panne, mettez à jour la configuration de votre IdP pour utiliser un point de SAML terminaison régional différent si votre point de terminaison préféré est altéré. Créez des utilisateurs Break Glass au cas où votre IdP serait défaillant ou indisponible. Définissez l'état URL de relais de vos ensembles d'autorisations dans IAM Identity Center pour qu'il corresponde à la région dans laquelle le service est déployé. Créez un ou plusieurs utilisateurs exceptionnels au cas où le déploiement de votre Identity Center ne serait pas disponible. Si vous avez besoin de données provenant du tableau de bord par défaut de S3 Storage Lens lors d'une panne affectant le service`us-east-1`, créez un tableau de bord supplémentaire dans une autre région d'origine. Vous pouvez également dupliquer tout autre tableau de bord personnalisé que vous avez créé dans d'autres régions.