Amazon SAA-C03: Gestion, opérations, observabilité et coûts — Guide d'étude

By Laurynas Brazys · 16 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fait partie du AWS SAA-C03 — Guide d’étude complet. 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.

CloudWatch : Métriques, Espaces de noms, Tableaux de bord et Alarmes

CloudWatch est le plan de télémétrie par défaut pour les services AWS, mais son utilité dépend entièrement de la connaissance de l’espace de noms dans lequel un service publie ses métriques. Un espace de noms est un conteneur pour les métriques qui empêche les conflits entre les services — AWS/Lambda contient Invocations, Errors et Throttles pour les fonctions, tandis que AWS/Events contient Invocations, FailedInvocations, TriggeredRules et MatchedEvents pour les règles EventBridge. Cette distinction est importante lors du diagnostic des pipelines événementiels. Si une règle EventBridge invoque une API tierce via une destination d’API et qu’aucun trafic n’arrive en aval, la réponse ne se trouve pas dans AWS/Lambda ; elle se trouve dans AWS/Events. La vérification de TriggeredRules vous indique si le modèle de la règle a réellement correspondu, et Invocations/FailedInvocations vous indiquent si la cible elle-même a été appelée et si l’appel a réussi. Chercher dans les métriques Lambda parce que Lambda est le service le plus familier omet le fait que la règle n’a peut-être jamais correspondu à un événement entrant.

La résolution des métriques est un paramètre par ressource qui a des implications sur les coûts. La surveillance de base émet des métriques toutes les cinq minutes sans frais supplémentaires, ce qui est suffisant pour les charges de travail stables et de longue durée, mais beaucoup trop grossier pour les réactions d’autoscaling, la détection de pics ou les calculs de SLO qui nécessitent une résolution à la minute. La surveillance détaillée réduit cet intervalle à une minute (et à une seconde pour les métriques personnalisées à haute résolution), ce que vous activez lorsque les groupes de mise à l’échelle doivent réagir rapidement. C’est une fonctionnalité payante — c’est pourquoi elle n’est pas activée par défaut.

Chaque service émet nativement un ensemble de métriques par défaut, mais l’hyperviseur ne peut pas voir à l’intérieur du système d’exploitation invité. CPUUtilization, NetworkIn et DiskReadOps sont visibles pour EC2 sans effort ; l’utilisation de la mémoire et les pourcentages d’utilisation du système de fichiers nécessitent l’agent CloudWatch, qui est le seul moyen de les obtenir. Les métriques d’application personnalisées arrivent également via l’agent ou via PutMetricData.

Les alarmes doivent distinguer le signal du bruit. Une seule alarme sur CPU > 50% se déclenche constamment lors de pics normaux et habitue les opérateurs à l’ignorer. Les alarmes composites combinent les états des alarmes enfants avec une expression de règle booléenne afin que les opérateurs ne soient alertés que lorsqu’une condition réellement exploitable est remplie. Pour une charge de travail où des pics de CPU transitoires sont bénins, mais une pression CPU soutenue combinée à des IOPS de lecture disque élevées indique un problème réel :

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Les alarmes enfants peuvent toujours passer à l’état ALARM en interne, mais seule l’alarme composite déclenche SNS. Deux alarmes indépendantes qui alertent toutes deux l’équipe d’astreinte recréent le problème du bruit ; une seule alarme à un seuil plus élevé manque la corrélation.

Les tableaux de bord regroupent des widgets de métriques, des widgets de journaux et du texte. Il existe deux modèles de partage et les confondre est un piège courant. Si un utilisateur dispose déjà d’un compte AWS, accordez-lui une identité IAM (ou un rôle via l’observabilité inter-comptes) avec cloudwatch:GetDashboard et cloudwatch:GetMetricData. Si l’utilisateur n’a pas de compte AWS — un chef de produit, un client partie prenante — utilisez la fonctionnalité de partage de tableau de bord intégrée, qui produit un lien partageable protégé par un seul e-mail/mot de passe, un pool d’utilisateurs Cognito ou une URL publique (rarement approprié). Envoyer des captures d’écran par e-mail n’est pas de l’observabilité, et créer un utilisateur IAM avec un accès à la console pour un utilisateur non-AWS n’est pas du moindre privilège.

Observabilité inter-comptes avec OAM

Passer d’un compte à l’autre pour consulter des dizaines de métriques est ingérable. L’observabilité inter-comptes de CloudWatch désigne un compte de surveillance comme récepteur (sink) central et un certain nombre de comptes sources qui partagent avec lui des métriques, des journaux et des traces via des ressources de récepteur (sink) et de lien (link). Le déploiement le plus rapide à grande échelle consiste à ouvrir la console CloudWatch dans le compte de surveillance, à créer un récepteur (sink) et à déployer le modèle CloudFormation StackSet généré dans toute l’organisation pour créer des ressources AWS::Oam::Link dans chaque compte source :

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Résoudre ce problème avec des rôles IAM inter-comptes et des requêtes manuelles est techniquement possible, mais ne vous donne pas de tableaux de bord unifiés, de requêtes Metrics Insights inter-comptes, ou l’enrichissement automatique des étiquettes avec le nom du compte que les liens OAM fournissent.

Container Insights et Traçage distribué

Pour les charges de travail conteneurisées, Container Insights est la fonctionnalité CloudWatch de référence. Sur EKS, il déploie l’agent CloudWatch (ou le collecteur ADOT) en tant que DaemonSet, ainsi que Fluent Bit pour le transfert des journaux. L’agent collecte les métriques de cAdvisor et du kubelet et les émet dans les espaces de noms ECS/ContainerInsights et ContainerInsights (CPU/mémoire par pod, nœud, espace de noms et cluster), tandis que Fluent Bit envoie stdout/stderr dans des groupes de journaux tels que /aws/containerinsights/<cluster>/application, /dataplane et /host. Il est possible de déployer votre propre pile Prometheus/Grafana ; le modèle managé est Container Insights plus Logs Insights :

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Les métriques vous disent que quelque chose est lent ; les traces vous disent où. X-Ray instrumente chaque service dans le chemin d’une requête, propageant un ID de trace via l’en-tête X-Amzn-Trace-Id et émettant des segments et des sous-segments au démon X-Ray ou au collecteur ADOT. La carte de service visualise les nœuds et les arêtes avec les pourcentages de latence, d’erreur et de défaillance. Sans X-Ray, un pic p99 apparaît comme une métrique CloudWatch sans attribution.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights, X-Ray et CloudWatch Logs constituent les trois piliers de l’observabilité des microservices.

Les Trois Flux de Logs : CloudTrail, VPC Flow Logs, CloudWatch Logs

Toute stratégie d’observabilité AWS distingue trois flux de logs distincts : l’activité des API du plan de contrôle (CloudTrail), l’activité réseau du plan de données (VPC Flow Logs), et les sorties des applications/du système d’exploitation (CloudWatch Logs). Chacun répond à une question d’investigation différente, et les confondre est une erreur de conception courante.

CloudTrail enregistre chaque appel d’API AWS — qui l’a invoqué (userIdentity), depuis quelle IP, sur quelle ressource, avec quels paramètres, et s’il a réussi. C’est le seul service qui relie de manière fiable une modification à un principal IAM spécifique. Une idée reçue courante est que CloudWatch Logs est le bon endroit pour chercher l’activité des API ; CloudWatch Logs capture les sorties des applications/systèmes, pas les données d’audit au niveau du principal. CloudTrail peut livrer ses événements à CloudWatch Logs pour un filtrage de métriques en temps réel, mais l’enregistrement d’audit sous-jacent provient de CloudTrail.

Dans un environnement AWS Organizations, le modèle correct est un trail d’organisation créé depuis le compte de gestion (ou un compte administrateur délégué), qui inscrit automatiquement les nouveaux comptes membres et envoie les événements dans un unique bucket S3 situé dans un compte dédié à l’archivage des logs :

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

Le bucket de destination nécessite le versioning, une politique de bucket restreignant s3:PutObject au principal de service CloudTrail, le chiffrement SSE-KMS, un accès en lecture seule inter-comptes pour les auditeurs, et idéalement S3 Object Lock en mode conformité pour des garanties WORM. La validation des fichiers journaux produit des fichiers de synthèse signés afin que toute altération soit détectable. Les événements de gestion sont activés par défaut pour 90 jours ; leur conservation au-delà nécessite un trail. Les événements de données (niveau objet S3, invocation Lambda, niveau élément DynamoDB) sont optionnels en raison de leur volume et de leur coût. Pour les requêtes historiques ad-hoc, CloudTrail Lake ou Athena sur le bucket du trail vous permet d’exécuter du SQL :

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs capture les métadonnées sur le trafic IP — le 5-tuple, les octets, les paquets, l’action (ACCEPT/REJECT), et le statut du log — pour un VPC, un sous-réseau ou une ENI. Ils ne capturent pas les charges utiles. Les cibles de livraison sont CloudWatch Logs, S3 ou Kinesis Data Firehose. Choisissez S3 pour l’archivage ; choisissez CloudWatch Logs lorsque vous avez besoin de filtres de métriques pour déclencher des alarmes sur des modèles de trafic suspects ; choisissez Firehose lorsque l’exigence est l’analytique en quasi-temps réel. Le pipeline canonique en quasi-temps réel pour un VPC avec des NLB, des ASG et des bases de données :

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Le chemin alternatif CloudWatch Logs → filtre d’abonnement → Firehose → OpenSearch fonctionne mais ajoute une étape et un coût supplémentaires. S3 est un mauvais choix lorsque l’exigence est le « quasi-temps réel ». Ne pas activer du tout les Flow Logs est le piège le plus dommageable : lorsqu’un incident de sécurité se produit, il n’y a aucune trace de la source/destination/port et aucune visibilité sur les ACCEPT vs REJECT. Le même raisonnement s’applique aux journaux d’accès ALB — optionnels, livrés à S3, et sans eux, il n’y a aucun enregistrement au niveau de la requête des IP clientes, des codes de réponse, des latences des cibles ou des user agents. Ensemble, les Flow Logs (L3/L4) et les journaux d’accès ALB (L7) constituent la base pour l’investigation forensique du trafic.

CloudWatch Logs reçoit les logs des applications, de Lambda et du système d’exploitation via l’agent CloudWatch. Sa puissance vient des filtres de métriques : des expressions de motifs qui analysent les événements entrants et incrémentent une métrique personnalisée en cas de correspondance, ce qui déclenche ensuite une alarme :

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Un filtre parallèle sur le port 3389 couvre le RDP. L’ingestion de logs sans alerte permet une investigation post-incident, mais pas la prévention.

Pour les flottes de grande taille, la norme est de distribuer les logs vers un pipeline de traitement via un filtre d’abonnement sur un groupe de journaux, en envoyant en streaming les événements correspondants vers un Kinesis Data Stream, Firehose ou Lambda en quasi-temps réel :

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

Le piège est d’envoyer les logs bruts vers le stockage sans pipeline de traitement : les déverser dans S3 sans catalogue Glue, sans index OpenSearch et sans groupe de travail Athena signifie que les logs existent mais ne peuvent pas être exploités lors d’un incident. L’observabilité nécessite une surface d’interrogation, pas seulement des octets durables. Les groupes de journaux nécessitent également des politiques de rétention explicites — la valeur par défaut est « ne jamais expirer », ce qui consomme de l’argent discrètement — et peuvent être exportés vers S3 pour un archivage à long terme via des règles de cycle de vie.

Détection d’Événements au Niveau API avec une Surcharge Minimale

Pour les événements de grande valeur du plan de contrôle — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin sans MFA — le modèle avec la surcharge la plus faible est CloudTrail → Règle EventBridge → SNS. EventBridge reçoit nativement chaque événement de gestion CloudTrail, et une règle avec un motif d’événement ne nécessite aucun code de liaison Lambda :

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

Envoyer CloudTrail vers CloudWatch Logs et appliquer un filtre de métrique fonctionne également, mais cela ajoute un groupe de journaux, un filtre, une alarme et un coût, ce qui augmente la surcharge opérationnelle lorsque l’exigence est simplement « alerter sur l’API X ».

AWS Config : Configuration continue et dérive

