# AWS Well-Architected Framework
Date de publication : **3 octobre 2023** ([Révisions du document](document-revisions.md))
AWS Well-Architected Framework vous aide à comprendre les avantages et les inconvénients des décisions que vous prenez lors du développement de systèmes sur AWS. En utilisant ce cadre, vous apprendrez les bonnes pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, économiques et durables dans le cloud.
## Introduction
AWS Well-Architected Framework vous aide à comprendre les avantages et les inconvénients des décisions que vous prenez lors du développement de systèmes sur AWS. En utilisant ce cadre, vous apprenez les bonnes pratiques architecturales en matière de conception et d'exploitation de charges de travail fiables, sécurisées, efficaces, économiques et durables dans le AWS Cloud. Il vous permet d'évaluer systématiquement vos architectures par rapport aux bonnes pratiques et d'identifier les domaines à améliorer. Le processus d'examen d'une architecture repose sur une discussion constructive sur les décisions architecturales, et non un mécanisme d'audit. Nous pensons que l'adoption de systèmes Well-Architected augmente considérablement les chances de réussite d'une entreprise.
Les architectes de solutions AWS ont des années d'expérience en architecture de produits sur une très grande variété de segments verticaux commerciaux et de cas d'utilisation. Nous avons contribué à la conception et à la vérification de milliers d'architectures client sur AWS. Sur la base de cette expérience, nous avons identifié les bonnes pratiques et les principales stratégies d'architecture de systèmes dans le Cloud.
Well-Architected Framework AWS documente un ensemble de questions de base afin de vous aider à évaluer si une architecture spécifique respecte bien les bonnes pratiques du cloud. Le cadre offre une approche cohérente pour évaluer les systèmes par rapport aux qualités attendues des systèmes modernes basés sur le Cloud, ainsi que les corrections requises pour atteindre ces qualités. Comme AWS évolue en permanence et que nous ne cessons d'apprendre en collaborant avec nos clients, nous continuerons à affiner la définition de « well-architected ».
Le présent outil est conçu pour ceux qui sont occupent des postes technologiques, comme les directeurs de la technologie, les architectes, les développeurs et les membres de l'équipe d'exploitation. Il décrit les stratégies et les bonnes pratiques AWS à utiliser lors de la conception et de l'exécution d'une charge de travail dans le cloud, et fournit des liens vers d'autres détails de mise en œuvre et modèles d'architecture. Pour en savoir plus, consultez [Page d'accueil AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp).
AWS fournit également un service gratuit pour vérifier vos charges de travail. La [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (AWS WA Tool) est un service dans le cloud qui fournit un processus uniforme pour que vous puissiez vérifier et mesurer votre architecture à l'aide d'AWS Well-Architected Framework. AWS WA Tool offre des recommandations qui vous permettent de renforcer la fiabilité, la sécurité, l'efficacité et la rentabilité de vos charges de travail.
Pour vous aider à appliquer les bonnes pratiques, nous avons créé [des ateliers AWS Well-Architected,](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp)qui vous fournissent un référentiel de code et de documentation afin de vous donner une expérience pratique de mise en œuvre des bonnes pratiques. Nous avons également fait équipe avec des partenaires du réseau de partenaires AWS (APN) triés sur le volet et eux-mêmes membres du [programme de partenariat AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp). Ces partenaires AWS disposent de connaissances approfondies sur AWS et peuvent vous aider à vérifier et améliorer vos charges de travail.
# Définitions
Chaque jour, les experts AWS aident les clients à concevoir des systèmes afin de tirer parti des bonnes pratiques dans le cloud. Nous collaborons avec vous pour parvenir à des compromis architecturaux au fur et à mesure que vos conceptions évoluent. Lorsque vous déployez ces systèmes dans des environnements réels, nous découvrons leurs performances réelles ainsi que les conséquences de ces compromis.
Grâce aux enseignements acquis, nous avons créé AWS Well-Architected Framework, qui fournit un ensemble cohérent de bonnes pratiques pour les clients et les partenaires, afin d'évaluer les architectures. Il inclut également un ensemble de questions dont vous pouvez vous inspirer pour évaluer le degré de conformité d'une architecture aux bonnes pratiques AWS.
Le cadre AWS Well-Architected Framework repose sur six piliers, à avoir l'Excellence opérationnelle, la Sécurité, la Fiabilité, l'Efficacité des performances, l'Optimisation des coûts et la Durabilité.
**Tableau 1. Les piliers d'AWS Well-Architected Framework**
| **Nom** | **Description** |
| --- | --- |
| Excellence opérationnelle | Capacité de soutenir le développement et de gérer efficacement les charges de travail, de recueillir des informations sur leurs opérations et d'améliorer continuellement les processus et procédures de soutien afin de fournir de la valeur ajoutée. |
| Sécurité | Le pilier Sécurité décrit comment tirer parti des technologies du cloud pour protéger les données, les systèmes et les ressources de manière à améliorer votre niveau de sécurité. |
| Fiabilité | Le pilier Fiabilité englobe la capacité d'une charge de travail à exécuter sa fonction de manière correcte et cohérente et ce, en temps utile. Cela inclut la possibilité d'exploiter et de tester la charge de travail tout au long de son cycle de vie. Ce livre blanc fournit des bonnes pratiques détaillées pour la mise en œuvre de charges de travail fiables sur AWS. |
| Efficacité en matière de performance | Capacité à utiliser efficacement les ressources informatiques pour satisfaire aux exigences système et à maintenir cette efficacité au fur et à mesure que la demande change et que les technologies évoluent. |
| Optimisation des coûts | Possibilité d'exécuter des systèmes pour proposer une valeur commerciale au prix le plus bas. |
| Durabilité | Capacité d'améliorer continuellement les impacts sur la durabilité via la réduction de la consommation d'énergie et l'amélioration de l'efficacité de tous les composants d'une charge de travail en maximisant les avantages des ressources allouées et en minimisant les ressources totales requises. |
Dans le cadre AWS Well-Architected Framework, nous utilisons les termes suivants :
+ A **Un composant** représente le code, la configuration et les ressources AWS qui répondent ensemble à une exigence commerciale. Un composant est souvent une unité de propriété technique. Il est découplé des autres composants.
+ Le terme **scalable** est utilisé pour désigner un ensemble de composants qui collaborent pour apporter une valeur métier. L'application représente généralement le niveau de détails dont discutent les responsables métier et techniques.
+ Nous considérons **l'architecture** comme la façon dont les composants fonctionnent ensemble dans une charge de travail. Les schémas d'architecture se concentrent souvent sur la manière dont les composants communiquent et interagissent entre eux.
+ **Les Milestones (Événements)** signalent les modifications importantes de votre architecture à mesure de son évolution tout au long du cycle de vie du produit (conception, mise en place, tests, pré-production et production).
+ Au sein d'une entreprise, **le portefeuille technologique** est l'ensemble des charges de travail qui sont nécessaires au bon fonctionnement de l'entreprise.
+ La **niveau d'effort** consiste à catégoriser le temps, les efforts et la complexité qu'une tâche nécessite pour sa mise en œuvre. Chaque organisation doit tenir compte de la taille et de l'expertise de l'équipe et de la complexité de la charge de travail comme contexte supplémentaire afin de catégoriser correctement son niveau d'effort.
+ **Élevé :** Le projet peut prendre plusieurs semaines, voire plusieurs mois. Il pourrait être divisé en plusieurs scénarios, versions et tâches.
+ **Moyen :** Le projet peut prendre plusieurs jours, voire plusieurs semaines. Il pourrait être divisé en plusieurs versions et tâches.
+ **Faible :** Le projet peut prendre plusieurs heures, voire plusieurs jours. Il pourrait être divisé en plusieurs tâches.
Lorsque vous concevez des charges de travail, vous faites des compromis entre des piliers en fonction de votre contexte commercial. Ces décisions métier peuvent vous aider à gérer vos priorités techniques. Vous pouvez opter pour l'optimisation afin d'améliorer l'impact sur la durabilité et de réduire les coûts au détriment de la fiabilité dans les environnements de développement, ou, pour les solutions stratégiques, vous pouvez optimiser la fiabilité avec des coûts plus élevés et un impact plus important sur la durabilité. Dans les solutions d'e-commerce, les performances peuvent affecter les revenus et la propension des clients à acheter les produits. La sécurité et l'excellence opérationnelle ne sont généralement pas la contrepartie des autres piliers.
# Sur l'architecture
Dans les environnements sur site, les clients possèdent souvent une équipe centrale pour l'architecture technologique, qui supervise les autres équipes dédiées aux produits ou aux fonctionnalités afin de vérifier qu'elles ont adopté les bonnes pratiques. Les équipes d'architecture technologique comptent généralement un ensemble de rôles, notamment : architecte technique (infrastructure), architecte de solutions (logiciel), architecte de données, architecte de mise en réseau et architecte de sécurité. Souvent, ces équipes utilisent [TOGAF](https://pubs.opengroup.org/architecture/togaf9-doc/arch/) ou le [cadre Zachman](https://zachman-feac.com/zachman/about-the-zachman-framework) en tant qu'élément de la capacité d'architecture de l'entreprise.
Chez AWS, nous préférons répartir les fonctionnalités entre plusieurs équipes dédiées plutôt que de ne recourir qu'à une seule équipe centralisée pour toutes les fonctionnalités. Il existe des risques lorsque vous choisissez de répartir les décisions. Par exemple, il faut vérifier que les équipes respectent les normes internes. Nous réduisons ces risques de deux manières. Tout d'abord, nous avons *les pratiques* (façons de procéder, processus, règles et autres normes acceptées) qui visent à permettre à chaque équipe de se charger de cette fonctionnalité comme il se doit, et nous avons recours à des experts afin de vérifier que les équipes dépassent les exigences. Ensuite, nous mettons en place *des mécanismes* qui effectuent des vérifications automatisées pour vérifier que les normes sont respectées.
****
« Les bonnes intentions ne suffisent pas, il faut de bons mécanismes pour tout rendre possible », Jeff Bezos.
Cela implique d'avoir recours à des mécanismes (souvent automatisés) qui vérifient la conformité aux règles ou aux processus plutôt que de faire appel à la bonne volonté des employés. Cette approche distribuée s'appuie sur les [principes de leadership d'Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)et établit une culture pour tous les rôles qui *travaillent à rebours* à partir du client. Le travail à rebours est un élément fondamental de notre processus d'innovation. Nous commençons par les clients et ce dont ils ont besoin, afin de définir et de guider nos efforts. Les équipes obsédées par le client fabriquent des produits en s'appuyant sur les besoins des clients.
Pour l'architecture, cela signifie que nous prévoyons que chaque équipe soit capable de créer des architectures et de suivre les bonnes pratiques. Pour aider les nouvelles équipes à s'approprier ces fonctionnalités, ou les équipes existantes à mettre la barre plus haut, nous activons l'accès à une communauté virtuelle d'ingénieurs en chef qui peuvent vérifier leurs conceptions et les aider à comprendre ce que sont les bonnes pratiques AWS. La communauté des ingénieurs principaux travaille pour rendre les bonnes pratiques visibles et accessibles. Une solution pourrait être, par exemple, d'organiser des discussions durant le déjeuner qui se concentrent sur l'application de bonnes pratiques à de véritables exemples. Ces discussions sont enregistrées et peuvent être utilisées dans le cadre de documents d'accueil pour les nouveaux membres de l'équipe.
Les bonnes pratiques AWS naissent de notre expérience dans l'exécution de milliers de systèmes à l'échelle d'Internet. Nous préférons utiliser des données pour définir les bonnes pratiques, mais utilisons également des experts fonctionnels en tant qu'ingénieurs principaux pour les définir. Lorsque les ingénieurs en chef voient l'émergence de nouvelles bonnes pratiques, ils collaborent afin de vérifier que les équipes les suivent. Avec le temps, ces bonnes pratiques sont officialisées dans nos processus d'évaluation internes, ainsi que dans les mécanismes qui renforcent la conformité. Le cadre Well-Architected est l'implémentation destinée aux clients de notre processus d'évaluation interne, où nous avons codifié notre réflexion sur l'ingénierie principale à travers les rôles tels que l'architecture de solutions et les équipes d'ingénieurs internes. Le cadre Well-Architected est un mécanisme évolutif qui vous permet de tirer parti de ces connaissances.
En suivant l'approche d'une communauté d'ingénierie principale avec une propriété d'architecture distribuée, nous pensons qu'une architecture d'entreprise Well-Architected reposant sur les besoins du client peut émerger. Nos leaders en matière de technologie (tels que les directeurs techniques ou les directeurs de développement), qui effectuent des évaluations Well-Architected sur toutes vos charges de travail, vous permettront de mieux comprendre les risques au sein de votre portefeuille de technologies. Cette approche vous permet d'identifier les thèmes, pour différentes équipes, que votre organisation pourrait aborder via les mécanismes, les formations, ou les discussions de midi où vos ingénieurs principaux peuvent partager leurs idées sur les domaines spécifiques avec plusieurs équipes.
# Principes généraux de conception
Le cadre Well-Architected identifie un ensemble de principes généraux de conception destinés à faciliter la bonne conception dans le Cloud :
+ **Une capacité réellement adaptée à vos besoins** : si vous prenez une mauvaise décision en matière de capacité lors du déploiement d'une charge de travail, il se peut que vous vous retrouviez face à des ressources inutilisées onéreuses, ou que vous deviez traiter les implications relatives aux performances d'une capacité limitée. Grâce au cloud computing, vous n'avez plus de soucis à vous faire. Vous pouvez utiliser autant ou aussi peu de capacité que vous le souhaitez, et l'augmenter ou la réduire automatiquement.
+ **Tester les systèmes à l'échelle de la production** : dans le cloud, vous pouvez créer un environnement de tests à l'échelle de la production et à la demande, exécuter les tests, puis mettre les ressources hors service. Puisque vous ne payez l'environnement de test que lorsqu'il s'exécute, vous pouvez simuler votre environnement réel pour une fraction du coût d'un test sur site.
+ **Automatiser en gardant à l'esprit l'expérimentation architecturale**: l'automatisation vous permet de créer et de répliquer vos charges de travail à un coût peu élevé et d'éviter les frais de main-d'œuvre. Vous pouvez suivre les modifications apportées à l'automatisation, auditer l'impact et rétablir les paramètres antérieurs si nécessaire.
+ **Tenir compte des architectures évolutives** : dans un environnement traditionnel, les décisions d'architecture sont souvent mises en place comme des événements statiques et fixes, avec quelques versions majeures d'un système pendant sa durée de vie. Tandis que l'entreprise et son contexte continuent à évoluer, ces décisions initiales peuvent entraver la capacité du système à satisfaire des exigences métier variables. Dans le cloud, la capacité d'automatiser et de tester les éléments à la demande réduit le risque d'impact des modifications de conception. Les systèmes peuvent ainsi évoluer au fil du temps, de telle sorte que les entreprises peuvent tirer profit des innovations dans le cadre d'une pratique standard.
+ **Créer des architectures basées sur des données** : dans le cloud, vous pouvez collecter des données sur la façon dont vos choix architecturaux affectent le comportement de votre charge de travail. Cela vous permet de prendre des décisions basées sur les faits sur la façon d'améliorer votre charge de travail. Votre infrastructure Cloud est codée. Vous pouvez donc utiliser ces données pour alimenter vos choix architecturaux et des améliorations au fil du temps.
+ **Améliorer les systèmes grâce aux journées jeu de rôle** : testez les performances de votre architecture et de vos processus en programmant régulièrement des tests de simulation de pannes, pour simuler des événements durant la production. Cela vous aidera à comprendre où apporter des améliorations et à développer une expérience de gestion des événements au sein de votre organisation.