Fiabilité et continuité d'activité
Garder les charges de travail en marche quand la demande explose ou qu'un composant tombe : équilibrage de charge et health checks, Auto Scaling, mise en cache, mise à l'échelle des bases de données, tolérance aux pannes Multi-AZ, sauvegardes automatisées et les quatre stratégies de reprise après sinistre, du backup-restore à l'actif/actif.
Une instance meurt à 02h00. Un lancement produit triple le trafic en dix minutes. Que cela se voie hors de l'équipe ops dépend de décisions prises bien avant l'incident : combien de zones de disponibilité couvre la charge de travail, si un health check retire la cible défaillante de la rotation, si la capacité augmente sans intervention humaine, et à quelle vitesse vous restaurez les données après une suppression de table par erreur.
Ce domaine pèse 22 % du SOA-C03 et s'appuie directement sur le premier. Une politique de scaling, c'est une alarme CloudWatch avec une action accrochée dessus. Un basculement, c'est un health check qui lit une métrique. Ici, vous transformez cette télémétrie en disponibilité réelle.
Ce que couvre ce domaine
- Elastic Load Balancing avec ALB, NLB et Gateway Load Balancer, les health checks des target groups et le diagnostic des cibles bloquées en unhealthy
- Les health checks Route 53, le basculement DNS et le zonal shift avec Application Recovery Controller
- Les Auto Scaling groups EC2, les politiques target tracking, step, scheduled et predictive, les lifecycle hooks et l'instance refresh
- La mise à l'échelle des conteneurs et du serverless : auto scaling des services ECS, EKS et concurrence Lambda
- La mise en cache avec CloudFront et ElastiCache, et la mise à l'échelle relationnelle avec les read replicas et Aurora Serverless v2
- Les modes de capacité DynamoDB, l'auto scaling des tables et DAX
- La tolérance aux pannes Multi-AZ, AWS Backup et les snapshots, la restauration point-in-time, le versioning et la réplication S3
- Les quatre stratégies de reprise après sinistre et les objectifs de RTO et de RPO qui tranchent entre elles
Pourquoi c'est important
Les questions de ce domaine vous demandent rarement de définir Multi-AZ. Elles posent une contrainte (un RPO de 5 minutes, un budget qui exclut une seconde flotte active, une application à sessions locales qui casse quand les instances se terminent) et vous demandent quel mécanisme y répond. Pour trancher, il faut savoir ce que chaque option coûte en argent, en temps de récupération et en travail opérationnel, pas seulement ce qu'elle fait.
Le même raisonnement revient à chaque astreinte. Si vous distinguez un health check en échec d'une politique de scaling qui n'a jamais déclenché, vous passez l'incident à régler le problème au lieu de découvrir l'architecture.