aws-well-architected-review

Par github · awesome-copilot

Effectuer une revue AWS Well-Architected Framework du workload IaC et de l'architecture actuels, en générant des findings et des issues GitHub pour les améliorations.

npx skills add https://github.com/github/awesome-copilot --skill aws-well-architected-review

Examen AWS Well-Architected

Ce workflow effectue un examen structuré du framework AWS Well-Architected (WAF) sur les fichiers IaC et l'infrastructure déployée de votre workload. Il identifie les risques sur les 6 piliers du WAF et crée des issues GitHub pour suivre la correction.

Prérequis

  • AWS CLI configurée et authentifiée
  • Fichiers IaC présents dans le repository (Terraform, CloudFormation, CDK ou SAM)
  • Serveur MCP GitHub configuré et authentifié

Étapes du workflow

Étape 1 : Charger la référence du framework Well-Architected

Récupérer les bonnes pratiques actuelles du WAF AWS :

  • https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
  • Lenses spécifiques aux piliers en fonction du type de workload (Serverless, SaaS, etc.)

Étape 2 : Découvrir l'IaC et l'architecture

Analyser le repository à la recherche de fichiers IaC :

  • Terraform : **/*.tf
  • CloudFormation/SAM : **/*.yaml, **/*.json (templates CFn)
  • CDK : lib/**/*.ts, bin/**/*.ts, cdk.json

Identifier les services AWS clés utilisés (compute, données, réseau, sécurité, observabilité) et générer un diagramme d'architecture Mermaid.

Étape 3 : Examen par pilier

Pilier 1 : Excellence opérationnelle

  • [ ] Toute l'infrastructure définie en IaC (aucune modification manuelle via console)
  • [ ] Stratégie de tagging cohérente appliquée sur toutes les ressources
  • [ ] Alarmes CloudWatch définies pour les métriques clés
  • [ ] Pipeline de déploiement automatisé (aucun déploiement manuel)
  • [ ] CloudTrail activé pour l'audit logging
  • [ ] Runbooks ou documentation opérationnelle présents

