Modèle de responsabilité partagée pour la résilience - Pilier Fiabilité

Modèle de responsabilité partagée pour la résilience

La résilience est une responsabilité partagée entre AWS et vous. Il est important que vous compreniez comment la reprise après sinistre (DR) et la disponibilité, qui font partie de la résilience, fonctionnent dans le cadre de ce modèle partagé.

AWS responsibility - Resiliency of the cloud (Responsabilité AWS : modèle de responsabilité partagée pour la résilience)

AWS est responsable de la résilience de l'infrastructure qui fait fonctionner tous les services proposés dans le AWS Cloud. Cette infrastructure comprend le matériel, les logiciels, les réseaux et les installations qui permettent d'exécuter les services AWS Cloud. AWS déploie des efforts commercialement raisonnables pour rendre ces services AWS Cloud disponibles, en veillant à ce que la disponibilité des services respecte ou dépasse les accords de niveau de service (SLA) AWS.

L'infrastructure de cloud mondial AWS est conçue pour permettre aux clients de créer des architectures de charges de travail hautement résilientes. Chaque Région AWS est entièrement isolée et se compose de plusieurs zones de disponibilité, qui sont des partitions physiquement isolées de l'infrastructure. Les zones de disponibilité isolent les défaillances susceptibles d'affecter la résilience des charges de travail, en les empêchant d'avoir un impact sur les autres zones de la région. Toutes les zones de disponibilité d'une Région AWS sont interconnectées avec un réseau à large bande passante et à faible latence, qui utilise une fibre métropolitaine dédiée entièrement redondante fournissant un réseau à haut débit et à faible latence entre les AZ. Tout le trafic entre les zones est chiffré. Les performances du réseau sont suffisantes pour réaliser une réplication synchrone entre les zones. Si une application est partitionnée sur plusieurs AZ, vous êtes mieux isolé et protégé contre les problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc.

Responsabilité du client : résilience dans le cloud

Votre responsabilité est déterminée par les services AWS Cloud que vous choisissez. Cela détermine la quantité de travail de configuration que vous devez effectuer dans le cadre de vos responsabilités en matière de résilience. Par exemple, un service tel que Amazon Elastic Compute Cloud (Amazon EC2) exige du client qu'il effectue toutes les tâches de configuration et de gestion de la résilience nécessaires. Les clients qui déploient des instances Amazon EC2 sont responsables du déploiement des instances Amazon EC2 sur plusieurs sites (tels que les zones de disponibilité AWS), de la mise en œuvre de l'auto-réparation à l'aide de services tels que Auto Scaling, et du respect des bonnes pratiques en matière d'architecture de charge de travail résiliente pour les applications installées sur les instances. Pour les services gérés, tels que Amazon S3 et Amazon DynamoDB, AWS exploite la couche infrastructure, le système d'exploitation et les plateformes, et les clients accèdent aux points de terminaison pour stocker et récupérer les données. Vous êtes responsable de la gestion de la résilience de vos données, y compris des stratégies de sauvegarde, de gestion des versions et de réplication.

Le déploiement de votre charge de travail dans plusieurs zones de disponibilité d'une Région AWS fait partie d'une stratégie de haute disponibilité conçue pour protéger les charges de travail en isolant les problèmes dans une zone de disponibilité donnée. Cette stratégie utilise la redondance des autres zones de disponibilité pour continuer à répondre aux requêtes. Une architecture Multi-AZ s'inscrit également dans une stratégie DR conçue pour mieux isoler et protéger les charges de travail contre des problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc. Les stratégies de DR peuvent également faire appel à de multiples Régions AWS. Par exemple, dans une configuration active/passive, le service de la charge de travail passe de sa région active à sa région DR si la région active ne peut plus répondre aux requêtes.

Graphique illustrant le modèle de résilience partagée.

Responsabilité de la résilience dans le cloud et de la résilience du cloud pour les clients et AWS.

Vous pouvez utiliser les services AWS pour atteindre vos objectifs de résilience. En tant que client, vous êtes responsable de la gestion des aspects suivants de votre système pour atteindre la résilience dans le cloud. Pour obtenir plus de détails sur chaque service en particulier, consultez la documentation AWS.

Réseaux, quotas et contraintes

  • Les bonnes pratiques pour ce domaine du modèle de responsabilité partagée sont décrites en détail dans la section Fondations.

  • Planifiez votre architecture en prévoyant une marge de manœuvre suffisante et comprenez les contraintes et les quotas de service que vous incorporez, en fonction des augmentations prévues de la demande de charge, le cas échéant.

  • Concevez votre topologie de réseau pour qu'elle soit hautement disponible, redondante et évolutive.

Gestion des modifications et résilience opérationnelle

Observabilité et gestion des pannes

Architecture de charge de travail

  • L'architecture de votre charge de travail comprend la manière dont vous concevez les services autour des domaines d'activité, dont vous appliquez l'architecture orientée services (SOA) et la conception des systèmes distribués pour éviter les pannes, et dont vous intégrez des capacités telles que la limitation, les tentatives, la gestion des files d'attente, les délais et les leviers d'urgence.

  • Appuyez-vous sur des solutions AWS éprouvées, les ressources Amazon Builders Library et les modèles sans serveur pour vous aligner sur les bonnes pratiques et lancer les mises en œuvre.

  • Utilisez l'amélioration continue pour décomposer votre système en services distribués afin d'évoluer et d'innover plus rapidement. Utilisez les conseils sur les microservices AWS et les options de services gérés pour simplifier et accélérer votre capacité à incorporer des modifications et à innover.

Test continu des infrastructures critiques

  • Tester la fiabilité signifie tester aux niveaux fonctionnel, des performances et du chaos. Cela nécessite en outre d'adopter des pratiques d'analyse d'incidents et de jeux de rôle pour acquérir une expertise dans la résolution des problèmes qui ne sont pas bien compris.

  • Pour les applications tout cloud et hybrides, le fait de savoir comment votre application se comporte lorsque des problèmes surviennent ou que des composants tombent en panne permet une reprise rapide et fiable après une panne.

  • Créez et documentez des expériences reproductibles pour comprendre comment votre système se comporte lorsque les objets ne fonctionnent pas comme prévu. Ces tests prouveront l'efficacité de votre résilience globale et fourniront une boucle de rétroaction pour vos procédures opérationnelles avant de vous confronter à des scénarios de panne réels.