Amazon DOP-C02: Architectures événementielles et automatisation — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-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.

Vue d’ensemble

Les architectures orientées événements découplent les producteurs des consommateurs, mettent l’accent sur la communication asynchrone et rendent les systèmes résilients aux pics de charge et aux pannes. Les principes fondamentaux sont le couplage faible via des événements/messages, la mise à l’échelle pilotée par les consommateurs, les gestionnaires idempotents, ainsi que la gestion explicite des défaillances et l’observabilité. AWS fournit les briques de base pour les files d’attente durables, le pub/sub, les bus d’événements, le traitement de flux, l’orchestration et l’automatisation opérationnelle. La maîtrise de l’interaction entre Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, les mappages de sources d’événements Lambda, AWS Systems Manager Automation et OpsCenter, ainsi que Kinesis Data Streams et Firehose, vous permet de construire des pipelines de données et d’automatisation évolutifs, tolérants aux pannes et auditables.

Messagerie et ingestion : SQS, SNS, Kinesis et Firehose

Amazon SQS fournit des files d’attente durables et évolutives pour le découplage. Les files d’attente standard offrent une livraison « au moins une fois » et un ordonnancement au mieux (best-effort) avec un débit pratiquement illimité ; elles conviennent aux workers parallèles qui tolèrent les messages en double et désordonnés grâce à des clés d’idempotence et des écritures conditionnelles. Les files d’attente FIFO garantissent une livraison ordonnée par groupe de messages et une sémantique de traitement « exactement une fois » avec déduplication (dans une fenêtre de cinq minutes). Elles garantissent l’ordre et un traitement unique mais sacrifient le débit absolu : utilisez plusieurs groupes de messages pour paralléliser au sein d’une file FIFO, ou activez le mode FIFO à haut débit pour des milliers de messages par seconde. Configurez le délai de visibilité (visibility timeout) par file d’attente ou par message pour qu’il dépasse le temps de traitement maximal ; avec des consommateurs Lambda, réglez le délai de visibilité à au moins six fois le délai d’expiration de votre fonction pour permettre les nouvelles tentatives avant qu’un message ne réapparaisse. Utilisez l’interrogation longue (long polling) pour réduire les réceptions vides. Les files de lettres mortes (DLQ) capturent les messages « empoisonnés » lorsqu’un message dépasse le maxReceiveCount ; effectuez plus tard un réacheminement (redrive) de la DLQ vers une file d’attente source pour un retraitement avec des correctifs. Surveillez ApproximateAgeOfOldestMessage pour détecter les retards et piloter les changements de simultanéité/d’autoscaling.

Amazon SNS fournit un service pub/sub géré à haut débit. Les publicateurs (publishers) envoient une seule fois vers un sujet (topic) ; SNS distribue (fan-out) à plusieurs abonnements (SQS, Lambda, HTTP/S, e-mail, mobile). Les politiques de filtrage d’abonnement utilisent les attributs de message pour router uniquement les notifications pertinentes par abonné, réduisant ainsi les coûts et la charge en aval ; elles permettent d’exprimer des prédicats tels que la correspondance exacte, le préfixe, les plages numériques, « tout-sauf » (anything-but) et l’existence (exists). Utilisez SNS pour la distribution (fan-out), les notifications découplées et les notifications push mobiles. Activez les nouvelles tentatives et envisagez des DLQ par abonnement pour les livraisons impossibles. Pour les besoins de distribution ordonnée (fan-out), les sujets SNS FIFO avec des abonnements SQS FIFO garantissent l’ordre et la déduplication.

Kinesis Data Streams fournit des flux ordonnés à faible latence avec un parallélisme au niveau des partitions (shards) pour l’analyse en temps réel et le traitement d’événements. Les producteurs écrivent des enregistrements (records) avec des clés de partition dans des partitions (shards) ; les consommateurs (Lambda, KCL, consommateurs Enhanced Fan-Out, Kinesis Data Analytics) lisent dans l’ordre par partition avec un système de points de contrôle (checkpointing). Utilisez la capacité à la demande pour une charge imprévisible ou des partitions provisionnées avec redimensionnement (resharding) pour un débit prévisible. Ajustez les clés de partition pour équilibrer les partitions surchargées (hot shards) et surveillez IteratorAge pour le retard des consommateurs. Le mode Enhanced Fan-Out offre un débit dédié de 2 Mo/s par flux de consommateur avec une transmission push à faible latence via HTTP/2.