Pilier 2 : Sécurité

  • [ ] Les rôles IAM utilisent des politiques avec privilèges minimaux (pas d'actions * sans justification)
  • [ ] Pas de credentials en dur dans l'IaC ou le code
  • [ ] Secrets gérés via Secrets Manager ou SSM Parameter Store
  • [ ] Buckets S3 avec accès public bloqué et chiffrement côté serveur activé
  • [ ] Ressources sensibles placées dans des subnets privés
  • [ ] Groupes de sécurité restreignant l'entrée aux ports/CIDR minimums requis
  • [ ] Chiffrement KMS activé pour les datastores sensibles (RDS, EBS, S3, SQS, DynamoDB)
  • [ ] SSL/TLS appliqué sur tous les endpoints (enforceSSL: true)
  • [ ] GuardDuty activé (aws guardduty list-detectors)
  • [ ] AWS WAF configuré sur les API exposées publiquement et les distributions CloudFront
  • [ ] Suppression MFA activée sur les buckets S3 critiques

Pilier 3 : Fiabilité

  • [ ] Déploiements Multi-AZ pour les bases de données de production (RDS Multi-AZ, DynamoDB Global Tables)
  • [ ] Auto Scaling configuré avec politiques appropriées pour EC2/ECS
  • [ ] Versioning et politiques de cycle de vie S3 configurés
  • [ ] Sauvegardes automatiques RDS activées avec période de rétention appropriée
  • [ ] DynamoDB Point-in-Time Recovery (PITR) activé
  • [ ] Dead Letter Queues (DLQ) configurées pour Lambda, SQS, SNS
  • [ ] Vérifications de santé Route 53 configurées pour le basculement DNS
  • [ ] Concurrence réservée Lambda définie pour éviter le throttling par effet de voisinage

Pilier 4 : Efficacité des performances

  • [ ] Types d'instances correctement dimensionnés (mémoire Lambda, type EC2, classe RDS)
  • [ ] Instances Graviton/ARM utilisées lorsque disponibles (Lambda arm64, EC2 Graviton)
  • [ ] Mise en cache implémentée (ElastiCache, DAX, CloudFront, caching API Gateway)
  • [ ] CloudFront utilisé pour la distribution mondiale de contenu statique
  • [ ] Aurora Serverless ou DynamoDB On-Demand pour les patterns de charge variable
  • [ ] Lambda Provisioned Concurrency pour les chemins synchrones critiques en latence

Pilier 5 : Optimisation des coûts

  • [ ] EC2 Reserved Instances ou Savings Plans pour les workloads à charge stable
  • [ ] Politiques de cycle de vie S3 déplaçant les données vers des niveaux de stockage moins chers
  • [ ] Architecture Lambda arm64 adoptée (réduction de 20% des coûts)
  • [ ] VPC Endpoints pour S3/DynamoDB afin d'éviter les frais NAT Gateway
  • [ ] Volumes EBS gp2 migrés vers gp3 (même performance, 20% moins cher)
  • [ ] Environnements de développement/test avec arrêts automatiques planifiés
  • [ ] AWS Budgets et Cost Anomaly Detection configurés
  • [ ] Volumes EBS non attachés et instances EC2 inactives identifiés

Pilier 6 : Durabilité

  • [ ] Instances Graviton/ARM sélectionnées lorsque disponibles
  • [ ] Services serverless/gérés préférés aux EC2 toujours actifs
  • [ ] Politiques de cycle de vie S3 réduisant le stockage de données long terme inutile
  • [ ] Auto Scaling configuré pour éviter le sur-provisionnement
  • [ ] Sélection des régions considérant les engagements AWS en énergie renouvelable

Étape 4 : Classification des risques

Pour chaque finding, classifier :

  • Risque Élevé : Vulnérabilité de sécurité, point de défaillance unique, pas de sauvegarde/récupération
  • Risque Moyen : Fiabilité sous-optimale, inefficacité des coûts, préoccupation de performance
  • Risque Faible : Écart des bonnes pratiques, opportunité d'optimisation mineure

Étape 5 : Confirmation utilisateur

🏗️ Résumé de l'examen AWS Well-Architected

📊 Résultats de l'examen :
• Fichiers IaC analysés : X
• Services AWS identifiés : Y
• Nombre total de findings : Z
  • Risque élevé : A (action immédiate requise)
  • Risque moyen : B (à traiter bientôt)
  • Risque faible : C (sympa à avoir)

🔴 Top findings à risque élevé :
1. [Pilier] : [Finding] — [Pourquoi c'est important]
2. [Pilier] : [Finding] — [Pourquoi c'est important]

💡 Cela créera Z issues GitHub individuelles + 1 issue EPIC.

❓ Procéder à la création des issues GitHub ? (o/n)

Étape 6 : Créer les issues individuelles des findings

Étiqueter avec "well-architected" et le nom du pilier (p. ex. "security", "reliability").

Titre : [WAF-<PILIER>] [Finding bref] — [Niveau de risque]

Corps :

## 🏗️ Finding Well-Architected : [Titre bref]

**Pilier** : [Nom] | **Niveau de risque** : [Élevé/Moyen/Faible] | **Effort** : [Faible/Moyen/Élevé]

### 📋 Description
[Explication claire du finding et pourquoi c'est important]

### 🔧 Correction

**Correction IaC** (préférée) :
```hcl
# Exemple Terraform
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  bucket = aws_s3_bucket.example.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

Fallback AWS CLI :

aws s3api put-bucket-encryption --bucket <name> \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

📚 Référence AWS

  • [Lien WAF Best Practice]
  • [Lien documentation AWS]

✅ Validation

  • [ ] Changement implémenté en IaC et déployé
  • [ ] La règle AWS Config passe (si applicable)
  • [ ] Le finding Security Hub résolu (si applicable)

Question Well-Architected : [Question WAF à laquelle cela correspond]



### Étape 7 : Créer l'issue EPIC de suivi
Étiqueter avec "well-architected" et "epic".

**Titre** : `[EPIC] Examen AWS Well-Architected — X findings sur 6 piliers`

**Corps** : Résumé exécutif avec tableau de répartition par pilier (nombre de findings par pilier et niveau de risque), diagramme d'architecture Mermaid, checklist priorisée liant tous les issues individuelles (Élevé → Moyen → Faible), et critères de succès :
- Tous les findings à risque élevé résolus
- Les findings moyen ont des plans d'atténuation acceptés
- Pas de régression dans les alarmes CloudWatch ou règles Config existantes

## Gestion des erreurs
- **Aucun fichier IaC trouvé** : Limiter l'examen à la découverte de ressources en direct via AWS CLI et noter l'écart
- **Permissions AWS insuffisantes** : Lister les permissions lecture seule requises pour l'examen
- **Échec de création GitHub** : Afficher tous les findings en markdown formaté à la console

## Critères de succès
- ✅ Les 6 piliers WAF examinés contre l'IaC et l'infrastructure en direct
- ✅ Tous les findings classifiés par niveau de risque et pilier
- ✅ Étapes de correction exploitables avec exemples IaC pour chaque finding
- ✅ Issues GitHub créées pour le suivi d'équipe
- ✅ Diagramme d'architecture généré pour le contexte EPIC
- ✅ Références documentation AWS incluses

Skills similaires

llm-obs-eval-bootstrap
datadog-labs / agent-skills

Générer une suite d'évaluateurs prêts à l'emploi à partir de traces LLM en production.

127
cosmosdb-datamodeling
github / awesome-copilot

Concevoir un modèle de données Azure Cosmos DB NoSQL adapté aux besoins applicatifs.

34 747
llm-obs-session-classify
datadog-labs / agent-skills

Classifier la satisfaction des sessions et traces LLM Observability Datadog en verdicts automatisés.

127
geofeed-tuner
github / awesome-copilot

Créer et optimiser des feeds de géolocalisation IP au format CSV selon RFC 8805.

34 747
pulumi-overview
pulumi / agent-skills

Gérer l'infrastructure cloud avec Pulumi via CLI, projets ou gouvernance avancée.

57