Amazon SAA-C03: Intégration d'applications, messagerie et streaming — 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.

Amazon SQS : Découplage, Ordre et Sémantique de Livraison

Amazon SQS est une file d’attente de messages entièrement gérée et basée sur le mode pull dont le rôle architectural principal est de découpler les producteurs des consommateurs. Une chaîne d’appels synchrone lie la latence et la disponibilité du producteur à chaque dépendance en aval ; l’insertion d’une file d’attente SQS transforme cela en un transfert asynchrone. Les producteurs ajoutent des messages au rythme où le trafic arrive, et les consommateurs les retirent au rythme où ils peuvent les traiter en toute sécurité. C’est la solution classique pour les pics d’écriture qui, autrement, surchargeraient une instance RDS — la file d’attente absorbe le pic, et une flotte limitée de consommateurs la vide avec une simultanéité contrôlée, maintenant le nombre de connexions à la base de données sous contrôle.

Il existe deux types de files d’attente, et le choix détermine à la fois le débit et les garanties de livraison.

Les files d’attente standard livrent les messages au moins une fois avec un ordre au mieux. Des doublons peuvent apparaître lorsqu’un consommateur ne parvient pas à supprimer un message avant l’expiration du délai de visibilité, ou lorsque le backend distribué rejoue un message à travers les partitions (shards). Même si vous ne voyez jamais de doublon lors des tests, le service est architecturalement autorisé à effectuer une nouvelle livraison, en particulier lors du basculement d’un broker. Supposer que les files d’attente standard livreront « habituellement » une seule fois est un défaut de conception, pas un risque opérationnel — il est garanti que des doublons se produiront à grande échelle. La logique du consommateur doit donc être idempotente : suivre un MessageId ou une clé métier dans DynamoDB avec une écriture conditionnelle, utiliser une clé d’idempotence sur les appels d’API en aval, ou s’appuyer sur une sémantique d’upsert.

Les files d’attente FIFO fournissent un ordre strict au sein d’un MessageGroupId et un traitement exactement unique via un MessageDeduplicationId (explicite ou un SHA-256 du corps du message) qui supprime les doublons pendant une fenêtre de 5 minutes. Le MessageGroupId est le concept central : tous les messages partageant un ID de groupe sont livrés strictement dans l’ordre à un seul consommateur à la fois, tandis que différents ID de groupe peuvent être traités en parallèle. Pour un système de traitement de commandes où les événements de chaque client doivent être séquentiels mais où les différents clients sont indépendants, utilisez MessageGroupId = customerId. Utiliser un seul ID de groupe pour tout sérialise l’ensemble de la charge de travail et anéantit le débit. Les ID de déduplication sont la primitive correcte pour empêcher la création de commandes en double lorsqu’un utilisateur soumet à nouveau un paiement bloqué : le client génère un jeton d’idempotence déterministe (un UUID lié à la session de paiement) et SQS rejette toute soumission en double arrivant dans la fenêtre de temps.

PaymentsQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: payments.fifo
    FifoQueue: true
    ContentBasedDeduplication: true
    DeduplicationScope: messageGroup
    FifoThroughputLimit: perMessageGroupId
    VisibilityTimeout: 60
    RedrivePolicy:
      deadLetterTargetArn: !GetAtt PaymentsDLQ.Arn
      maxReceiveCount: 5

Sélectionner une file standard lorsque les exigences spécifient « ordre » ou « pas de doublons » est l’erreur classique. Aucune logique applicative ne peut restaurer un ordre que la file d’attente n’a jamais préservé, car les messages provenant de différents hôtes du backend arrivent de manière entrelacée. Choisissez FIFO chaque fois que la charge de travail exige un ordre (registres de transactions, transitions de machine à états) ou une sémantique de traitement unique (capture de paiement, décrémentation d’inventaire).

Délai de Visibilité, Messages Empoisonnés et Limites de Charge Utile

Lorsqu’un consommateur reçoit un message, SQS le rend invisible aux autres consommateurs pendant le délai de visibilité (par défaut 30 secondes, max 12 heures). Si le consommateur supprime le message avant l’expiration du délai, il disparaît ; sinon — parce que le consommateur a planté, ou que le traitement a simplement pris trop de temps — le message réapparaît et est livré à nouveau. Définir un délai de visibilité plus court que le temps de traitement réel est une cause majeure de traitement en double : une fonction Lambda prenant 45 secondes pour traiter un message d’une file avec le délai par défaut de 30 secondes retraitera chaque message au moins deux fois. Réglez le délai de visibilité à au moins le temps de traitement p99 (la recommandation d’AWS pour les files d’attente pilotées par Lambda est d’au moins 6 fois le timeout de la fonction), et pour les tâches de durée imprévisible, prolongez le délai de manière dynamique :

