Architecture AWS auto-résiliente après une panne à 2 h

Une simple panne EBS a figé un dashboard interne utilisé par 200+ agents support sans alerte. On m’a dit : « Assure-toi que ça n’arrive plus jamais. »

• Couplage serré entre compute, stockage et crons.
• Zéro métrique/alerte : on découvrait l’incident via Slack.
• Procédures backup/restore manuelles nécessitant un humain à 2h du matin.
• Rôles IAM partagés avec permissions illimitées.

1. Découpé le monolithe en services derrière des ALB, chacun dans son ASG multi-AZ.
2. Migré la persistance sur Amazon RDS Multi-AZ avec failover auto + PITR ; snapshots nightly répliqués cross-region.
3. Stocké assets + backups dans des buckets S3 versionnés avec lifecycle et réplication.
4. Tout codifié en Terraform, y compris des rôles IAM least privilege, pour des rebuilds déterministes.
5. Mis en place métriques/alertes CloudWatch branchées sur PagerDuty + tracing distribué via X-Ray/Grafana.
6. Organisé des game days mensuels simulant perte EBS, fail AZ et compromission de credentials.

L’incident suivant (fail AZ volontaire) s’est guéri en <90 s sans bruit pager. Le MTTR est passé d’heures à minutes et la direction a accepté d’onboarder une nouvelle BU.

La fiabilité est un état d’esprit, pas une feature. En supposant que chaque dépendance tombe, on a rendu la résilience ennuyeuse — exactement ce qu’il faut pour des dashboards critiques.