AWS Well-Architected Framework : piliers, revue et limites

L’AWS (Amazon Web Services) Well-Architected Framework est un référentiel de bonnes pratiques d’architecture publié par AWS, organisé en six piliers et outillé par une revue par questionnaire. Ce n’est ni une norme, ni une certification, ni une garantie : c’est une auto-évaluation structurée dont la valeur tient entièrement à ce qu’on fait des risques qu’elle révèle. Cette page dit ce que le cadre demande, ce qu’il coûte à tenir, ce qu’il change pour la sécurité et où s’arrête sa portée.

→ Lire l’explication complète de la marmotte

Six piliers du Well-Architected Framework : ce que le cadre demande vraiment

Le cadre compte six piliers depuis l’ajout du pilier durabilité fin 2021 ; aucun n’a été ajouté ni retiré depuis. Chaque pilier se décompose en principes de conception, puis en questions numérotées (SEC 1, REL 9, COST 3…), chacune assortie de bonnes pratiques identifiées (par exemple SEC01-BP01). AWS publie des révisions datées du document : les questions évoluent, les piliers restent.

Pilier	Ce que les questions vérifient en pratique
Excellence opérationnelle	Déploiement par code, observabilité, procédures d’exploitation, post-mortems qui produisent des changements
Sécurité	Séparation des comptes, identités humaines et machines, détection, protection réseau et calcul, protection des données, réponse à incident, sécurité applicative
Fiabilité	Quotas, isolation des pannes, sauvegardes, objectifs RTO (Recovery Time Objective) et RPO (Recovery Point Objective) testés, reprise
Efficacité des performances	Choix des ressources fondé sur des mesures, revue périodique des types d’instances et services
Optimisation des coûts	Attribution des coûts par étiquetage, dimensionnement, modèles d’achat, suppression de l’inutilisé
Durabilité	Réduction des ressources consommées par unité de travail utile, choix de région, cycle de vie des données

Le point à retenir : une question Well-Architected ne demande pas « le service X est-il activé ? », elle demande « comment la charge de travail traite-t-elle tel risque ? ». Les cases à cocher décrivent des pratiques, et c’est leur absence qui génère un risque. Le cadre est donc un questionnaire d’architecture, pas une liste de contrôle de configuration. Ceux qui le remplissent en lisant la console à voix haute obtiennent un score, pas une architecture.

Deux pièges récurrents. Le premier : traiter les six piliers à égalité. Ils ne le sont pas pour une charge donnée ; une API de paiement et un traitement batch interne n’ont ni les mêmes risques ni le même budget d’attention, et le cadre lui-même assume l’arbitrage entre piliers (la fiabilité multi-région coûte, la durabilité pousse à consolider). Le second : confondre l’unité d’évaluation. La revue porte sur une charge de travail (workload), c’est-à-dire un ensemble de ressources et de code qui délivre une valeur métier, pas sur un compte, ni sur « le cloud de l’entreprise ». Une revue sans périmètre délimité produit des réponses moyennes qui ne correspondent à aucun système réel.

Revue Well-Architected : mécanisme, outil, lentilles et risques HRI

La revue s’appuie sur l’AWS Well-Architected Tool, gratuit dans la console et pilotable par API (Application Programming Interface). On y déclare une charge de travail, on répond aux questions pilier par pilier, et l’outil calcule pour chaque question un niveau de risque : HRI (High Risk Issue), MRI (Medium Risk Issue) ou absence de risque. Les lentilles (lenses) ajoutent des questions propres à un contexte : serverless, SaaS (Software as a Service), services financiers, IA générative, etc. Les lentilles personnalisées, décrites en JSON (JavaScript Object Notation), permettent d’ajouter ses propres questions et règles de calcul de risque. Les jalons (milestones) figent l’état d’une revue à une date, ce qui permet de mesurer une progression plutôt que de réécrire l’historique.

Le cycle qui tient en production est le suivant ; ce qu’il faut y lire, c’est que la valeur se crée après le calcul des risques, pas pendant le questionnaire.

La recommandation est nette : une revue par charge de travail critique, à la conception puis à chaque changement d’architecture significatif, avec les HRI versés dans le backlog comme n’importe quel défaut. Une revue annuelle de toutes les charges, en atelier de deux jours, produit surtout un fichier PDF (Portable Document Format) et un sentiment du devoir accompli ; le sentiment, lui, ne figure dans aucun pilier. Les HRI non traités relèvent de la dette de sécurité et doivent y être comptés comme tels.