Kinesis Data Firehose est un service de livraison entièrement géré pour l’ingestion en quasi-temps réel dans S3, Amazon OpenSearch Service, Splunk ou des points de terminaison HTTP, avec transformation Lambda optionnelle, mise en mémoire tampon (taille/temps), compression et chiffrement. Il s’alimente à partir d’appels directs PutRecord/PutRecordBatch, de Kinesis Data Streams ou d’abonnements CloudWatch Logs/Events. Utilisez Firehose lorsque vous avez besoin d’une livraison gérée avec transformation et traitement par lots, et que vous n’avez pas besoin de créer et d’opérer du code consommateur. Le partitionnement dynamique vous permet de router les enregistrements vers des préfixes S3 en fonction de clés pour un traitement en aval efficace.

Routage, Orchestration et Planification : EventBridge et Step Functions

Amazon EventBridge est le bus d’événements central pour le routage, la gouvernance et l’intégration inter-comptes/domaines d’événements. Utilisez le bus par défaut pour les événements de service AWS, les bus personnalisés pour segmenter les domaines et appliquer des autorisations, et les bus partenaires pour les intégrations SaaS. Les règles filtrent les événements via des patterns basés sur le contenu et ciblent plus de 200 services AWS. Utilisez les transformateurs d’entrée pour façonner les charges utiles (payloads) et l’archivage/relecture pour retraiter les événements historiques lors d’une reprise ou de l’intégration d’un nouveau consommateur. Les politiques de ressources permettent le routage d’événements inter-comptes pour consolider la gouvernance dans un compte plateforme. EventBridge Pipes fournit des flux point à point configurables depuis des sources d’événements (SQS, Kinesis, DynamoDB Streams, Apache Kafka auto-géré sur Amazon MSK, et autres) vers des cibles avec filtrage, traitement par lots, transformation et enrichissement intégrés via Lambda ou Step Functions — idéal lorsque vous ne souhaitez pas gérer une application de consommation complète mais avez besoin d’une médiation légère. EventBridge Scheduler fournit des planifications uniques et cron pour invoquer des cibles avec un rôle d’exécution, la prise en charge des fuseaux horaires et des fenêtres temporelles flexibles optionnelles pour réduire les effets de troupeau (thundering herds).

AWS Step Functions orchestre des workflows distribués définis en Amazon States Language avec des états pour Task, Choice, Parallel, Map (y compris le Map distribué), Wait, Pass, Succeed/Fail, et des patterns robustes de Retry/Catch. Des intégrations de service profondes suppriment le besoin de code de liaison pour appeler les API AWS, y compris les patterns synchrones (.sync) et de rappel (callback) avec des jetons de tâche. Choisissez les Workflows Standard pour une orchestration de longue durée, nécessitant un audit poussé, avec une progression d’état exactement une fois, une durée pouvant atteindre un an et une tarification par transition d’état ; l’historique d’exécution est conservé, avec une forte visibilité et des traces X-Ray intégrées. Choisissez les Workflows Express pour des orchestrations à haut débit et de courte durée (de quelques secondes à quelques minutes) où vous pouvez échanger une tarification par requête + durée et une sémantique d’exécution au moins une fois contre une mise à l’échelle massive ; à utiliser pour les enrichissements d’ingestion en streaming, les routeurs d’événements et les micro-orchestrations où vous pouvez rendre les tâches idempotentes. Appliquez des patterns comme le saga avec des tâches de compensation et une gestion centralisée des erreurs ; externalisez les nouvelles tentatives (retries)/délais d’attente (timeouts) dans la machine à états pour simplifier le code des tâches.

Déclencheurs de Calcul et Contre-pression : Mappages de Sources d’Événements Lambda

Les mappages de sources d’événements (ESM) Lambda connectent des sources basées sur l’interrogation (polling) à Lambda et contrôlent la concurrence, le traitement par lots et la gestion des erreurs.

