AWS Well-Architected Framework : les 6 piliers appliqués en 2025

Qu'est-ce que le Well-Architected Framework ?

Créé par AWS en 2015, le Well-Architected Framework (WAF) est un ensemble de bonnes pratiques structuré pour concevoir des architectures cloud sécurisées, performantes, résilientes, efficientes et durables. À sa création, il reposait sur 5 piliers ; en 2021, AWS a ajouté un sixième : la Durabilité (Sustainability), reflétant la prise de conscience croissante des enjeux environnementaux du numérique.

Depuis son lancement, plus de 400 000 Well-Architected Reviews (WARs) ont été conduites dans le monde, identifiant des milliers de risques architecturaux avant qu'ils ne deviennent des incidents de production. Le WAF est aujourd'hui la référence de l'industrie pour évaluer la maturité d'une architecture cloud.

Pilier 1 — Excellence Opérationnelle

L'excellence opérationnelle consiste à exécuter et surveiller les systèmes pour livrer de la valeur métier, et à améliorer continuellement les processus et procédures. En 2025, cela se traduit par quatre pratiques fondamentales.

Infrastructure as Code obligatoire

Toute ressource cloud doit être provisionnée via IaC (Terraform, AWS CDK, CloudFormation). Pas d'exception : les ressources créées manuellement via la console sont une source de dérive de configuration et un obstacle aux revues de sécurité. Le code IaC vit dans Git, est revu via des Pull Requests et déclenche des pipelines CI/CD.

Runbooks pour chaque type d'incident

Un runbook est une procédure étape par étape pour répondre à un type d'incident spécifique (indisponibilité de la base de données, saturation du disque, pic de trafic inattendu). Ils sont stockés dans un wiki ou un système de documentation versionné, et testés régulièrement lors de Game Days.

Post-mortems sans blâme (Blameless Post-Mortems)

Après chaque incident majeur (SEV1 ou SEV2), un post-mortem est rédigé dans les 48 heures. L'objectif n'est pas de trouver un coupable mais d'identifier les causes profondes systémiques et de définir des actions correctives. Cette culture du blameless post-mortem, popularisée par Google SRE, est l'un des facteurs les plus différenciants entre les organisations tech matures et les autres.

Mesurer avec les métriques DORA

Les métriques DORA (DevOps Research and Assessment) sont les indicateurs de référence pour mesurer la performance des équipes d'ingénierie :

• Deployment Frequency : fréquence des déploiements en production (objectif élite : plusieurs fois par jour)
• Lead Time for Changes : temps entre un commit et son déploiement en production (objectif élite : moins d'une heure)
• Mean Time to Recovery (MTTR) : temps moyen de rétablissement après un incident (objectif élite : moins d'une heure)
• Change Failure Rate : pourcentage de déploiements qui causent un incident (objectif élite : moins de 5 %)

Pilier 2 — Sécurité

La sécurité dans le cloud est une responsabilité partagée : AWS sécurise l'infrastructure physique, vous sécurisez ce que vous déployez dessus. Ce pilier couvre l'identité, la détection, la protection des données et la réponse aux incidents.

IAM : principe du moindre privilège

Aucune politique IAM en production ne doit comporter de wildcard * sur les actions ou les ressources. Chaque rôle IAM est taillé au plus juste pour les actions que le service doit effectuer, et rien de plus. Les accès humains utilisent IAM Identity Center (SSO) avec MFA obligatoire.

GuardDuty + Security Hub : détection automatisée

# Activer GuardDuty et Security Hub via Terraform
resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs { enable = true }
    kubernetes { audit_logs { enable = true } }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes { enable = true }
      }
    }
  }
}

resource "aws_securityhub_account" "main" {}

resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"
  depends_on    = [aws_securityhub_account.main]
}

resource "aws_securityhub_standards_subscription" "aws_foundational" {
  standards_arn = "arn:aws:securityhub:eu-west-1::standards/aws-foundational-security-best-practices/v/1.0.0"
  depends_on    = [aws_securityhub_account.main]
}

CloudTrail, Config et VPC Flow Logs

CloudTrail doit être activé dans toutes les régions (pas uniquement la région principale) et les logs doivent être envoyés vers un bucket S3 dans un compte Log Archive dédié — inaccessible aux équipes applicatives. AWS Config enregistre l'historique de toutes les modifications de configuration des ressources et permet de détecter les dérives. Les VPC Flow Logs capturent tous les flux réseau et sont indispensables pour les investigations de sécurité.

Pilier 3 — Fiabilité

La fiabilité consiste à s'assurer qu'un système peut se remettre des perturbations et acquérir des ressources dynamiquement pour répondre à la demande. Les architectures fiables sont conçues pour échouer gracieusement.

Multi-AZ et Multi-Région

Toute application de production critique doit être déployée sur au moins 2 zones de disponibilité. Pour les applications avec un RTO proche de zéro (services financiers, e-commerce), une architecture multi-région active-active ou active-passive est nécessaire.

Circuit Breaker avec API Gateway

# Circuit Breaker : timeout strict sur les intégrations API Gateway
resource "aws_api_gateway_integration" "backend" {
  rest_api_id             = aws_api_gateway_rest_api.main.id
  resource_id             = aws_api_gateway_resource.proxy.id
  http_method             = "ANY"
  type                    = "HTTP_PROXY"
  integration_http_method = "ANY"
  uri                     = "http://${aws_lb.backend.dns_name}/{proxy}"

  # Timeout strict : évite que les lenteurs du backend propagent
  timeout_milliseconds = 3000
}

