À la fin de ce tutoriel, vous saurez expliquer le AWS Well-Architected Framework, décrire les 6 piliers, relier chaque pilier à des checklists de labs DEH en
ca-central-1, et lancer une revue lecture seule avec le Well-Architected Tool — sans créer de ressources coûteuses.Niveau : Intermédiaire · Temps estimé : 45–60 min · Versions testées : AWS Management Console (2026), AWS CLI v2, Well-Architected Tool · Dernière vérification : 2026-09-11 · Region :
ca-central-1Slug :
aws-well-architected-framework· Série : AWS Solutions Architect · Mot-clé SEO : aws well architected framework← Précédent : AWS Cloud Computing · → Suivant : IAM : users, groupes, rôles, politiques · Hub : Démarrer avec AWS
Prérequis
- Compte AWS de lab (Free Tier) et profil CLI
lab— voir Démarrer avec AWS - Bases cloud (IaaS / Regions / AZ) — AWS Cloud Computing
- Notions IAM, VPC et EC2 utiles mais pas obligatoires pour la lecture
Coût estimé : 0 € — revue console / CLI en lecture seule ; le Well-Architected Tool ne facture pas la création d’une workload de documentation. Ne lancez pas d’EC2, RDS ou NAT Gateway « pour tester ».
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
Ce que nous allons construire
AWS Well-Architected Framework (2026)
├── Définition + pourquoi (risques, trade-offs, SAA)
├── 6 piliers → checklists labs DEH
│ ├── Operational Excellence
│ ├── Security
│ ├── Reliability
│ ├── Performance Efficiency
│ ├── Cost Optimization
│ └── Sustainability
├── Well-Architected Tool (console, lecture)
├── Exemple charge 3-tier (ca-central-1)
└── Lien SAA-C03 + quiz
(Schéma — alt : « Six piliers AWS Well-Architected reliés aux labs VPC, IAM, RDS, WAF, Cost Explorer en ca-central-1 ».)
Qu’est-ce que le AWS Well-Architected Framework ?
Le AWS Well-Architected Framework (souvent abrégé WA) est un ensemble de principes de conception, de questions et de bonnes pratiques pour évaluer une architecture cloud. Il ne remplace pas un design détaillé : il fournit un langage commun pour discuter des risques (sécurité, disponibilité, coût, ops) avant qu’ils n’arrivent en production.
AWS publie le framework, des lenses (perspectives métier / techno) et le Well-Architected Tool dans la console. Pour la série DEH, on traduit chaque pilier en actions concrètes de lab déjà couvertes par d’autres tutoriels — pas en théorie floue.
Pourquoi s’en servir en lab ?
- Structurer une revue d’architecture (même pour un projet perso Free Tier)
- Préparer SAA-C03 : le vocabulaire des piliers revient dans les scénarios
- Éviter les anti-patterns coûteux (single-AZ « pour aller vite », SG
0.0.0.0/0partout, snapshots oubliés) - Prioriser : High Risk Issues (HRI) d’abord, nice-to-have ensuite
Les 6 piliers
Les six piliers sont égaux en importance ; le poids relatif dépend du contexte (startup vs banque). Voici l’idée, des questions clés, et une checklist lab DEH.
1. Operational Excellence (excellence opérationnelle)
Idée : faire tourner et améliorer les systèmes en production — IaC, runbooks, observabilité, post-mortems sans blâme.
Questions clés : Comment provisionnez-vous ? Comment détectez-vous un incident ? Comment apprenez-vous des échecs ?
Checklist lab DEH :
- IaC (CloudFormation / Terraform) plutôt que clics orphelins — CloudFormation
- Alarmes CloudWatch + accès via SSM (pas de SSH ouvert) — CloudWatch · EC2 + SSM
2. Security (sécurité)
Idée : protéger données, systèmes et actifs ; défense en profondeur ; moindre privilège.
Questions clés : Qui peut faire quoi ? Qu’est-ce qui est chiffré ? Comment isolez-vous le réseau ?
Checklist lab DEH :
- IAM least privilege + MFA — IAM
- VPC multi-tier, SG / NACL — VPC · SG/NACL
- S3 non public + WAF devant ALB/CloudFront — S3 sécurité · WAF
3. Reliability (fiabilité)
Idée : charge de travail qui récupère des pannes et répond à la demande ; fondations, changements contrôlés, récupération.
Questions clés : Multi-AZ ? Backups testés ? Quotas et limites connus ?
Checklist lab DEH :
4. Performance Efficiency (efficacité des performances)
Idée : utiliser les ressources de calcul de façon efficace ; sélection de types, évolutivité, monitoring.
Questions clés : Le bon type d’instance / service managé ? Caching ? Mesurez-vous la latence ?
Checklist lab DEH :
- Familles EC2 / Spot adaptés — EC2 types / Spot
- ALB + ASG ; choix RDS vs DynamoDB — ALB · DynamoDB
- CDN pour statique — CloudFront + S3
5. Cost Optimization (optimisation des coûts)
Idée : éviter ou éliminer les coûts inutiles ; mesurer, attribuer, dimensionner, tarification adaptée.
Questions clés : Qui paie quoi (tags) ? Droits Free Tier / Budgets ? Ressources idle ?
Checklist lab DEH :
- Budgets + Cost Explorer filtrés
ca-central-1/ tags — Démarrer avec AWS - Couper EC2, NAT, ALB après lab ; lifecycle S3 ; Spot/Lambda si pertinent — S3 lifecycle · Spot
6. Sustainability (durabilité)
Idée : minimiser l’impact environnemental ; efficacité énergétique, utilisation maximale, régions et architectures sobres.
Questions clés : Sur-provisionnement ? Région proche des utilisateurs ? Stockage froid pour archives ?
Checklist lab DEH :
- Right-sizing + ASG ; S3 froid / Glacier — S3 classes
- Services managés plutôt que serveurs idle 24/7 ; une Region lab (
ca-central-1)
| Pilier | Focus | Lab DEH typique |
|---|---|---|
| Operational Excellence | Ops, IaC, observabilité | CloudWatch, SSM, CloudFormation |
| Security | Identité, réseau, data | IAM, VPC, S3, WAF |
| Reliability | Multi-AZ, backup, scale | ALB, ASG, RDS |
| Performance Efficiency | Choix techno, mesure | EC2 types, DynamoDB, CloudFront |
| Cost Optimization | Mesure, idle, tarifs | Budgets, Cost Explorer, lifecycle |
| Sustainability | Efficacité, sobriété | Right-sizing, S3 froid, serverless |
Outil Well-Architected Tool (console)
Le AWS Well-Architected Tool (service console, gratuit pour documenter une workload) guide une revue par questions. En lab DEH : lecture / documentation seulement.
Procédure minimale :
- Console → Region
ca-central-1→ AWS Well-Architected Tool - Define workload :
deh-lab-3tier, env Pre-production - Framework AWS Well-Architected (lens optionnelle plus tard)
- Parcourir un pilier (ex. Security) ; noter High / Medium risk
- Lire l’Improvement plan pour prioriser les labs suivants
- Supprimer la workload documentaire si besoin (ne détruit pas EC2/RDS)
Pas d’environnement « production » Free Tier ; ne partagez pas la workload hors lab.
Exemple de charge de travail : 3-tier web en ca-central-1
Scénario DEH : site web public, API sur EC2 (Auto Scaling), base RDS, assets sur S3, entrée via ALB (+ WAF optionnel).
| Couche | Services | Piliers surtout couverts |
|---|---|---|
| Edge / entrée | ALB, WAF, (CloudFront) | Security, Reliability, Performance |
| Compute | Launch Template, ASG, EC2 + SSM | Ops, Reliability, Performance, Cost |
| Données | RDS Multi-AZ, snapshots ; S3 versionné | Reliability, Security, Sustainability |
| Observabilité | CloudWatch alarms + logs | Operational Excellence |
| Identité réseau | IAM roles, SG, subnets privés DB | Security |
| Coût | Tags Project=deh-wa, Budgets, Cost Explorer |
Cost Optimization |
Parcours labs : VPC → EC2/SSM → ALB → ASG → RDS → S3 → CloudWatch → WAF.
Lien SAA-C03 / Exam Content Outline
L’examen SAA-C03 n’a pas de domaine nommé « Well-Architected », mais ses quatre domaines (Secure / Resilient / High-Performing / Cost-Optimized) recoupent Security, Reliability, Performance Efficiency et Cost Optimization. Operational Excellence et Sustainability reviennent dans les scénarios best practice.
En révision : traitez les questions WA comme check-list mentale ; reliez chaque réponse à un ou deux piliers (ex. Multi-AZ RDS → Reliability) ; pratiquez via le quiz / FAQ SA. Consultez l’Exam Content Outline officiel pour les pondérations à jour.
Mini-lab lecture seule (CLI + console)
Objectif : valider identité / Region et lister les workloads WA existantes sans créer de compute.
export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity
aws wellarchitected list-workloads
--region ca-central-1
--query 'WorkloadSummaries[].{Name:WorkloadName,Id:WorkloadId,Risk:RiskCounts}'
--output table
Attendu : ARN IAM (pas root). Liste vide ou quelques workloads de doc — normal sur un compte lab neuf. Si AccessDenied, ajoutez une politique lecture wellarchitected:List* / Get* sur le rôle lab, ou restez sur la console WA Tool en lecture.
Erreurs fréquentes
| Erreur | Pourquoi ça fait mal | Correction |
|---|---|---|
| Traiter WA comme un audit one-shot | Risques à chaque feature | Revue légère à chaque jalon |
| Coût avant sécu | Breach + forensics | Security / Reliability d’abord |
| Single-AZ « pour Free Tier » | Downtime AZ | Designer multi-AZ ; single-AZ = dette notée |
| Créer des ressources pour le Tool | Facture | Workload documentaire seulement |
| Confondre piliers et services | Mauvaise réponse SAA | Un service couvre souvent plusieurs piliers |
Quiz (5 questions)
1. Combien de piliers compte le AWS Well-Architected Framework (2026) ?
– A. 4
– B. 5
– C. 6
2. VPC multi-AZ + RDS Multi-AZ + ALB illustrent surtout :
– A. Uniquement Cost Optimization
– B. Reliability (et souvent Performance / Security)
– C. Sustainability seule
3. Le Well-Architected Tool en lab DEH sert surtout à :
– A. Provisionner automatiquement un VPC facturable
– B. Documenter une workload et prioriser des risques (lecture / amélioration)
– C. Remplacer IAM
4. WAF devant un ALB + buckets S3 non publics relèvent principalement du pilier :
– A. Security
– B. Sustainability uniquement
– C. Cost Optimization uniquement
5. Cost Explorer + tags + arrêt des NAT après lab relèvent de :
– A. Operational Excellence seulement
– B. Cost Optimization (souvent lié à Sustainability)
– C. Reliability seule
Réponses : 1‑C · 2‑B · 3‑B · 4‑A · 5‑B
Pour aller plus loin
- AWS Well-Architected
- Well-Architected Framework whitepaper
- AWS Well-Architected Tool User Guide
- SAA-C03 Exam Guide / Content Outline
Maillage série AWS (P1)
| ← Précédent | AWS Cloud Computing |
| → Suivant | IAM : users, groupes, rôles, politiques |
| Aussi | Démarrer avec AWS · VPC · EC2 + SSM · ALB · ASG · RDS · S3 · CloudWatch · WAF · Quiz SA |
Retour parcours AWS — hub de la série et leçons sœurs.