2.1 - Scalabilité et haute disponibilité
L'objectif 2.1 de l'AWS SysOps Administrator couvre la scalabilité et la haute disponibilité. Tu exécutes des instances dans plusieurs zones de disponibilité derrière un Elastic Load Balancer pour que la perte d'une zone ne fasse pas tomber l'application, et tu utilises EC2 Auto Scaling pour ajuster la capacité à la demande. Connais les politiques de scaling - target tracking, step, simple, planifiée et prédictive - plus les cooldowns, le warm-up, les lifecycle hooks, les warm pools et l'instance refresh pour les mises à jour progressives. Règle le type de contrôle de santé sur ELB pour que le groupe remplace les instances marquées non saines par le load balancer, et adapte la capacité sur la bonne métrique comme le CPU, une métrique CloudWatch personnalisée ou la profondeur d'une file SQS. Le RDS Multi-AZ et les réplicas de lecture ajoutent résilience et montée en charge en lecture. Attends-toi à des mises en situation sur la bonne conception HA ou Auto Scaling.
Couche web HA = instances sur plusieurs zones derrière un load balancer. Remplacer les instances jugées non saines par l'ELB = type de contrôle de santé ELB. Maintenir un taux stable = scaling target tracking.
Questions d'entraînement
1. Une alarme CloudWatch surveille StatusCheckFailed_System pour une instance EC2. Quelle action déplace l'instance vers un matériel sain tout en conservant son ID et son IP ?
- L'action recover d'EC2 (bonne réponse)
- L'action terminate d'EC2 suivie d'un remplacement par Auto Scaling
- L'action stop d'EC2, qui éteint l'instance jusqu'au matin
- Une action reboot qui réinstalle d'abord le système d'exploitation invité
L'action recover migre l'instance vers un nouveau matériel sous-jacent en conservant l'ID, l'IP privée, l'Elastic IP et les métadonnées, idéal pour un échec du system status check. Terminate/remplacer changerait l'identité.
2. Vous êtes alerté chaque fois que le CPU ou la mémoire pique brièvement, ce qui crée de la fatigue d'alerte. Vous ne voulez une alerte que si les DEUX sont élevés en même temps. Que configurez-vous ?
- Une composite alarm reliant les deux alarmes avec une logique AND (bonne réponse)
- Une alarme metric math qui additionne les deux métriques non liées
- Deux SNS topics distincts que les abonnés corrèlent à la main à chaque fois
- Une alarme haute résolution évaluée chaque seconde sur chaque métrique
Une composite alarm combine des états d'alarme existants avec une règle (ALARM(cpu) AND ALARM(mem)), donc elle ne se déclenche que si les deux dépassent, réduisant le bruit. Additionner des métriques non liées n'a pas de sens.
3. Une application se bloque parfois, faisant échouer l'instance status check alors que le matériel reste sain. Quelle action d'alarme redémarre la même instance sur place ?
- L'action reboot d'EC2 (bonne réponse)
- L'action recover d'EC2, qui la migre vers un nouveau matériel sous-jacent
- L'action terminate reliée à un launch template de remplacement
- L'action stop, laissant l'instance éteinte jusqu'au retour d'un opérateur
Une action reboot redémarre la même instance sur place, débloquant un OS invité figé alors que le matériel va bien (échec de l'instance status check). Recover concerne les défaillances système (matériel), pas un blocage côté invité.
4. Un Auto Scaling group a min 2, capacité désirée 4, max 8. Une politique de scaling tente d'ajouter 6 instances d'un coup. Combien d'instances tourneront réellement ?
- 10, la désirée plus les six demandées
- 8, car le maximum plafonne le groupe (bonne réponse)
- 6, seules les nouvelles demandées
- 4, la désirée ne change jamais
La capacité désirée peut croître mais reste bornée par le max : 4 + 6 viserait 10 mais s'arrête à 8. Le groupe ne lance jamais sous le min ni au-dessus du max, quelles que soient les demandes.
5. Vous avez des charges dans trois Regions et voulez qu'un log group d'une seule Region reçoive les événements de toutes pour des dashboards de continuité. Qu'est-ce qui le permet ?
- Exporter manuellement les logs de chaque Region vers S3 puis les réimporter
- Activer le detailed monitoring, qui réplique les log groups entre Regions
- Des subscription filters alimentant une stream Kinesis Data Firehose cross-Region (bonne réponse)
- Rien, car les CloudWatch Logs ne peuvent quitter leur Region de création
Les subscription filters peuvent pousser les événements vers un Kinesis Data Firehose (ou Data Stream) dans une autre Region, centralisant les logs. Le detailed monitoring ne réplique pas les logs, l'aller-retour S3 manuel n'est pas temps réel, et les logs peuvent quitter leur Region via ces pipelines.
6. Un compte sécurité central doit ingérer en continu les logs de 40 comptes membres. Quel modèle est le plus fiable ?
- Que chaque compte email ses fichiers de logs exportés chaque semaine
- Des subscription filters cross-account livrant vers un Firehose/Kinesis central (bonne réponse)
- Donner un accès lecture à l'équipe sécurité pour copier les logs à la main
- Activer le detailed monitoring dans chaque compte membre pour synchroniser
Des subscription filters cross-account vers un Kinesis Data Stream ou Firehose central offrent un pipeline d'agrégation continu, automatisé et fiable. Emailer des fichiers, copier à la main ou le detailed monitoring ne sont pas des solutions de logging centralisé temps réel.