• SQS : Lambda se met à l’échelle horizontalement en interrogeant la file d’attente et en invoquant votre fonction avec des lots (jusqu’à 10 messages ; fenêtre de traitement par lots maximale jusqu’à 300 secondes). Avec les files d’attente Standard, la mise à l’échelle est agressive en fonction de la profondeur et du débit de messages ; avec les files FIFO, Lambda préserve l’ordre par groupe de messages et traite un lot par groupe à la fois. Configurez la concurrence maximale sur l’ESM pour plafonner la mise à l’échelle des workers et protéger les systèmes en aval ; combinez-la avec la concurrence réservée/provisionnée pour garantir la capacité. Utilisez la réponse de lot partielle pour n’acquitter que les enregistrements réussis et remettre en file d’attente ceux qui ont échoué, évitant ainsi la relecture de l’ensemble du lot. Réglez le délai de visibilité de la file d’attente pour qu’il dépasse le total des nouvelles tentatives dans le pire des cas. Les DLQ et les politiques de redrive isolent les messages empoisonnés.

• Kinesis Data Streams : Une invocation Lambda concurrente par fragment (shard) par défaut garantit l’ordre par fragment. Augmentez le ParallelizationFactor jusqu’à 10 pour traiter plusieurs lots par fragment simultanément lorsque l’ordre entre les sous-séquences n’est pas une contrainte. Une taille de lot allant jusqu’à 10 000 enregistrements (6 Mo) et une fenêtre de traitement par lots maximale de 5 minutes vous permettent d’amortir les coûts et d’augmenter le débit. Utilisez la bissection en cas d’erreur de fonction pour rechercher par dichotomie les enregistrements défectueux dans un lot et les destinations en cas d’échec ou le nombre maximal de tentatives/l’âge maximal des enregistrements pour rejeter ou router les enregistrements non traitables. Surveillez IteratorAge pour détecter le retard du consommateur et re-fragmenter ou augmenter la parallélisation en conséquence.

• DynamoDB Streams : Similaire à Kinesis en termes de sémantique ; taille de lot jusqu’à 1 000 enregistrements (6 Mo) et modèle de fragment par clé de partition. Les consommateurs reçoivent les mutations ordonnées au niveau de l’élément (INSERT, MODIFY, REMOVE). Appliquez la même gestion des échecs (bissection en cas d’erreur, nombre maximal de tentatives, âge de l’enregistrement) et le même filtrage. Utilisez le type de vue de flux qui inclut les attributs dont votre consommateur a besoin (NewImage, OldImage, NewAndOldImages, ou KeysOnly) pour optimiser la taille de la charge utile (payload).

Le filtrage d’événements dans les ESM réduit les invocations en ignorant les événements non pertinents au niveau du poller. Utilisez l’agrégation par fenêtres basculantes (tumbling window) sur les flux avec Lambda pour agréger les enregistrements dans le temps pour des patterns de traitement par mini-lots.

Automatisation des opérations et remédiation : Systems Manager Automation et OpsCenter

AWS Systems Manager Automation fournit des runbooks (documents de type Automation) écrits en JSON/YAML avec des étapes telles que aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack et aws:executeAutomation. Les automatisations acceptent des paramètres, émettent des sorties, sont versionnées avec un historique des modifications et s’exécutent avec un rôle AutomationAssumeRole dédié pour le moindre privilège et les opérations inter-comptes/inter-régions. Contrôlez la simultanéité et les seuils d’erreur sur l’ensemble des flottes, exigez des approbations et des fenêtres Change Calendar, et intégrez-vous aux notifications via SNS. Invoquez des automatisations selon un calendrier, à partir de règles EventBridge (pour une remédiation quasi en temps réel sur les événements AWS Health, CloudWatch ou API), à partir des remédiations AWS Config pour appliquer une politique (par exemple, l’application de balises par défaut aux volumes EBS ou l’attachement d’un profil d’instance par défaut aux instances EC2), et depuis OpsCenter.

