1.3 - Remédiation automatisée (EventBridge et SSM Automation)
L'objectif 1.3 de l'AWS SysOps Administrator couvre la remédiation des problèmes à partir de la supervision. Le schéma central est piloté par les événements : une alarme CloudWatch, un résultat GuardDuty ou une règle AWS Config non conforme émet un événement, une règle Amazon EventBridge le filtre, et une cible exécute la correction - le plus souvent un runbook AWS Systems Manager Automation ou une fonction Lambda qui redémarre un service, étiquette ou isole une instance, ou redimensionne une ressource. Les actions de remédiation AWS Config attachent un document SSM à une règle pour une correction manuelle ou automatique. L'auto-récupération EC2 remplace le matériel défaillant, et les dead-letter queues captent les livraisons d'événements en échec. Tu dois connaître les motifs d'événements EventBridge, les règles planifiées et les bus inter-comptes. Attends-toi à des mises en situation demandant quel déclencheur et quelle action de remédiation associer.
Détecter puis corriger seul = alarme/résultat -> règle EventBridge -> runbook SSM Automation. Une règle Config peut auto-remédier via un document SSM. Les événements en échec vont dans une dead-letter queue.
Questions d'entraînement
1. Une alarme CloudWatch nouvellement créée n'a pas encore reçu assez de données pour évaluer son seuil. Dans quel état est-elle ?
- INSUFFICIENT_DATA (bonne réponse)
- ALARM
- OK
- PENDING_EVALUATION
Avec trop peu de points de données, une alarme reste en INSUFFICIENT_DATA jusqu'à en recevoir assez. Les trois états valides sont OK, ALARM et INSUFFICIENT_DATA ; PENDING_EVALUATION n'existe pas.
2. Une alarme a une période d'évaluation de 5 et un 'datapoints to alarm' de 3. Que signifie cette configuration ?
- L'alarme se déclenche si 3 des 5 derniers points dépassent le seuil (bonne réponse)
- L'alarme se déclenche seulement si 5 points consécutifs dépassent tous le seuil
- L'alarme attend 3 minutes puis moyenne 5 échantillons avant de décider
- L'alarme exige 5 dépassements dans une fenêtre glissante de trois heures
C'est une alarme M sur N : 3 des 5 derniers points évalués doivent dépasser le seuil pour déclencher l'alarme. Elle n'exige pas que les 5 soient des dépassements consécutifs.
3. Une instance EC2 est arrêtée chaque nuit, donc sa métrique cesse de remonter. Vous ne voulez pas que l'alarme passe en ALARM pendant ce trou. Quel réglage 'treat missing data' convient ?
- missing, l'alarme conserve son état actuel pendant l'absence (bonne réponse)
- breaching, chaque point manquant compte comme un dépassement du seuil
- notBreaching combiné à une fenêtre d'attente obligatoire de 24 heures
- ignore, ce qui désactive définitivement le moteur d'évaluation
Traiter les données manquantes comme 'missing' fait conserver l'état actuel pendant les trous attendus, évitant les fausses ALARM. 'breaching' la forcerait en ALARM, et 'ignore' garde le dernier état sans désactiver l'évaluation.
4. Un metric filter compte les erreurs 500. Vous voulez un email lors d'un pic ET une remédiation auto. Quelle chaîne fonctionne ?
- Alarme sur la métrique du filter, notifier SNS, et lancer un runbook Systems Manager (bonne réponse)
- Pointer le metric filter vers SNS pour envoyer l'email à chaque erreur
- Planifier une requête Logs Insights et emailer ses résultats via Lambda
- Créer une règle EventBridge qui lit le texte brut du log group chaque minute
Filter vers métrique, alarme sur la métrique, puis l'alarme diffuse vers SNS (email) et un runbook SSM Automation (remédiation). Un metric filter ne notifie pas SNS directement, Insights est ponctuel, et EventBridge ne lit pas le texte brut des logs.
5. Après installation de l'agent CloudWatch, aucun événement n'apparaît dans la console. Que vérifier EN PREMIER ?
- Si la rétention du log group a été mise à un seul jour par erreur
- Si le pattern du metric filter correspond exactement au format des logs
- Si le widget du dashboard pointe vers la bonne Region AWS
- Si l'agent tourne et si son rôle autorise CreateLogStream/PutLogEvents (bonne réponse)
Des logs absents viennent presque toujours de l'agent arrêté ou d'un rôle sans CreateLogStream/PutLogEvents ; vérifiez cela d'abord. La rétention, les patterns de metric filter et les widgets de dashboard n'empêchent pas l'ingestion dans le group.
6. Une app écrit ses logs, mais votre alarme sur un metric filter ne se déclenche jamais. Le filter vise app/prod alors que l'app écrit dans app/production. Quel est le problème ?
- Le pattern du metric filter est sensible à la casse et doit être en minuscules
- Le metric filter est attaché au mauvais nom de log group (bonne réponse)
- La période de l'alarme est trop longue, ignorant chaque point de donnée
- La rétention du stream a expiré les événements avant l'évaluation de l'alarme
Le filter surveille app/prod mais l'app écrit dans app/production ; il ne voit donc rien et la métrique reste vide. La casse, la période d'alarme et la rétention ne sont pas en cause quand les noms de group ne correspondent pas.