Amazon DVA-C02: Messagerie, Streaming et Architectures événementielles (SNS, SQS, Kinesis, EventBridge, Step Functions) — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-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.

Choisir la bonne primitive de messagerie et de streaming

Le choix entre SNS, SQS (standard vs FIFO), Kinesis, EventBridge et Step Functions commence par le modèle de communication : publication/abonnement (pub/sub), point à point, streaming ordonné, routage par bus d’événements ou orchestration de flux de travail. SNS est un éditeur pub/sub à diffusion (fan-out) ; utilisez Publish (appel SDK : Publish/PublishBatch) et abonnez des points de terminaison SQS, Lambda, HTTP/S ou mobiles. SQS est un tampon point à point durable avec une sémantique ReceiveMessage/DeleteMessage ; créez des files d’attente avec CreateQueue et des attributs comme VisibilityTimeout, ReceiveMessageWaitTimeSeconds (interrogation longue), MessageRetentionPeriod, et des politiques de redirection (redrive policies) liant une file de lettres mortes (DLQ). Les files d’attente FIFO nécessitent FifoQueue=true et utilisent MessageGroupId ainsi que MessageDeduplicationId (ou ContentBasedDeduplication) pour l’ordonnancement et le dédoublonnage. Kinesis Data Streams est un service de streaming ordonné basé sur des shards ; les producteurs appellent PutRecord/PutRecords et les consommateurs utilisent GetShardIterator (TRIM_HORIZON, LATEST, AT_SEQUENCE_NUMBER) puis GetRecords. Kinesis Firehose gère la livraison vers S3/Redshift/OpenSearch et offre des BufferingHints (SizeInMBs, IntervalInSeconds) et des transformations Lambda. EventBridge route des événements avec PutEvents et un filtrage basé sur des règles, prend en charge un registre de schémas et des bus inter-comptes. Step Functions orchestre des flux complexes ; StartExecution (Standard) ou StartSyncExecution pour les modèles Express synchrones, avec des intégrations de tâches comme arn:aws:states:::lambda:invoke. Tenez compte de ces compromis lorsque le débit, l’ordonnancement, les garanties de livraison, la rétention et les besoins d’orchestration entrent en conflit.

• SNS : diffusion (fan-out) à haut débit, pas d’ordonnancement, Publish/Subscribe, utilisez MessageAttributes pour le routage.
• SQS Standard : au moins une fois (at-least-once), ordre au mieux (best-effort), interrogation longue (long polling), moins cher pour le découplage.
• SQS FIFO : ordre exact une seule fois au sein d’un MessageGroupId, à utiliser pour un ordonnancement strict et le dédoublonnage.
• Kinesis Data Streams : ordonné par shard, streaming à haut débit, PutRecord/PutRecords, mise à l’échelle des shards requise.
• Kinesis Firehose : livraison et mise en mémoire tampon gérées, prend en charge le chiffrement côté serveur et les transformations Lambda.
• EventBridge : bus d’événements avec règles de routage, registre de schémas, archivage et relecture, API PutEvents.
• Step Functions : orchestration avec état (stateful), nouvelles tentatives/Catch, compromis Standard vs Express pour la durabilité et le débit.

Patrons SQS et SNS, dédoublonnage et mise à l’échelle des consommateurs

Lorsque vous avez besoin d’un découplage durable, SQS est le choix par excellence ; implémentez SendMessage/SendMessageBatch pour les producteurs et utilisez ReceiveMessage avec WaitTimeSeconds pour activer l’interrogation longue (long polling) et réduire les réceptions vides. Pour un ordonnancement et un dédoublonnage stricts, créez une file d’attente FIFO avec CreateQueue (FifoQueue=true) et définissez un MessageGroupId pour les partitions ordonnées ; utilisez MessageDeduplicationId ou activez ContentBasedDeduplication pour que les charges utiles identiques dans la fenêtre de dédoublonnage soient supprimées. Les files d’attente standard peuvent livrer des doublons — rendez donc les consommateurs idempotents via des écritures conditionnelles en base de données (PutItem sur DynamoDB avec ConditionExpression attribute_not_exists(pk)) ou des contraintes d’unicité et des opérations d’upsert dans des transactions RDS. Configurez des politiques de redirection (redrive policies) pour router les messages en échec vers une DLQ après maxReceiveCount ; surveillez ApproximateNumberOfMessages et ApproximateNumberOfMessagesNotVisible via GetQueueAttributes. Les intégrations Lambda utilisent CreateEventSourceMapping pour SQS : définissez BatchSize, MaximumBatchingWindowInSeconds, et activez FunctionResponseTypes = [“ReportBatchItemFailures”] pour utiliser la sémantique de réponse partielle de lot et éviter de retraiter les enregistrements réussis. Attention à la sémantique FIFO avec Lambda : l’ordre des groupes de messages impose un traitement monothread par MessageGroupId, limitant la concurrence par groupe ; mettez à l’échelle en partitionnant en de nombreux ID de groupe ou en utilisant des consommateurs parallèles avec SNS vers plusieurs files d’attente. Gardez également à l’esprit le délai de visibilité (visibility timeout) : définissez ChangeMessageVisibility lorsque le traitement prend plus de temps ou vous risquez un traitement en double.

Kinesis Data Streams et Firehose : ordonnancement, rétention et gestion de la contre-pression

Kinesis Data Streams fournit un ordonnancement par shard et une rétention durable pour les cas d’usage de streaming. Les producteurs appellent PutRecord ou PutRecords (en lot) avec une PartitionKey qui est mappée à un shard ; les consommateurs appellent GetShardIterator et GetRecords, puis enregistrent les décalages (offsets) via un checkpoint en utilisant la KCL (Kinesis Client Library) ou une table de checkpoint DynamoDB personnalisée. La rétention par défaut est de 24 heures (ajustable à des fenêtres plus longues par configuration de flux, et des fonctionnalités de rétention étendue là où elles sont disponibles) ; planifiez le nombre de shards avec UpdateShardCount pour correspondre au débit d’écriture et au parallélisme des lecteurs. La mise à l’échelle des consommateurs est limitée : un seul mappage de source d’événement Lambda associe un shard à une seule instance concurrente de Lambda. Pour augmenter la concurrence des consommateurs, augmentez le nombre de shards ou activez la diffusion améliorée (enhanced fan-out) pour donner à chaque consommateur son propre canal de 2 Mo/s et une mise à l’échelle indépendante en utilisant l’API SubscribeToShard (enregistrement du consommateur). Utilisez PutRecords pour un traitement par lots efficace ; la contre-pression (back-pressure) survient lorsque les consommateurs prennent du retard (surveillez GetRecords.IteratorAgeMilliseconds). Pour gérer les pics, mettez en mémoire tampon sur Kinesis ou placez SQS en amont, utilisez des nouvelles tentatives côté producteur avec un intervalle exponentiel (exponential backoff), et utilisez le chiffrement au niveau du flux avec KMS pour les données personnelles (PII). Kinesis Data Firehose simplifie la livraison : configurez les BufferingHints (SizeInMBs, IntervalInSeconds), le CompressionFormat, et une transformation de données Lambda. Firehose gère les nouvelles tentatives/intervalles vers les destinations et peut écrire les enregistrements en échec dans un compartiment S3 de sauvegarde. Un piège courant est le sous-provisionnement des shards : les consommateurs sont en attente (starve) et des pics de latence apparaissent ; mesurez et mettez à l’échelle de manière proactive.

← Bases de données et Mise en cache (RDS · Tous les domaines

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

Parcourir Amazon →