Amazon SOA-C02: Surveillance, journalisation et remédiation — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

La surveillance, la journalisation et la remédiation constituent le système nerveux opérationnel des environnements AWS : elles détectent les problèmes, fournissent du contexte et pilotent les actions correctives. Ce domaine couvre la création de métriques et de tableaux de bord pertinents, la collecte et la conservation des journaux de manière rentable, la création d’une observabilité applicative traçable, ainsi que l’automatisation des alertes et des remédiations. Les bonnes implémentations équilibrent le rapport signal/bruit, maîtrisent les coûts et garantissent que les playbooks et les automatisations sont testés et auditables.

Métriques, tableaux de bord et alarmes CloudWatch

Concevez les métriques autour des SLI (indicateurs de niveau de service) métier et opérationnels (latence, taux d’erreur, profondeur de la file d’attente, CPU/mémoire pour l’infra). Utilisez les métriques intégrées (EC2, RDS, ELB) ainsi que des métriques personnalisées via PutMetricData pour les compteurs au niveau applicatif (

undefined

). Préférez les dimensions qui permettent le filtrage (InstanceId, ServiceName) et évitez les dimensions à haute cardinalité qui font exploser les coûts des métriques.

Utilisez les tableaux de bord CloudWatch pour combiner les métriques, les journaux et les alarmes dans des vues opérationnelles. Créez des widgets dans la console ou via CloudFormation (AWS::CloudWatch::Dashboard) avec la fonction mathématique sur les métriques (metric math) pour les métriques dérivées : calculez le taux d’erreur en utilisant la fonction mathématique sur les métriques (ERRORS/SUM(REQUESTS)) et affichez les centiles (p50, p90, p99). Pour les alarmes, choisissez des modèles de configuration en fonction de l’intention :

• Alarmes sur une seule métrique pour les seuils simples :

undefined

• Alarmes composites pour réduire le bruit en combinant des conditions (AND/OR) sur plusieurs alarmes.
• Détection d’anomalies pour ajuster automatiquement les seuils : utilisez la détection d’anomalies CloudWatch sur une métrique avec un comportement saisonnier attendu.

Critères de décision : utilisez les périodes d’évaluation et les paramètres de points de données par alarme (datapoint-to-alarm) pour éviter les oscillations (flapping) ; déclenchez SNS, Auto Scaling ou Systems Manager Automation comme actions d’alarme. Préférez les alarmes composites et la détection d’anomalies pour les environnements avec des bases de référence variables.

CloudWatch Logs, Logs Insights et rétention

Agrégez les journaux avec les groupes de journaux CloudWatch Logs et structurez-les par application et environnement. Créez des groupes de journaux via la CLI :

undefined

et appliquez la conservation avec

undefined

. Utilisez des filtres d’abonnement pour diffuser les journaux en continu vers Kinesis Data Firehose (pour S3/Redshift), Lambda (traitement en temps réel) ou des outils partenaires ; compressez et partitionnez dans S3 pour réduire les coûts de stockage.

Utilisez CloudWatch Logs Insights pour les requêtes ad hoc et les tableaux de bord ; créez des requêtes enregistrées qui extraient les ID de trace et les contextes d’erreur (par ex.,

undefined

). Pratiques de contrôle des coûts de rétention et d’ingestion :

• Définissez une rétention appropriée par groupe de journaux (7/30/90/365 jours) en fonction des besoins de conformité et de dépannage.
• Exportez les journaux plus anciens vers S3 via le cycle de vie de rétention ou Firehose avec des règles de compression et de cycle de vie vers Glacier/Archive.
• Utilisez l’échantillonnage ou les journaux structurés (JSON) et le format de métrique intégré (EMF) pour réduire les journaux coûteux à haute cardinalité tout en continuant à dériver des métriques.

Critères de décision : une rétention courte pour les journaux de débogage verbeux, une rétention plus longue pour les journaux d’audit/sécurité ; dirigez les journaux à fort volume vers S3 plutôt que de les conserver indéfiniment dans CloudWatch.

CloudTrail, pistes d’audit et historique des événements

Activez CloudTrail dans toutes les régions et tous les comptes ; créez un journal de suivi (trail) d’organisation pour une journalisation d’audit centralisée dans un compartiment S3 sécurisé, avec validation des fichiers journaux et chiffrement SSE-KMS. Configurez les événements de gestion (Lecture/Écriture) et activez sélectivement les événements de données (niveau objet S3, invocation de fonction Lambda) lorsqu’un audit détaillé est requis, car les événements de données ont un volume et un coût plus élevés.

Utilisez l’historique des événements CloudTrail dans la console pour des recherches rapides sur 90 jours et CloudTrail Lake ou Athena sur les journaux exportés vers S3 pour des analyses et des investigations à long terme. Protégez le journal de suivi en :

• Appliquant des journaux de suivi multi-régions pour capturer les événements de services globaux.
• Intégrant CloudTrail avec CloudWatch Logs pour une détection quasi en temps réel, ou EventBridge pour router des événements spécifiques vers Lambda/Systems Manager pour une remédiation automatisée.
• Appliquant des politiques de compartiment S3 et S3 Object Lock (si nécessaire) pour empêcher toute modification.

Critères de décision : activez les événements de données uniquement pour les compartiments/fonctions où une visibilité forensique est nécessaire ; utilisez des journaux de suivi centralisés et des modèles d’accès inter-comptes pour simplifier la conformité.

Traçage applicatif et observabilité (X-Ray)