sqs.change_message_visibility(
    QueueUrl=queue_url,
    ReceiptHandle=handle,
    VisibilityTimeout=300  # extend by 5 minutes
)

Les files de lettres mortes (DLQ) capturent les messages empoisonnés (poison pills). Une RedrivePolicy sur la file d’attente source spécifie un maxReceiveCount (généralement 3 à 5) ; une fois ce seuil dépassé, SQS déplace le message vers la DLQ pour une inspection hors ligne. La DLQ doit être du même type que la file d’attente source (FIFO ↔ FIFO). Sans DLQ, les messages malformés bouclent indéfiniment, et dans une file FIFO, c’est particulièrement dommageable — le respect de l’ordre empêche la livraison des messages suivants du même groupe jusqu’à ce que le message problématique soit traité, donc un seul mauvais message bloque tout un groupe.

Les messages SQS sont limités à 256 Ko. Pour les charges utiles plus volumineuses — par exemple, une tâche transportant un document rendu — utilisez la bibliothèque cliente étendue SQS (SQS Extended Client Library), qui écrit la charge utile dans S3 et ne met en file d’attente qu’une référence au bucket/à la clé. La bibliothèque du consommateur récupère la charge utile de manière transparente à la réception. Ne divisez pas les charges utiles sur plusieurs messages (vous perdez l’atomicité et l’ordre) et n’encodez pas en base64 un blob de 2 Mo en espérant qu’il passe.

Mise à l’Échelle Automatique Pilotée par la File d’Attente

Pour une flotte de consommateurs sur EC2 ou ECS derrière une file d’attente SQS, le bon signal de mise à l’échelle n’est pas le CPU — c’est le backlog de la file d’attente. Le CPU est en retard sur le taux d’arrivée et interprète à tort un consommateur saturé comme étant « occupé mais gérant la charge ». La métrique de mise à l’échelle canonique est ApproximateNumberOfMessagesVisible, mais une mise à l’échelle directe sur la profondeur brute de la file est imprécise. L’approche recommandée est la métrique personnalisée de backlog par instance :

backlogPerInstance = ApproximateNumberOfMessagesVisible / RunningInstances

Publiez cette métrique sur CloudWatch et pilotez une politique de suivi de cible (target tracking) sur un groupe Auto Scaling ou un service ECS afin que chaque worker maintienne un backlog limité (par exemple, 10 messages). Cela permet un scale-out fluide pendant les pics et empêche l’oscillation lorsque la profondeur de la file est faible mais que les consommateurs sont déjà saturés. Pour le scale-in, associez-la à ApproximateAgeOfOldestMessage pour éviter de supprimer de la capacité alors que des messages anciens persistent.

Amazon SNS : Fan-Out, Filtrage et Livraison Inter-Comptes

SNS est un service de publication/abonnement (pub/sub) basé sur le mode push. Les publicateurs écrivent dans un topic ; SNS envoie (push) à chaque abonnement : files d’attente SQS, fonctions Lambda, points de terminaison HTTP(S), e-mails, SMS, Kinesis Data Firehose ou notifications push mobiles. Le modèle de durabilité dominant est le fan-out SNS → SQS : un topic avec plusieurs files d’attente SQS abonnées, de sorte que chaque service en aval dispose de son propre tampon durable, de sa politique de nouvelle tentative et de sa DLQ, tandis que le publicateur ne connaît que le topic. Si un service consommateur tombe en panne pendant des heures, sa file d’attente accumule les messages et se vide lors de la reprise — SNS seul ne dispose pas de cette mise en mémoire tampon et épuisera sa politique de nouvelle tentative.

Producer ──▶ SNS topic ──┬──▶ SQS Queue A ──▶ Service A
                         ├──▶ SQS Queue B ──▶ Service B
                         └──▶ SQS Queue C ──▶ Service C