Config et CloudTrail sont souvent confondus, mais ils répondent à des questions fondamentalement différentes. CloudTrail enregistre qui a appelé quoi ; Config enregistre à quoi ressemble la ressource maintenant et comment elle a changé au fil du temps. S’attendre à ce que Config journalise les appels d’API est une erreur classique — Config ne sait pas qu’un utilisateur a invoqué PutBucketAcl ; il sait qu’à 14:03:22, l’ACL du bucket est passée de l’état A à l’état B. Pour identifier le principal, corrélez l’enregistrement de changement de Config avec l’événement CloudTrail au même horodatage (Config fournit un lien direct vers celui-ci dans la console).

Les règles Config évaluent les ressources par rapport à un état souhaité. Les règles gérées couvrent des vérifications courantes (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), et les règles personnalisées s’exécutent en tant que fonctions Lambda ou utilisent CloudFormation Guard. Les règles s’évaluent lors d’un changement de configuration et selon un calendrier, marquent les ressources comme COMPLIANT ou NON_COMPLIANT, et peuvent déclencher une remédiation automatique via des documents SSM Automation. C’est la réponse à faible charge opérationnelle pour « détecter un accès SSH ouvert » ou « détecter des types d’instances surdimensionnés » — les règles existent déjà et s’intègrent nativement avec SNS et Security Hub. Proposer des audits manuels périodiques, des scans planifiés ou des scanners développés sur mesure vous oblige à créer et à maintenir du code que Config fournit déjà.

Config publie les résultats d’évaluation sur SNS. Pour automatiser la remédiation, connectez une règle EventBridge à l’événement de changement de conformité et invoquez un document SSM Automation ou une fonction Lambda :

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Les agrégateurs consolident la conformité à travers une organisation ; les packs de conformité regroupent des règles pour des cadres de référence comme PCI-DSS ou HIPAA. Workload Discovery on AWS (anciennement AWS Perspective) est une solution basée sur Config qui visualise les relations entre les ressources et génère des diagrammes d’architecture — la réponse canonique lorsqu’une question demande un outil d’inventaire capable de schématiser un environnement existant. Config est un prérequis.

Security Hub, GuardDuty et Control Tower

Security Hub est le plan d’agrégation pour les résultats de sécurité (findings). Il ingère les données de GuardDuty (détection de menaces basée sur les VPC Flow Logs, DNS et CloudTrail), Inspector (résultats de vulnérabilité), Macie, IAM Access Analyzer et Config, puis normalise le tout au format AWS Security Finding Format (ASFF). L’activation de Security Hub active également des standards de sécurité, notamment le standard AWS Foundational Security Best Practices (FSBP) — des dizaines de vérifications automatiques (MFA sur le compte root, S3 public, EBS non chiffré, CloudTrail multi-régions) mappées en arrière-plan à des règles Config.

À l’échelle d’une organisation, désignez un compte administrateur délégué pour Security Hub (ainsi que pour GuardDuty et Config), activez le service et le standard FSBP pour toute l’organisation avec l’option « auto-enable new accounts », et acheminez les résultats via EventBridge vers SNS en faisant correspondre Security Hub Findings - Imported filtré sur l’ARN du standard FSBP avec Compliance.Status = FAILED. Développer votre propre Lambda pour analyser CloudTrail ou des tableaux de bord par compte ajoute une charge opérationnelle que Security Hub absorbe déjà.

Une distinction conceptuelle cruciale : Security Hub est détective et agrégatif, et non préventif. La prévention de la dérive est le rôle d’AWS Control Tower, qui orchestre une landing zone multi-comptes bien architecturée. Account Factory provisionne de nouveaux comptes avec une configuration de base pour le réseau, la journalisation et IAM. La gouvernance s’exprime à travers des garde-fous (guardrails) de trois types :

Les contrôles proactifs évaluent les modèles CloudFormation avant le déploiement d’une pile et refusent de créer, par exemple, une instance RDS non chiffrée. Security Hub vous indiquerait seulement que l’instance non chiffrée existe après qu’elle soit en cours d’exécution. Si une exigence mentionne « prévenir », pensez à Control Tower. Si elle mentionne « détecter, notifier ou agréger », pensez à Security Hub ou Config.

Macie : Découverte de données sensibles

Macie utilise le ML et la reconnaissance de formes pour identifier des données sensibles — PII, données financières, informations d’identification — à l’intérieur des objets S3. Le piège critique est de supposer que Macie protège les données. Ce n’est pas le cas. Macie découvre et rapporte. Utilisation correcte :