Instrumentez les applications avec les SDK AWS X-Ray pour émettre des segments et des sous-segments. Pour les runtimes non instrumentés, exécutez le démon/agent X-Ray en tant que sidecar ou service (tâche ECS, démon EC2 ou traçage intégré à Lambda). Configurez des règles d’échantillonnage pour contrôler le volume de traces et définissez des cartes de service (service maps) dans ServiceLens pour visualiser les dépendances entre les services. Annotez les traces avec des clés métier (userId, orderId) et enregistrez les exceptions/métadonnées pour faciliter le triage.

Corrélez les traces avec les journaux en incluant l’ID de trace X-Ray dans les journaux d’application (utilisez l’en-tête de trace ou le SDK pour obtenir l’ID de trace actuel) afin que les requêtes CloudWatch Logs Insights puissent joindre les journaux et les traces. Pour Lambda, activez le traçage actif (Console ou

undefined

) pour envoyer automatiquement les traces à X-Ray. Utilisez l’analyse des traces pour détecter les latences de queue (tail latencies), les points chauds (hotspots) et les détails des appels de base de données.

Critères de décision : activez le traçage pour les services critiques et utilisez l’échantillonnage adaptatif pour limiter les coûts ; préférez les traces structurées (annotations/métadonnées) pour rendre la corrélation Journaux+Traces déterministe.

Correction automatisée et alertes (EventBridge/Lambda)

Utilisez les règles EventBridge pour correspondre aux changements d’état des alarmes CloudWatch, aux événements CloudTrail ou à des événements personnalisés et les router vers des cibles telles que Lambda, des documents Systems Manager Automation, Step Functions ou SNS. Créez des règles avec des transformateurs d’entrée (input transformers) pour transmettre un contexte minimal à l’action de correction (

undefined

). Implémentez des fonctions Lambda pour les corrections légères (redémarrer un service, révoquer des informations d’identification) mais utilisez SSM Automation ou Step Functions pour les playbooks auditables et de longue durée avec des points de contrôle.

Concevez les corrections en gardant la sécurité à l’esprit : incluez des modes dry-run, l’idempotence, des étapes de validation, le moindre privilège IAM, la journalisation et un kill-switch. Utilisez des files d’attente de lettres mortes (DLQ) et des politiques de nouvelle tentative sur les intégrations EventBridge/Lambda et publiez les tentatives de correction dans un journal d’audit ou une piste de sécurité. Testez les automatisations dans un compte de pré-production (staging) et exécutez des tests canary après le déploiement.

Critères de décision : préférez SSM Automation ou Step Functions pour les récupérations multi-étapes et l’approbation humaine ; utilisez Lambda pour les correctifs simples et rapides. Incluez toujours une possibilité de rollback manuel ou un point d’arrêt pour intervention humaine pour les actions à risque.

Pièges courants et critères de décision

• Se fier à une seule métrique pour les décisions de santé : combinez les métriques (par ex., taux d’erreur + latence + limitations) ou utilisez des alarmes composites/metric math pour éviter les faux positifs.
• Ne pas tenir compte des coûts de rétention et d’ingestion des logs : définissez la rétention par groupe de logs, routez les logs en vrac vers S3 via Firehose avec compression, et utilisez des politiques de cycle de vie pour déplacer les anciennes données vers des niveaux de stockage moins chers.
• Sur-instrumentation avec des dimensions à haute cardinalité ou un échantillonnage des traces désactivé : limitez les dimensions et activez l’échantillonnage adaptatif pour maîtriser les coûts tout en préservant le signal.
• Déployer une correction automatisée sans la tester : validez en pré-production (staging), utilisez des indicateurs dry-run, et assurez-vous de l’idempotence et de la sécurité des rollbacks avant l’activation en production.
• Fatigue liée aux alertes à cause d’alarmes bruyantes : utilisez la détection d’anomalies, les alarmes composites, les fenêtres de suppression et ne remontez que les événements significatifs au personnel d’astreinte.
• Manque de corrélation entre les logs, les métriques et les traces : propagez les ID de trace dans les logs et les métriques EMF, et construisez des requêtes Logs Insights enregistrées et des vues ServiceLens pour lier les données entre elles.

Problème pratique : Scénario d’utilisation

Acme Payments subit des échecs intermittents de traitement des paiements pendant les pics de trafic ; les ingénieurs constatent une latence accrue et des erreurs 5xx sporadiques, mais les redémarrages automatisés ont parfois masqué la cause racine.

1. Instrumentez le service de paiement avec le SDK X-Ray et les métriques EMF ; ajoutez les ID de trace aux logs applicatifs et envoyez les métriques structurées OrdersFailed et OrdersProcessed via PutMetricData/EMF.
2. Créez un calcul CloudWatch metric math pour calculer le taux d’erreur (OrdersFailed / OrdersProcessed) et une alarme composite combinant un taux d’erreur > seuil ET une latence p99 > seuil.
3. Routez les actions d’alarme vers une règle EventBridge qui déclenche un workflow Step Functions pour les étapes de diagnostic (collecter les traces/logs récents, exécuter des bilans de santé) et, si la sécurité le permet, un redémarrage automatisé via SSM Automation.
4. Configurez l’abonnement CloudTrail et CloudWatch Logs pour archiver les logs complets sur S3 (compressés) avec un cycle de vie vers Glacier, et définissez une rétention courte dans CloudWatch pour les logs de débogage verbeux.
5. Exécutez des tests de bout en bout et des transactions synthétiques canary (CloudWatch Synthetics) pour valider l’observabilité et le flux de correction avant d’activer l’auto-correction en production.

Raisonnement : corréler les métriques, les logs et les traces pour localiser la cause racine plutôt que de traiter les symptômes à répétition ; combiner les alarmes pour réduire le bruit et utiliser une automatisation auditable et testée (Step Functions/SSM) pour une correction sûre tout en maîtrisant les coûts de stockage des logs.

Tous les domaines · Haute disponibilité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →