# AWS Well-Architected Framework
Date de publication : **10 avril 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.
AWS Well-Architected Framework documente un ensemble de questions de base qui vous permettent de comprendre si une architecture spécifique respecte 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 la page d'accueil du cadre [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. [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 vous permettant de vérifier et de mesurer votre architecture à l'aide du cadre 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éé [AWS Well-Architected Labs](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), qui vous fournit un référentiel de code et de documentation pour vous donner l'expérience pratique nécessaire à la mise en œuvre des bonnes pratiques. Nous avons également fait équipe avec des partenaires du réseau de partenaires AWS (APN) sélectionnés, 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 | The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. |
| Sécurité | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. |
| Fiabilité | The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS. |
| Efficacité des performances | The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. |
| Optimisation des coûts | The ability to run systems to deliver business value at the lowest price point. |
| Durabilité | The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required. |
Dans le cadre AWS Well-Architected Framework, nous utilisons les termes suivants :
+ 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 **charge de travail** sert à identifier un ensemble de composants qui, ensemble, apportent une valeur commerciale. L'application représente généralement le niveau de détails dont discutent les responsables métier et techniques.
+ Nous considérons que l'**architecture** est le fonctionnement des composants 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 **étapes** 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 organisation, le **portefeuille technologique** est l'ensemble des charges de travail nécessaires pour que l'entreprise fonctionne.
+ Le **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 s'assurer 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é. Ces équipes utilisent souvent [TOGAF](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) ou le [cadre Zachman](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp) 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 s'assurer 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 ont pour but de permettre à chaque équipe de profiter de cette capacité, et nous avons mis en place des spécialistes afin de garantir que les équipes ont renforcé le respect des normes. Deuxièmement, nous mettons en place des *mécanismes* qui effectuent des vérifications automatisées pour s'assurer 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 est soutenue par les [principes de leadership d'Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp) et établit une culture sur l'ensemble des rôles qui *procèdent à rebours* en partant 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 permettons 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 principaux voient l'émergence de nouvelles bonnes pratiques, ils collaborent afin de s'assurer 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 d'essai à l'échelle de la production et à la demande, exécuter les tests, puis désactiver les ressources. 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 pour faciliter 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.
+ **Permettre 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.