# AWS Backup pour RTO/RPO maîtrisés
resource "aws_backup_plan" "daily" {
  name = "daily-backup-plan"

  rule {
    rule_name         = "daily-backup"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 1 * * ? *)"  # 1h du matin chaque jour

    lifecycle {
      delete_after = 30  # Rétention 30 jours
    }
  }
}

Chaos Engineering avec AWS Fault Injection Service

AWS Fault Injection Service (FIS) permet d'injecter des pannes contrôlées dans votre infrastructure (arrêt d'instances EC2, latence réseau artificielle, erreurs d'API) pour tester la résilience de vos systèmes. Planifiez des Game Days mensuels pour valider que vos runbooks fonctionnent dans les situations réelles.

Pilier 4 — Performance Efficiente

Ce pilier concerne la capacité à utiliser les ressources informatiques efficacement pour satisfaire les exigences du système, et à maintenir cette efficacité au fur et à mesure de l'évolution de la demande et des technologies.

Le bon service pour la bonne tâche

• AWS Lambda : traitement événementiel, fonctions courtes (< 15 min), pas de gestion de serveur
• Amazon ECS Fargate : services long-running, conteneurs, sans gestion d'EC2
• Amazon EC2 Graviton : workloads CPU-intensifs, bases de données self-managed
• AWS Batch : jobs batch à grande échelle, traitement différé
• Amazon SageMaker : entraînement et inférence de modèles ML

Cache multi-couches

Une architecture performante utilise plusieurs niveaux de cache pour minimiser les appels aux services coûteux :

• CloudFront : cache edge pour les assets statiques et les API publiques — réduit la latence à < 10 ms pour les utilisateurs proches d'un PoP
• ElastiCache (Redis) : cache de sessions, résultats de requêtes fréquentes, compteurs temps-réel
• DAX (DynamoDB Accelerator) : cache in-memory pour DynamoDB, réduit les latences de millisecondes à microsecondes

Pilier 5 — Optimisation des Coûts

L'optimisation des coûts n'est pas une activité ponctuelle mais un processus continu. Ce pilier couvre la visibilité, la gouvernance et l'optimisation active des dépenses cloud.

Stratégie de tagging obligatoire

# Politique de tagging obligatoire via AWS Config Rule
resource "aws_config_config_rule" "required_tags" {
  name = "required-tags"

  source {
    owner             = "AWS"
    source_identifier = "REQUIRED_TAGS"
  }

  input_parameters = jsonencode({
    tag1Key   = "Environment"
    tag1Value = "production,staging,development"
    tag2Key   = "Team"
    tag3Key   = "CostCenter"
    tag4Key   = "Application"
  })
}

AWS Budgets : alertes à 80 % et 100 %

resource "aws_budgets_budget" "monthly" {
  name         = "monthly-budget"
  budget_type  = "COST"
  limit_amount = "5000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["finops@company.com"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_email_addresses = ["finops@company.com", "cto@company.com"]
  }
}

Stratégie Savings Plans + Spot

Pour les workloads prévisibles (trafic de base d'une application web), engagez-vous sur des Compute Savings Plans (1 an : -30 %, 3 ans : -50 %). Pour les workloads tolérantes aux interruptions (jobs ML, rendu vidéo, tests d'intégration), utilisez les Spot Instances avec une stratégie multi-type multi-AZ pour maximiser la disponibilité.

Pilier 6 — Durabilité (Sustainability)

Introduit en 2021, ce pilier reflète la responsabilité environnementale des architectes cloud. Réduire l'empreinte carbone d'une architecture cloud est à la fois une obligation croissante (CSRD) et une opportunité d'optimisation des coûts.

Régions à faible empreinte carbone

Priorisez eu-north-1 (Stockholm, ~12 gCO2eq/kWh via hydraulique) et eu-west-1 (Irlande, ~240 gCO2eq/kWh via éolien) pour vos workloads batch et archives. Évitez us-east-1 (~415 gCO2eq/kWh) pour les workloads non sensibles à la localisation.

Graviton3 et Customer Carbon Footprint Tool

Les instances Graviton3 offrent 60 % de meilleures performances par watt que les instances x86 équivalentes. Combinez cette migration avec l'AWS Customer Carbon Footprint Tool pour mesurer votre progression et alimenter votre reporting CSRD.

Comment réaliser une Well-Architected Review (WAR) ?

Une WAR est une revue structurée de votre architecture sur la base des questions du Well-Architected Tool. Elle se déroule typiquement en 2 jours avec un partenaire AWS certifié :

• Jour 1 : ateliers par pilier avec les équipes techniques — identification des risques (High Risk Issues — HRI) et des améliorations (Medium Risk Issues — MRI)
• Jour 2 : priorisation des risques, construction du plan de remédiation, estimation de l'effort et des économies potentielles

Le livrable est un rapport détaillé avec l'ensemble des risques identifiés, priorisés et associés à des recommandations concrètes. Les entreprises qui suivent les recommandations d'une WAR économisent en moyenne 30 % sur leurs coûts AWS dans les 6 mois suivants.

Move2Cloud est partenaire AWS et propose des WARs gratuites pour les architectures éligibles. Contactez-nous pour évaluer votre architecture.

Conclusion

Le Well-Architected Framework n'est pas un état à atteindre une fois — c'est un processus d'amélioration continue. Commencez par le pilier Sécurité (risque le plus immédiat), puis Fiabilité, puis les quatre autres selon vos priorités. Planifiez une WAR annuelle pour adapter votre architecture à l'évolution de vos besoins et des services AWS. En 2025, le pilier Durabilité s'impose comme priorité réglementaire pour toutes les entreprises soumises à la CSRD.