Le filtrage des messages permet à chaque abonnement de déclarer une politique de filtrage JSON afin que SNS ne livre que les messages correspondants, évitant l’anti-modèle où chaque consommateur reçoit chaque message et filtre côté client :

{
  "eventType": ["order_placed", "order_cancelled"],
  "region": ["us-east-1", "us-west-2"]
}

Deux propriétés comportementales sont importantes. Premièrement, les topics SNS standard ne garantissent pas l’ordre des messages — les temporisateurs de nouvelle tentative par abonné et les chemins réseau indépendants rendent la réorganisation courante. Si l’ordre est important, utilisez un topic SNS FIFO abonné à des files d’attente SQS FIFO ; l’ID du groupe de messages se propage de bout en bout. Sinon, les abonnés doivent être idempotents et tolérants à la réorganisation. Deuxièmement, les abonnements HTTP(S) effectuent des nouvelles tentatives selon une politique de livraison (par défaut : trois nouvelles tentatives immédiates, puis un backoff exponentiel jusqu’à une heure, puis suppression). Les abonnés doivent répondre avec un code 2xx en 15 secondes, valider la signature x-amz-sns-message-type, et — pour les points de terminaison non fiables — toujours avoir une DLQ SNS (redirigée vers SQS) afin que les messages non livrés soient capturés plutôt que silencieusement abandonnés.

L’invocation inter-comptes est un piège fréquent. Lorsque le Compte A publie dans un topic qui distribue (fan-out) à une fonction Lambda dans le Compte B, deux politiques sont nécessaires : la politique du topic SNS (ou la direction de l’abonnement) doit autoriser l’abonnement, et la politique basée sur les ressources de la Lambda doit autoriser lambda:InvokeFunction depuis sns.amazonaws.com avec une condition SourceArn correspondant au topic. L’absence de la politique de ressource Lambda est le mode d’échec le plus courant — l’abonnement semble sain, mais les invocations sont rejetées avec une erreur 403. Si le topic est chiffré avec une clé KMS gérée par le client, la politique de la clé doit également accorder kms:Decrypt et kms:GenerateDataKey au principal qui publie et à sns.amazonaws.com.

{
  "Effect": "Allow",
  "Principal": {"Service": "sns.amazonaws.com"},
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:222222222222:function:ProcessOrder",
  "Condition": {"ArnLike": {"AWS:SourceArn": "arn:aws:sns:us-east-1:111111111111:orders"}}
}

Amazon EventBridge : Bus d’Événements Routés

EventBridge (anciennement CloudWatch Events) étend le modèle pub/sub avec un routage basé sur le contenu, la découverte de schémas, des sources d’événements de partenaires SaaS, et l’archivage/relecture. Les événements transitent par des bus d’événements (par défaut, personnalisés ou partenaires) et sont comparés à des règles dont les modèles d’événements (event patterns) filtrent sur la structure JSON. Les règles peuvent transformer les charges utiles (payloads) via des chemins d’entrée (input paths) et des modèles d’entrée (input templates), attacher des cibles de lettres mortes (dead-letter targets), et livrer à plus de 20 cibles natives, y compris Lambda, Step Functions, tâches ECS, SQS, SNS, Kinesis et API destinations.