Un détail qui casse en silence : la version de la lentille est attachée à la revue. Quand AWS publie une révision du cadre, une revue existante reste sur l’ancienne version jusqu’à une mise à niveau explicite (opération UpgradeLensReview dans l’API). Deux revues de la même charge, sur deux versions, ne se comparent pas question par question.

Pilier sécurité et responsabilité partagée : ce que la revue change pour l’architecture

Le pilier sécurité est le plus prescriptif du cadre, et le plus orienté vers les services AWS. Il pousse des choix d’architecture précis : isolation des charges par comptes distincts sous AWS Organizations, utilisateur racine verrouillé, identités humaines fédérées plutôt qu’utilisateurs IAM (Identity and Access Management) à clés longues, identités machines par rôles à crédentiels temporaires, moindre privilège encadré par des SCP (Service Control Policies), journalisation centralisée, chiffrement au repos via AWS KMS (Key Management Service), procédures de réponse à incident répétées.

Tout cela s’inscrit dans le modèle de responsabilité partagée d’AWS : AWS répond de la sécurité du cloud (matériel, hyperviseur, centres de données), le client répond de la sécurité dans le cloud (identités, configuration, données, code). Le pilier sécurité ne couvre que la seconde moitié, ce qui est logique, et ne dit rien de la première, ce qui l’est aussi : la revue ne vérifie pas AWS, elle vérifie ce que le client fait chez AWS. La partie fournisseur s’évalue autrement, par ses attestations et par l’analyse décrite dans la page sur la gestion des risques tiers. La partie identités renvoie au fond technique de la section identités.

Ce que le pilier change concrètement : il impose de répondre à des questions que beaucoup d’architectures repoussent, comme « comment détecter l’usage d’un crédentiel compromis ? » ou « qui peut lire les clés de chiffrement des sauvegardes ? ». Ce qu’il ne change pas : la profondeur. La question sur la gestion des clés vérifie qu’une démarche existe, pas que la politique de clé KMS empêche réellement l’administrateur du compte de déchiffrer. Une architecture peut cocher toutes les cases du pilier et laisser un rôle d’intégration continue avec AdministratorAccess, parce qu’aucune case ne lit les politiques IAM.

Ce que le Well-Architected Framework ne garantit pas

Le cadre est déclaratif. L’outil calcule un risque à partir de réponses saisies par des humains, sans aucune vérification de l’environnement réel, sauf l’intégration optionnelle avec AWS Trusted Advisor, dont l’ensemble complet des contrôles exige un plan de support payant (Business ou supérieur). Une revue honnête et une revue complaisante produisent le même format de rapport ; seule la première produit de l’information.

Il ne garantit donc pas :

la conformité : aucune exigence de NIS2, de DORA (Digital Operational Resilience Act) ou de l’ISO/IEC 27001 n’est satisfaite par une revue Well-Architected. Elle peut alimenter un dossier, à condition d’y joindre des preuves techniques ; ce qu’un auditeur vérifie réellement est détaillé dans la page sur la preuve de conformité, et les obligations elles-mêmes dans les pages NIS2 et DORA ;
l’analyse de risque : le cadre pose des questions génériques par pilier, il ne part ni des valeurs métier ni des scénarios d’attaque. Il complète une méthode comme EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité, Risk Manager), il ne la remplace pas ;
la gouvernance : il ne dit rien des droits de décision, des budgets ni de l’arbitrage entre programmes ; c’est le terrain de COBIT 2019 (Control Objectives for Information and Related Technologies) et, côté architecture d’entreprise, de TOGAF (The Open Group Architecture Framework) ;
l’exploitation des services : le pilier excellence opérationnelle évoque les procédures, il ne décrit pas une gestion des incidents, des changements et des problèmes au sens d’ITIL (Information Technology Infrastructure Library) ;
la neutralité : les bonnes pratiques recommandent, sans surprise, des services AWS. Le cadre d’un fournisseur qui conclurait « partez ailleurs » reste à écrire.

La vérification continue doit venir d’ailleurs : AWS Config et ses packs de conformité, les standards de contrôles d’AWS Security Hub, des tests de restauration chronométrés, des tests d’intrusion. La revue pose la question, ces outils produisent la réponse mesurée.

Surface d’attaque d’un programme Well-Architected

Une revue Well-Architected bien menée est, par construction, la liste à jour des faiblesses d’une charge de travail, classées par gravité, avec commentaires. Ce document mérite la protection qu’on accorderait à un rapport de test d’intrusion, ce qu’il reçoit rarement.