OpsCenter agrège les problèmes opérationnels dans des OpsItems à partir d’alarmes CloudWatch, d’AWS Config, d’événements Health ou de sources personnalisées. Chaque OpsItem suit le statut, la priorité, la déduplication, les ressources associées et les liens vers les runbooks. Associez des runbooks en un clic pour les correctifs standards et activez la remédiation automatique en reliant des règles EventBridge ou Config pour démarrer une Automation spécifique lorsqu’un OpsItem est créé ou mis à jour avec une condition correspondante (par exemple, un groupe de sécurité autorisant 0.0.0.0/0 sur SSH, une dérive de la conformité des correctifs ou des sauvegardes échouées). Utilisez Systems Manager Explorer pour visualiser la santé de la flotte et les OpsItems ouverts sur plusieurs comptes et régions. Cette association — les OpsItems en tant qu’enregistrements durables et les runbooks Automation en tant que correctifs codifiés — permet des opérations auditables et cohérentes à grande échelle.

Conception et Recommandations Opérationnelles

Concevez pour l’idempotence sur tous les consommateurs car la livraison au moins une fois est courante. Préférez le fan-out événementiel via SNS ou les règles EventBridge pour des réactions parallèles à faible latence ; préférez SQS pour mettre en mémoire tampon les charges de travail et protéger les producteurs de la lenteur des consommateurs ; préférez Kinesis lorsque l’ordre strict par partition et des flux rejouables sont requis pour l’analytique. Utilisez EventBridge Pipes pour une intégration légère et gérée entre les sources et les cibles lorsqu’un consommateur sur mesure est excessif, et EventBridge Scheduler pour des déclencheurs temporels sans maintenir d’infrastructure cron.

Dimensionnez correctement les délais d’attente et les tentatives. Pour SQS, le délai de visibilité doit dépasser le temps de traitement maximal plus les tentatives ; pour les flux, limitez les tentatives et définissez

undefined

pour éviter de rejouer sans fin les enregistrements défectueux. Utilisez systématiquement des DLQ ou des destinations en cas d’échec et ajoutez des tableaux de bord et des alarmes sur SQS

undefined

, Lambda

undefined

,

undefined

, Step Functions

undefined

, et EventBridge

undefined

. Lorsque le trafic en pics est inévitable mais que les SLA de latence sont stricts, utilisez la concurrence provisionnée de Lambda pour préchauffer la capacité. Pour la gouvernance, préférez EventBridge avec des politiques de ressources pour le routage inter-comptes et l’archivage/relecture afin de supporter l’évolution des consommateurs et la reprise après incident.

Scénario de Problème Pratique

Shopify doit moderniser le traitement des commandes pour les événements de ventes flash tout en ajoutant de l’analytique en temps réel et une remédiation automatisée lorsque les services en aval ralentissent ou échouent.

1. Ingérer et diffuser les événements de commande

• Utiliser un sujet SNS FIFO pour publier les événements

undefined

depuis le processus de paiement, garantissant des notifications ordonnées et dédupliquées par

undefined

. Les abonnements incluent :

• Une file d’attente SQS FIFO (Order-Workers) pour l’exécution des commandes, en préservant l’ordre.
• Un bus d’événements personnalisé EventBridge (CommerceBus) pour la gouvernance et le routage additionnel.
• Un flux de livraison Kinesis Data Firehose pour la livraison en quasi temps réel des commandes vers S3 avec compression GZIP pour l’analytique. Pourquoi SNS FIFO : Il fournit une sémantique ordonnée de type exactly-once avec un fan-out scalable vers de multiples abonnés sans coupler les publicateurs aux consommateurs.

2. Mettre en tampon et traiter l’exécution des commandes

• Lambda consomme depuis la file d’attente SQS FIFO via un mappage de source d’événement avec une taille de lot de 10, la réponse partielle de lot activée, et une concurrence maximale plafonnée pour protéger les API des entrepôts en aval. Le délai de visibilité de la file est fixé à six fois le timeout de la Lambda pour accommoder les tentatives. Une DLQ capture les messages empoisonnés avec

undefined