{
  "source": ["com.acme.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {"amount": [{"numeric": [">", 500]}]}
}

La distinction avec SNS est d’ordre architectural. SNS est optimisé pour la diffusion à haut débit (broadcast) vers des abonnés homogènes avec un filtrage simple par attributs et une latence plus faible. EventBridge est optimisé pour les architectures hétérogènes pilotées par les événements : de nombreux producteurs émettent des schémas d’événements différents, et les consommateurs s’abonnent par modèle (pattern) plutôt que par topic. Pour un monolithe en cours de décomposition en microservices — surtout lorsque les producteurs incluent des partenaires SaaS ou des services AWS (Config, GuardDuty, CodePipeline, CloudTrail) qui émettent nativement des événements — EventBridge est généralement le bon choix. Pour un fan-out à très haut volume et faible latence vers des abonnés identiques, SNS reste gagnant car EventBridge a une latence par événement légèrement plus élevée et un plafond de débit par défaut plus bas.

Amazon MQ : Messagerie à base de Broker pour les Protocoles Existants

Amazon MQ est un broker géré exécutant ActiveMQ ou RabbitMQ. Il a pour but de migrer des charges de travail on-premises qui dépendent de AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, OpenWire, ou JMS sans réécrire l’application. Si un système de paiement utilise un broker JMS tiers avec une sémantique transactionnelle de type “exactly-once”, le migrer vers Amazon MQ préserve le protocole filaire (wire protocol) et les garanties de livraison tout en éliminant la gestion de l’infrastructure. Choisissez SQS/SNS/EventBridge pour les nouvelles conceptions natives AWS (greenfield) ; ne choisissez Amazon MQ que lorsque la compatibilité protocolaire est la contrainte.

Kinesis Data Streams

Kinesis Data Streams (KDS) est un journal (log) durable, ordonné et partitionné pour l’ingestion de flux à haut débit — flux de clics (clickstreams), télémétrie IoT, agrégation de logs. Les enregistrements (records) sont placés dans des partitions (shards) par PartitionKey ; l’ordre est garanti au sein d’une partition, mais pas à travers tout le flux. Chaque partition supporte 1 Mo/s ou 1 000 enregistrements/s en écriture et 2 Mo/s en lecture (ou plus avec l’Enhanced Fan-Out). Les enregistrements sont conservés 24 heures par défaut, extensible jusqu’à 365 jours, afin que plusieurs consommateurs indépendants puissent relire le même historique — ce que SQS ne peut pas faire car SQS supprime après acquittement (ack).

Le mode à la demande (on-demand) élimine le calcul des partitions en scalant automatiquement jusqu’à 200 Mio/s en écriture par flux, idéal pour un trafic imprévisible. Le mode provisionné est moins cher pour un état stable où la capacité est connue.

Choisissez KDS plutôt que SQS FIFO lorsque la charge de travail exige une ingestion ordonnée et rejouable à des débits que FIFO ne peut pas supporter (FIFO plafonne bien en dessous des millions d’enregistrements/seconde que KDS gère), lorsque plusieurs consommateurs indépendants doivent lire le même flux, ou lorsque la formulation “préserver l’ordre original tout au long du traitement” est associée à un volume élevé.

Kinesis Data Firehose

Kinesis Data Firehose est un service de livraison entièrement géré. Il lit depuis un flux Kinesis ou par des appels PUT directs, met en mémoire tampon par taille (1–128 Mo) ou par temps (60–900 secondes, selon la première limite atteinte), invoque optionnellement une fonction Lambda pour la transformation de chaque enregistrement (nettoyage des PII, normalisation du format), peut convertir le JSON en Parquet ou ORC à la volée en utilisant un schéma Glue, chiffre avec KMS, et livre à S3, Redshift, OpenSearch ou Splunk. Il n’a pas de partitions (shards), pas de consommateurs à exécuter, et une tarification au Go.

Le modèle canonique pour une ingestion évolutive dans un data lake associe Data Streams (en mode on-demand) comme tampon durable avec Firehose pour la livraison vers S3 :

Producers → Kinesis Data Streams (on-demand) → Firehose (60s buffer, Parquet) → S3 → Athena/Glue

Pour ingérer des millions d’événements mobiles, les chiffrer et les déposer dans S3 au format Parquet, la bonne réponse est Firehose avec la conversion Parquet et une clé KMS — et non KDS plus un consommateur personnalisé plus un rédacteur Parquet écrit à la main, ce qui représente beaucoup plus de code et d’infrastructure. Firehose fonctionne en quasi-temps réel et ne prend pas en charge la relecture côté consommateur ; lorsque la relecture est nécessaire, conservez KDS dans le cheminement.

Kinesis Data Analytics (maintenant Managed Service for Apache Flink) exécute des tâches SQL ou Flink sur un flux pour des agrégations fenêtrées.

Intégration Lambda et Sémantiques de Nouvelle Tentative

Lambda s’intègre avec ces services avec des comportements de nouvelle tentative matériellement différents :

Pour SQS, maintenez le délai d’expiration (timeout) de la fonction Lambda ≤ au délai de visibilité de la file d’attente, et configurez le délai de visibilité à au moins 6 fois le timeout de la fonction. Pour Kinesis, activez BisectBatchOnFunctionError et configurez une destination OnFailure (SQS ou SNS) pour qu’un seul enregistrement empoisonné ne bloque pas indéfiniment toute la partition (shard).

Tableau de Décision pour la Sélection

← Analytique · Tous les domaines · Sécurité →

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

Parcourir Amazon →