1. Activer Macie dans le compte/la région cible.
2. Configurer une tâche de découverte de données sensibles, ciblant des buckets/préfixes/tags selon un calendrier.
3. Acheminer les résultats via EventBridge (source: aws.macie) vers SNS pour les notifications, Lambda pour la remédiation (mise en quarantaine, renforcement de la politique de bucket), ou Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Sans la tâche de découverte, Macie ne produit rien. Sans la connexion EventBridge → SNS, les résultats restent dans la console Macie sans être remarqués.

Organizations, SCPs et politiques de balises

AWS Organizations expose trois types de politiques pertinents ici. Les politiques de balises (Tag policies) définissent les clés de balise, la casse et les valeurs autorisées — elles signalent la non-conformité et, combinées avec les conditions aws:ResourceTag/aws:RequestTag, peuvent être appliquées. Les politiques de contrôle des services (SCPs) définissent les autorisations maximales disponibles pour les principaux des comptes membres. Les politiques de sauvegarde (Backup policies) et les politiques de désinscription à l’IA (AI opt-out policies) complètent l’ensemble.

Un modèle mental crucial : les SCPs n’accordent jamais d’autorisations. Elles agissent comme un filtre sur ce que IAM (politiques d’identité, politiques de ressources, limites d’autorisations) peut autrement autoriser. Un principal doit avoir une autorisation Allow dans IAM et la SCP ne doit pas contenir de Deny (ou doit inclure l’action dans sa liste Allow). « Il suffit d’attacher une SCP » n’est jamais une réponse complète à une question d’autorisations — sans une autorisation Allow dans IAM, le principal se voit refuser l’accès par défaut, quel que soit le contenu de la SCP.

Pour exiger des balises lors de la création, combinez des politiques de balises avec une SCP telle que :

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

La politique de balises déclare le schéma ; la SCP refuse la création sans la balise ; la politique IAM accorde l’action de création. Les trois sont nécessaires. La règle required-tags d’AWS Config détecte et corrige les ressources existantes non conformes.

Systems Manager Automation et application de correctifs

Systems Manager (SSM) est l’épine dorsale opérationnelle pour les activités de cycle de vie sur des parcs de nœuds EC2 et hybrides. Deux constructions sont particulièrement importantes pour l’application de correctifs : les documents d’automatisation (Automation documents) (des runbooks déclaratifs en YAML/JSON qui appellent des API AWS ou des scripts) et les fenêtres de maintenance (Maintenance Windows) (qui planifient ces runbooks sur des cibles basées sur des balises ou des groupes de ressources, dans une fenêtre de changement avec des seuils de simultanéité et d’erreur).

Le flux canonique d’application de correctifs est AWS-RunPatchBaseline (un Command document) qui s’exécute sur des instances sélectionnées par une balise de Patch Group, en utilisant une Patch Baseline qui définit les règles d’approbation par système d’exploitation. Pour les instances derrière des répartiteurs de charge (load balancers), l’exécution directe de AWS-RunPatchBaseline interrompt les connexions en plein milieu du processus, car les instances restent InService dans le groupe cible. Le modèle correct est AWSEC2-PatchLoadBalancerInstance, qui :

1. Désenregistre l’instance de son groupe cible CLB ou ALB.
2. Attend le drainage des connexions / le délai de désenregistrement.
3. Invoque les étapes d’analyse et d’installation de la patch baseline.
4. Redémarre si la baseline l’exige.
5. Ré-enregistre l’instance et attend que la vérification de santé de la cible retourne healthy.

Deux prérequis peuvent causer le mode d’échec « produit des erreurs ». Premièrement, le rôle IAM passé en tant que AutomationAssumeRole doit inclure elasticloadbalancing:DeregisterTargets, RegisterTargets, et DescribeTargetHealth en plus des autorisations de patching SSM standard. Deuxièmement, l’instance doit être un nœud géré (managed node) — c’est-à-dire que l’agent SSM Agent doit être en cours d’exécution et le profil d’instance doit inclure AmazonSSMManagedInstanceCore. Sans cela, les appels de désenregistrement échouent ou SSM ne peut pas voir l’instance.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Sécurité · Tous les domaines · Haute disponibilité →

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

Parcourir Amazon →