; un workflow de redrive retraite ultérieurement les messages corrigés. Pourquoi SQS FIFO + Lambda ESM : Garantit le séquencement par commande, isole la lenteur en aval grâce à la mise en tampon, et offre une gestion fine des erreurs.

3. Orchestrer une saga multi-étapes

• Un workflow Step Functions Standard orchestre la capture du paiement, la réservation de l’inventaire, la détection de la fraude et la réservation de l’expédition avec des tentatives, des timeouts et des tâches de compensation (remboursement, réapprovisionnement) sur les chemins d’échec. La première tâche est déclenchée par une Lambda invoquée depuis le consommateur SQS. Pourquoi Standard : Progression d’état de longue durée, auditable, de type exactly-once à travers des systèmes externes avec une gestion d’erreurs riche.

4. Router les événements de domaine vers les capacités

• Le CommerceBus reçoit les événements

undefined

via

undefined

depuis les services producteurs et depuis l’abonnement SNS. Règles EventBridge :

• Correspondent à

undefined

pour notifier le Marketing (Lambda) et créer un ticket de support (intégration API AWS Support) lorsque des clients à forte valeur commandent.

• Transfèrent

undefined

vers le bus d’événements d’un compte d’opérations central en utilisant une politique de ressources pour la gouvernance inter-comptes. Pourquoi EventBridge : Routage centralisé, filtrage, livraison inter-comptes, et la capacité d’ajouter de nouveaux consommateurs sans modifier les producteurs.

5. Connecter (Pipe) le flux d’un partenaire pour l’enrichissement

• EventBridge Pipes connecte une file d’attente SQS Standard d’un partenaire (SKU en rupture de stock) à un workflow Step Functions Express qui enrichit les articles via une fonction Lambda et pousse les résultats vers une file d’attente SQS interne pour le réapprovisionnement. Pourquoi Pipes + Express : Intégration gérée à faible surcharge avec un enrichissement léger à haut débit et faible coût.

6. Analytique et recherche en temps réel

• Un Kinesis Data Stream collecte le clickstream et les événements opérationnels. Lambda (consommateur Enhanced Fan-Out) effectue la sessionisation, et Kinesis Data Analytics agrège les KPI. Firehose livre les commandes transformées et les analyses au data lake S3 et à Amazon OpenSearch Service avec un partitionnement dynamique par date/marché pour des requêtes efficaces. Pourquoi Streams + Firehose : Traitement ordonné à faible latence pour l’analytique, avec livraison et transformation gérées vers le stockage et la recherche.

7. Automatisation temporelle

• EventBridge Scheduler exécute un cron chaque minute pour publier

undefined

sur CommerceBus, déclenchant un workflow Step Functions Express qui compile des instantanés à travers les entrepôts pour une précision des stocks en quasi temps réel. Pourquoi Scheduler : Cron natif et résilient sans infrastructure personnalisée.

8. Remédiation et opérations automatisées

• Des règles AWS Config détectent les ports SSH ouverts ou les ACL S3 publiques dans les VPC d’exécution des commandes. Des remédiations gérées invoquent des runbooks Systems Manager Automation pour corriger la dérive. Des alarmes CloudWatch sur SQS

undefined

et Lambda

undefined

créent des OpsItems dans OpsCenter ; des runbooks associés augmentent la concurrence provisionnée sur des Lambdas spécifiques, augmentent la capacité réservée de Step Functions, ou élargissent temporairement les fenêtres de traitement par lot. Une règle EventBridge sur les événements de maintenance EC2 d’AWS Health cible un document SSM Automation pour redémarrer les instances impactées de manière contrôlée pendant les fenêtres de maintenance. Pourquoi OpsCenter + Automation : Suivi des problèmes centralisé et auditable avec des remédiations en un clic ou automatiques, basées sur le moindre privilège, qui s’exécutent en toute sécurité sur plusieurs comptes/régions.

Cette conception soutient les pics des ventes flash grâce à la mise en tampon et au fan-out, préserve les invariants métier via l’orchestration, fournit des analyses en quelques secondes, et boucle la boucle avec une remédiation automatisée et pilotée par des politiques.

← Haute disponibilité · Tous les domaines · Stockage →

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

Parcourir Amazon →