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.
# infrastructure AWS
Cette section présente un résumé de l'infrastructure AWS globale et des limites d'isolation des pannes qu'elle fournit. En outre, cette section fournira un aperçu des concepts de plans de contrôle et de plans de données, qui constituent des distinctions essentielles dans la AWS conception de ses services. Ces informations fournissent la base de référence pour comprendre comment les limites d'isolation des pannes ainsi que le plan de contrôle et le plan de données d'un AWS service s'appliquent aux types de services dont nous parlerons dans la section suivante.
**Topics**
+ [Zones de disponibilité](availability-zones.md)
+ [Régions](regions.md)
+ [AWSZones Locales](aws-local-zones.md)
+ [AWS Outposts](aws-outposts.md)
+ [Points de présence](points-of-presence.md)
+ [Partitions](partitions.md)
+ [Plans de contrôle et plans de données](control-planes-and-data-planes.md)
+ [Stabilité statique](static-stability.md)
+ [Récapitulatif](summary.md)
# Zones de disponibilité
AWSgère plus de 100 zones de disponibilité dans plusieurs régions du monde (les chiffres actuels se trouvent ici : [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/)). Une zone de disponibilité est un ou plusieurs centres de données discrets dotés d'une infrastructure électrique, d'un réseau et d'une connectivité indépendants et redondants au sein d'unRégion AWS. Les zones de disponibilité d'une région sont nettement distantes les unes des autres, jusqu'à 60 miles (\$1100 km) pour éviter les défaillances corrélées, mais suffisamment proches pour utiliser la réplication synchrone avec une latence d'un chiffre en millisecondes. Ils sont conçus pour ne pas être simultanément affectés par un scénario de destin partagé, tel que l'alimentation en électricité, les ruptures d'eau, l'isolation par fibre optique, les tremblements de terre, les incendies, les tornades ou les inondations. Les points de défaillance courants, tels que les générateurs et les équipements de refroidissement, ne sont pas partagés entre les zones de disponibilité et sont conçus pour être alimentés par des sous-stations électriques indépendantes. Lors du AWS déploiement de mises à jour de ses services, les déploiements vers les zones de disponibilité d'une même région sont séparés dans le temps afin d'éviter toute défaillance corrélée.
Toutes les zones de disponibilité d'une région sont interconnectées par un réseau à bande passante élevée et à faible latence, via une fibre métropolitaine dédiée entièrement redondante. *Chaque zone de disponibilité d'une région est connectée à Internet via deux centres de transit où se trouvent des AWS homologues de plusieurs [fournisseurs Internet de niveau 1 (pour plus d'informations, reportez-vous à la section](https://en.wikipedia.org/wiki/Tier_1_network) [Présentation d'Amazon Web Services](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html?did=wp_card&trk=wp_card)).*
Ces fonctionnalités permettent d'isoler fortement les zones de disponibilité les unes des autres, ce que nous appelons l'indépendance des zones de disponibilité (AZI). La structure logique des zones de disponibilité et de leur connectivité à Internet est illustrée dans la figure suivante.
![\[Cette image montre comment les zones de disponibilité se composent d'un ou de plusieurs centres de données physiques connectés de manière redondante les uns aux autres et à Internet\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-fault-isolation-boundaries/images/availability-zones.png)
# Régions
Chacune Région AWS se compose de plusieurs zones de disponibilité indépendantes et physiquement séparées au sein d'une zone géographique. Toutes les régions disposent actuellement de trois zones de disponibilité ou plus. Les régions elles-mêmes sont isolées et indépendantes des autres régions, à quelques exceptions près indiquées plus loin dans ce document [(voir les opérations mondiales à une seule région)](global-services.md#global-single-region-operations). Cette séparation entre les régions limite les défaillances de service, lorsqu'elles se produisent, à une seule région. Les opérations normales des autres régions ne sont pas affectées dans ce cas. En outre, les ressources et les données que vous créez dans une région n'existent dans aucune autre région, sauf si vous utilisez explicitement une fonctionnalité de réplication ou de copie proposée par un AWS service ou si vous répliquez vous-même la ressource.
![\[Cette image illustre les régions AWS actuelles et prévues en décembre 2022.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-fault-isolation-boundaries/images/current-and-planned-aws-regions.png)
# AWSZones Locales
AWSLes [Zones Locales](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) sont un type de déploiement d'infrastructure qui place le calcul, le stockage, les bases de données et d'autres [AWSservices sélectionnés](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) à proximité de grands centres urbains et industriels. Vous pouvez utiliser AWS des services, tels que les services de calcul et de stockage, dans la zone locale pour exécuter des applications à faible latence en périphérie ou pour simplifier les migrations vers le cloud hybride. Les zones locales disposent d'une entrée et d'une sortie Internet locales pour réduire la latence, mais elles sont également connectées à leur région mère via le réseau privé redondant et à large bande passante d'Amazon, ce qui permet aux applications exécutées dans les zones AWS locales d'accéder rapidement, de manière sécurisée et fluide à la gamme complète de services.
# AWS Outposts
[AWS Outposts](https://aws.amazon.com/outposts/)est une famille de solutions entièrement gérées fournissant une AWS infrastructure et des services à pratiquement tous les sites sur site ou en périphérie pour une expérience hybride véritablement cohérente. Les solutions Outposts vous permettent d'étendre et d'exécuter des AWS services natifs sur site. Elles sont disponibles sous différents formats, des serveurs Outposts 1U et 2U aux racks Outposts 42U, en passant par les déploiements en rack multiples.
AvecAWS Outposts, vous pouvez exécuter [certains AWS services](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html#services) localement et vous connecter à un large éventail de services disponibles chez le parentRégion AWS. AWS Outpostssont des racks de calcul et de stockage entièrement gérés et configurables conçus avec du matériel AWS conçu qui permet aux clients d'exécuter des opérations de calcul et de stockage sur site, tout en se connectant facilement à AWS la vaste gamme de services dans le cloud.
# Points de présence
Outre les zones de disponibilité Régions AWS et de disponibilité, exploite AWS également un réseau mondial de points de présence distribués (PoP). Ils PoPs hébergent Amazon CloudFront, un réseau de diffusion de contenu (CDN) ; Amazon Route 53, un service public de résolution du système de noms de domaine (DNS) ; et AWS Global Accelerator (AGA), un service d'optimisation des réseaux de pointe. Le réseau Edge mondial comprend actuellement plus de 410 PoPs, dont plus de 400 emplacements Edge, et 13 caches régionaux de milieu de gamme dans plus de 90 villes dans 48 pays (le statut actuel peut être consulté ici : [Caractéristiques CloudFront principales d'Amazon](https://aws.amazon.com/cloudfront/features/)).
![\[Cette image montre le réseau périphérique CloudFront mondial d'Amazon\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/aws-fault-isolation-boundaries/images/amazon-cloudfront.png)
Chaque PoP est isolé des autres, ce qui signifie qu'une panne affectant un seul PoP ou une seule zone métropolitaine n'a pas d'impact sur le reste du réseau mondial. Le AWS réseau est compatible avec des milliers d'opérateurs de télécommunications de niveau 1/2/3 dans le monde entier, est bien connecté à tous les principaux réseaux d'accès pour des performances optimales et dispose de centaines de térabits de capacité déployée. Les sites périphériques sont connectés Régions AWS via le backbone du AWS réseau, une fibre parallèle 100 GbE multiple entièrement redondante qui fait le tour du monde et est reliée à des dizaines de milliers de réseaux pour améliorer la récupération des données d'origine et l'accélération dynamique du contenu.
# Partitions
AWSregroupe les régions en [partitions](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Chaque région se trouve exactement dans une partition, et chaque partition possède une ou plusieurs régions. Les partitions possèdent des instances indépendantes de Gestion des identités et des accès AWS (IAM) et fournissent une limite stricte entre les régions des différentes partitions. AWSLes régions commerciales sont dans la `aws` partition, les régions en Chine sont dans la `aws-cn` partition et AWS GovCloud les régions sont dans la `aws-us-gov` partition. Certains AWS services sont conçus pour fournir des fonctionnalités interrégionales, comme [Amazon S3 Cross-Region Replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) ou le peering [interrégional AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-peering.html). Ces types de fonctionnalités ne sont pris en charge qu'entre les régions d'une même partition. Vous ne pouvez pas utiliser les informations d'identification IAM d'une partition pour interagir avec les ressources d'une autre partition.
# Plans de contrôle et plans de données
AWSsépare la plupart des services entre les concepts de *plan de contrôle* et de *plan de données*. Ces termes proviennent du monde des réseaux, en particulier des routeurs. Le plan de données du routeur, qui est sa principale fonctionnalité, déplace les paquets selon des règles. Mais les politiques de routage doivent être créées et distribuées depuis quelque part, et c'est là qu'intervient le plan de contrôle.
Les plans de contrôle fournissent les API administratives utilisées pour créer, lire/décrire, mettre à jour, supprimer et répertorier les ressources (CRUDL). Par exemple, les actions suivantes concernent toutes le plan de contrôle : lancement d'une nouvelle instance [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2), création d'un bucket [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) et description d'une file d'attente [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) (Amazon SQS). Lorsque vous lancez une instance EC2, le plan de contrôle doit effectuer plusieurs tâches, telles que la recherche d'un hôte physique capable, l'allocation des interfaces réseau, la préparation d'un volume Amazon [Elastic Block Store (Amazon](https://aws.amazon.com/ebs/) EBS), la génération d'informations d'identification IAM, l'ajout des règles du groupe de sécurité, etc. Les plans de contrôle sont généralement des systèmes d'orchestration et d'agrégation complexes.
Le plan de données est la principale fonction du service. Par exemple, les éléments suivants constituent tous les éléments du plan de données pour chacun des services concernés : l'instance EC2 en cours d'exécution elle-même, la lecture et l'écriture sur un volume EBS, l'obtention et le placement d'objets dans un compartiment S3, et la Route 53 répondant aux requêtes DNS et effectuant des contrôles de santé.
Les plans de données sont volontairement moins compliqués, avec moins de pièces mobiles que les plans de contrôle, qui mettent généralement en œuvre un système complexe de flux de travail, de logique métier et de bases de données. Cela rend les événements de défaillance statistiquement moins susceptibles de se produire dans le plan de données par rapport au plan de contrôle. Bien que les données et le plan de contrôle contribuent au fonctionnement global et au succès du service, ils AWS sont considérés comme des composants distincts. Cette séparation présente à la fois des avantages en termes de performances et de disponibilité.
# Stabilité statique
L'une des caractéristiques de résilience les plus importantes des AWS services est ce que l'on AWS appelle la stabilité statique. Ce terme signifie que les systèmes fonctionnent dans un état statique et continuent de fonctionner normalement sans qu'il soit nécessaire d'apporter des modifications en cas de défaillance ou d'indisponibilité des dépendances. Nous y parvenons notamment en empêchant les dépendances circulaires dans nos services qui pourraient empêcher le rétablissement réussi de l'un de ces services. Une autre façon d'y parvenir est de maintenir l'état existant. Nous prenons en compte le fait que les plans de contrôle sont statistiquement plus susceptibles de tomber en panne que les plans de données. Bien que le plan de données dépende généralement des données provenant du plan de contrôle, le plan de données conserve son état existant et continue de fonctionner même en cas de détérioration du plan de contrôle. L'accès aux ressources par le plan de données, une fois provisionné, ne dépend pas du plan de contrôle et n'est donc pas affecté par une quelconque altération du plan de contrôle. En d'autres termes, même si la capacité de créer, de modifier ou de supprimer des ressources est réduite, les ressources existantes restent disponibles. Cela rend AWS les plans de données statiquement stables en cas de détérioration du plan de contrôle. Vous pouvez implémenter différents modèles pour être statiquement stable face à différents types de défaillances de dépendance.
Un exemple de stabilité statique peut être trouvé dans Amazon EC2. Une fois qu'une instance EC2 a été lancée, elle est tout aussi disponible que le serveur physique d'un centre de données. Il ne dépend d'aucune API du plan de contrôle pour continuer à fonctionner ou pour recommencer à fonctionner après un redémarrage. La même propriété vaut pour d'autres AWS ressources telles que les VPC, les compartiments et objets Amazon S3 et les volumes Amazon EBS.
La stabilité statique est un concept profondément ancré dans la AWS conception de ses services, mais c'est également un modèle qui peut être utilisé par les clients. En fait, la majorité des meilleures pratiques pour utiliser les différents types de AWS services de manière résiliente consistent à implémenter la stabilité statique pour les environnements de production. Les mécanismes de rétablissement et d'atténuation les plus fiables sont ceux qui nécessitent le moins de changements pour réaliser le rétablissement. Au lieu de compter sur le plan de contrôle EC2 pour lancer de nouvelles instances EC2 afin de procéder à une restauration après une défaillance d'une zone de disponibilité, le préprovisionnement de cette capacité supplémentaire permet d'obtenir une stabilité statique. Ainsi, l'élimination des dépendances à l'égard des plans de contrôle (les API qui mettent en œuvre les modifications apportées aux ressources) dans votre processus de restauration permet de produire des charges de travail plus résilientes. Pour plus de détails sur la stabilité statique, les plans de contrôle et les plans de données, consultez l'article [Static stability using Availability](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) Zones de la bibliothèque Amazon Builders.
# Récapitulatif
AWSutilise différents conteneurs de défauts dans notre infrastructure pour isoler les pannes. Les principaux conteneurs de défaillances de l'infrastructure sont les partitions, les régions, les zones de disponibilité, les plans de contrôle et les plans de données. Nous examinerons ensuite les différents types de AWS services, la manière dont ces conteneurs d'erreurs sont utilisés dans leur conception et la manière dont vous devez concevoir les charges de travail avec eux pour qu'elles soient résilientes.