Attaque ou dérive	Mécanisme	Contre-mesure
Reconnaissance par lecture des revues	Un compte doté de droits de lecture larges lit les HRI et les notes via `wellarchitected:Get` et `List`	Restreindre les actions `wellarchitected:*` par politique IAM et SCP, vérifier ce que contiennent les politiques de lecture génériques attribuées
Fuite par partage	Les charges de travail et lentilles personnalisées se partagent avec d’autres comptes ou utilisateurs	Limiter le partage aux comptes de l’organisation, auditer les invitations de partage
Fuite par export	Les rapports PDF circulent par messagerie et finissent dans des espaces partagés	Classifier les rapports, les stocker avec les livrables d’audit
Falsification de l’état	Une réponse modifiée fait disparaître un HRI sans correction	Journaliser les appels API Well-Architected dans AWS CloudTrail, alerter sur `UpdateAnswer` hors période de revue, comparer aux jalons
Fausse assurance	Score vert sans preuve technique	Exiger pour chaque HRI clos une preuve vérifiable (règle Config, test, ticket)

Vingt ans de métier apprennent qu’un registre de vulnérabilités protégé par « personne ne sait qu’il existe » finit toujours par être découvert, et rarement par la personne qu’on espérait.

Transposer le cadre hors AWS : ce qui voyage et ce qui reste propre à AWS

Les six piliers et leurs principes de conception sont indépendants du fournisseur : séparer les environnements, automatiser les déploiements, tester la reprise, attribuer les coûts, mesurer avant de dimensionner. Ils s’appliquent tels quels à une infrastructure sur site ou chez un autre fournisseur. Microsoft publie d’ailleurs son propre Azure Well-Architected Framework, à cinq piliers (sans durabilité comme pilier distinct), et Google Cloud un cadre d’architecture équivalent ; les recouvrements sont massifs. À distinguer du Microsoft Cloud Adoption Framework, qui traite l’adoption du cloud à l’échelle de l’organisation (stratégie, zones d’atterrissage, gouvernance) et non la revue d’une charge de travail.

Ce qui reste propre à AWS : la formulation des bonnes pratiques (nommées par service), l’outil, les lentilles du catalogue, l’intégration avec Trusted Advisor et AWS Organizations, et la frontière de responsabilité partagée telle qu’AWS la trace.

Le choix de méthode dépend d’une question : la charge de travail tourne-t-elle majoritairement sur AWS ? Si oui, utiliser la lentille standard et y ajouter une lentille personnalisée pour les exigences internes. Si l’environnement est mixte, garder les six piliers comme structure commune et réécrire les questions dans une lentille personnalisée neutre ; l’outil accepte des charges hors AWS (paramètre de régions non AWS), et l’on évite ainsi de maintenir trois questionnaires de trois fournisseurs qui posent la même question avec trois vocabulaires.

Prérequis et coût d’exploitation d’une revue Well-Architected

Avant la première revue, il faut :

un périmètre par charge de travail (ressources, comptes, régions, dépendances) et un propriétaire nommé qui accepte les risques résiduels ;
un socle multi-comptes avec journalisation centralisée : sans lui, les réponses aux questions de détection sont des intentions ;
un étiquetage cohérent des ressources, condition des questions de coût et de l’intégration Trusted Advisor ;
des droits IAM dédiés à l’outil, séparés entre rédacteurs de la revue et lecteurs ;
une lentille personnalisée maintenue, si des exigences internes ou réglementaires doivent apparaître dans la revue.

Le coût réel n’est pas l’outil, gratuit, mais le temps : une revue complète des six piliers mobilise l’équipe produit et un architecte sur une durée qui se compte en demi-journées, et la correction des HRI se paie en sprints. Le calcul de rentabilité relève des méthodes décrites dans la page sur le coût total de possession d’un contrôle. L’exploitation courante tient en quatre règles : un jalon après chaque lot de corrections, une mise à niveau de lentille à chaque révision du cadre, une revue partielle (pilier sécurité et fiabilité) à chaque changement d’architecture, et une sauvegarde des revues par export API, car une charge de travail supprimée dans l’outil emporte son historique.

Exemple de revue Well-Architected pilotée par la CLI AWS

Les commandes suivantes, avec la CLI (Command Line Interface) AWS, créent une charge de travail, extraient les HRI du pilier sécurité et figent un jalon. Les identifiants sont fictifs.

# 1. Déclarer la charge de travail (lentille standard "wellarchitected")
aws wellarchitected create-workload \
  --workload-name "api-paiement-prod" \
  --description "API de paiement, comptes de production" \
  --environment PRODUCTION \
  --aws-regions eu-west-3 \
  --review-owner "equipe-plateforme" \
  --lenses wellarchitected
# Renvoie un WorkloadId, par exemple 0123456789abcdef0123456789abcdef

# 2. Après saisie des réponses : lister les questions sécurité en risque élevé
aws wellarchitected list-answers \
  --workload-id 0123456789abcdef0123456789abcdef \
  --lens-alias wellarchitected \
  --pillar-id security \
  --query "AnswerSummaries[?Risk=='HIGH'].[QuestionId,QuestionTitle]" \
  --output table

# 3. Compter les risques par niveau sur toute la lentille
aws wellarchitected get-lens-review \
  --workload-id 0123456789abcdef0123456789abcdef \
  --lens-alias wellarchitected \
  --query "LensReview.RiskCounts"

# 4. Figer l'état courant avant le lot de corrections suivant
aws wellarchitected create-milestone \
  --workload-id 0123456789abcdef0123456789abcdef \
  --milestone-name "post-correction-identites"

La sortie de l’étape 2 sert de source au backlog : un ticket par QuestionId, avec propriétaire et échéance. L’étape 3 fournit l’indicateur de suivi (nombre de HRI ouverts), à condition de ne pas en faire un objectif : un indicateur qui décroît parce que les réponses changent, et non l’architecture, illustre exactement ce que la page sur les indicateurs de sécurité appelle une façade. Les identifiants de piliers acceptés sont operationalExcellence, security, reliability, performance, costOptimization et sustainability.

Sources

AWS Well-Architected Framework, Amazon Web Services.
AWS Well-Architected Framework, Security Pillar, Amazon Web Services.
Modèle de responsabilité partagée AWS, Amazon Web Services.
ISO/IEC 27001, ISO/IEC.
Directive (UE) 2022/2555 (NIS 2), Union européenne.
Règlement (UE) 2022/2554 (DORA), Union européenne.

🐝 Ce qui arrive si on s’en passe

Sans revue structurée par charge de travail, les risques d’architecture n’ont ni inventaire ni propriétaire : un rôle machine trop permissif, une sauvegarde jamais restaurée ou un compte de production partagé avec le développement restent invisibles tant qu’aucun incident ne les révèle. Personne n’a signé leur acceptation, donc personne n’en répond. L’absence de jalons supprime toute trace datée de l’état de sécurité d’un système, ce qui prive l’analyse après incident de son point de comparaison et laisse l’audit sans historique à examiner. Les arbitrages entre fiabilité, coût et sécurité se font alors par défaut, au fil des urgences, et le premier qui cède est généralement celui qu’aucun tableau de bord ne mesurait.

🦫 Explication de la marmotte 🍫

Quand une entreprise fait tourner ses programmes sur les ordinateurs d’Amazon, loués à distance, Amazon lui propose un questionnaire pour vérifier qu’elle construit correctement. Le questionnaire est rangé en six thèmes : bien faire fonctionner le service au quotidien, le protéger contre les attaques, éviter qu’il tombe en panne, le rendre rapide, ne pas gaspiller d’argent et consommer moins d’énergie. On choisit d’abord un service précis, par exemple le paiement en ligne, puis l’équipe qui le construit répond aux questions une par une. Pour chaque bonne pratique qu’elle n’applique pas, l’outil marque un risque, élevé ou moyen. Ensuite vient le vrai travail : chaque risque élevé devient une tâche avec un responsable et une date, ou bien un chef signe qu’il accepte ce risque en connaissance de cause. Après les corrections, l’équipe met ses réponses à jour et enregistre une photo de l’état du moment, pour pouvoir comparer plus tard. Attention aux limites : l’outil croit ce qu’on lui dit, il ne vérifie pas les ordinateurs. Si l’équipe répond « oui » par paresse, le risque disparaît de l’écran mais reste bien réel. Le questionnaire ne prouve pas non plus qu’on respecte la loi, et il ne vérifie pas le travail d’Amazon, seulement celui de son client. Enfin, cette liste de faiblesses est précieuse pour un attaquant : il faut la garder secrète.

Pages voisines

La citent

AWS Well-Architected Framework : piliers, revue et limites

Elle cite

: les deux pages se citent l’une l’autre.

AWS Well-Architected Framework : piliers, revue et limites

AWS Well-Architected Framework : piliers, revue et limites

Six piliers du Well-Architected Framework : ce que le cadre demande vraiment

Revue Well-Architected : mécanisme, outil, lentilles et risques HRI

Pilier sécurité et responsabilité partagée : ce que la revue change pour l’architecture

Ce que le Well-Architected Framework ne garantit pas

Surface d’attaque d’un programme Well-Architected

Transposer le cadre hors AWS : ce qui voyage et ce qui reste propre à AWS

Prérequis et coût d’exploitation d’une revue Well-Architected

Exemple de revue Well-Architected pilotée par la CLI AWS

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines