Amazon SOA-C02: Serverless et intégration d'applications — 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.

Le sans serveur et l’intégration d’applications couvrent l’exécution d’applications événementielles sans gérer de serveurs et la connexion fiable des services. L’importance opérationnelle réside dans la gestion de la mise à l’échelle, de la latence, des modes de défaillance et de l’accès au moindre privilège, tout en maintenant des coûts prévisibles. Ce domaine se concentre sur le comportement de Lambda (démarrages à froid, simultanéité), la livraison fiable d’événements (EventBridge, SNS, SQS), les contrôles de sécurité (rôles d’exécution et autorisations) et l’observabilité des flux asynchrones.

Aspects opérationnels et simultanéité d’AWS Lambda

La performance et la disponibilité de Lambda dépendent des démarrages à froid, des limites de simultanéité et des contrôles de limitation (throttling). Les démarrages à froid se produisent lorsque Lambda doit initialiser un nouvel environnement d’exécution ; réduisez leur impact en utilisant la simultanéité provisionnée (

undefined

) pour les chemins critiques en termes de latence, et préférez des runtimes plus légers ou un travail d’initialisation plus réduit. Réservez et limitez la simultanéité avec la simultanéité réservée (

undefined

) pour protéger les services en aval et appliquer des quotas par fonction ; surveillez les métriques CloudWatch ConcurrentExecutions et Throttles.

Les modèles de nouvelle tentative et d’invocation diffèrent selon le mode : les appels synchrones (API Gateway, Invoke direct) retournent les erreurs immédiatement ; les appels asynchrones (EventBridge, SNS, notifications asynchrones S3) utilisent la politique de nouvelle tentative asynchrone de Lambda (deux tentatives avec backoff) et peuvent utiliser des DLQ ou des destinations. Pour les mappages de source d’événements (SQS, Kinesis, flux DynamoDB), le poller de Lambda réessaie jusqu’à ce que le message expire ou que la politique de redirection (redrive policy) de la source d’événements déclenche une lettre morte. Configurez le timeout et la mémoire de manière prudente (

undefined

) et définissez le délai de visibilité SQS > timeout de la fonction (recommandation : visibilité >= timeout de la fonction * 2) pour réduire les traitements en double.

Architectures événementielles avec EventBridge

EventBridge fournit un bus d’événements géré avec un routage flexible, un registre de schémas, une livraison inter-comptes et des paramètres de nouvelle tentative/DLQ. Utilisez des bus d’événements personnalisés pour la séparation des domaines et des bus d’événements partenaires pour les intégrations SaaS ; créez des règles avec des filtres (patterns) (

undefined

) et attachez des cibles avec une configuration de lettre morte et de nouvelle tentative (le JSON des cibles prend en charge DeadLetterConfig et RetryPolicy). Utilisez le registre de schémas pour découvrir et appliquer les formes d’événements ; enregistrez les schémas lorsque les producteurs sont bien définis, et utilisez les liaisons de code (Code Bindings) pour générer des modèles typés si utile.

Choisissez EventBridge lorsque vous avez besoin de :

• Routage et filtrage complexes avec des filtres d’événements (event patterns) riches ou une isolation inter-comptes/bus d’événements
• Prise en charge native de plusieurs cibles (Lambda, Step Functions, Kinesis, SQS, SNS)
• Découverte de schémas et gouvernance entre les équipes

Choisissez SNS/SQS en direct lorsque vous avez besoin d’une distribution (fan-out) plus simple ou d’une sémantique de file d’attente garantie :

• SNS pour la distribution (fan-out) à de nombreux abonnés et une sémantique push
• SQS pour un traitement durable basé sur l’extraction (pull) avec un délai de visibilité et des politiques de redirection (redrive policies)

Messagerie avec SNS et SQS (DLQ, délai de visibilité)

SNS est un service pub/sub en mode push ; SQS est une file d’attente durable avec une sémantique d’extraction (pull). Pour un traitement à haute fiabilité, préférez les schémas SNS -> SQS -> Lambda pour découpler l’ingestion du traitement et obtenir un contrôle sur les nouvelles tentatives et la visibilité. Configurez la politique de redirection (redrive policy) de SQS (

undefined

) pour déplacer les messages vers une DLQ après maxReceiveCount, et assurez-vous que le délai de visibilité est suffisamment long pour éviter une nouvelle livraison prématurée (recommandation : visibilité >= timeout de la fonction * 2). Pour les besoins FIFO, utilisez SQS FIFO ou SNS FIFO avec des ID de groupe de messages pour préserver l’ordre et des ID de déduplication pour éviter les doublons.

Options de gestion des lettres mortes et où les utiliser :

• Invocations asynchrones de Lambda : configurez DeadLetterConfig ou les Destinations (AsyncEventInvokeConfig) pour envoyer les échecs à SQS/SNS ou invoquer une autre Lambda.
• SQS : configurez la politique de redirection (redrive policy) vers une DLQ SQS pour les messages empoisonnés et définissez un maxReceiveCount approprié.
• EventBridge : définissez DeadLetterConfig et RetryPolicy sur les cibles des règles pour capturer les événements non livrables.

L’idempotence est essentielle : implémentez des gestionnaires idempotents en utilisant des écritures conditionnelles DynamoDB (PutItem avec ConditionExpression attribute_not_exists(pk)), des jetons d’idempotence stockés avec un TTL, ou la déduplication SQS FIFO pour une sémantique de traitement unique (exactly-once).

Autorisations de fonction, rôles et moindre privilège

Appliquez le moindre privilège aux rôles d’exécution Lambda et aux politiques de ressource de la fonction. Commencez avec AWSLambdaBasicExecutionRole pour les journaux CloudWatch Logs, puis accordez des ARN de ressources explicites pour les services (par ex., dynamodb:PutItem sur arn:aws:dynamodb:region:acct:table/MyTable). Évitez les caractères génériques comme Resource: “*” lorsque des ARN spécifiques sont possibles. Utilisez des politiques gérées ou personnalisées limitées par action et ressource, et incluez des conditions (aws:SourceAccount, aws:SourceArn) lors de l’ajout d’autorisations d’invocation pour les services :

• Ajouter une autorisation d’invocation pour EventBridge :

undefined

• Pour SNS : utilisez la condition source-arn pour limiter quel topic peut invoquer la fonction

Critères de décision :

• Utilisez des politiques basées sur les ressources de la fonction pour autoriser les invocations de service (EventBridge, SNS, CloudWatch Events)
• Utilisez le rôle d’exécution IAM pour les autorisations d’exécution (DynamoDB, S3, Secrets Manager)
• Préférez les autorisations au niveau des ressources et les contraintes conditionnelles pour réduire le rayon d’impact (blast radius)

Observabilité et dépannage pour le serverless

L’observabilité doit couvrir les métriques, les journaux (logs), les traces et le statut de livraison asynchrone. Métriques CloudWatch clés : Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (pour les déclencheurs de flux et SQS). Pour la visibilité des échecs asynchrones, surveillez les métriques “AsyncEventInvoke” et configurez des alarmes CloudWatch sur DeadLetterErrors et Throttles. Activez le traçage X-Ray (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) pour obtenir des traces de bout en bout à travers les services et visualiser les démarrages à froid (cold-starts), les latences en aval et les exceptions.

Utilisez des journaux JSON structurés et des requêtes CloudWatch Logs Insights pour trouver rapidement les schémas d’erreurs ; instrumentez les vérifications d’idempotence et enregistrez les ID de corrélation dans les journaux. Pour le traçage distribué, propagez explicitement les ID de trace dans les charges utiles (payloads) des événements pour les flux EventBridge/SNS si le contexte automatique est perdu. Pour les mappages de source d’événements SQS, surveillez ApproximateAgeOfOldestMessage et définissez des alarmes si cette valeur augmente, ce qui indique une contre-pression (backpressure) ou un throttling. Capturez la métrique Lambda Throttles et alertez dessus, et suivez les compromis entre l’utilisation et le coût de la simultanéité provisionnée.

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

• Ne pas configurer de DLQ ou se fier uniquement aux tentatives par défaut : configurez des DLQ ou des Destinations pour les Lambdas asynchrones et une politique de redirection (redrive) SQS pour les files d’attente afin de capturer les messages empoisonnés (poison messages) pour une inspection manuelle.
• Délai de visibilité incorrect sur SQS entraînant un traitement en double : définissez le délai de visibilité >= au timeout de la fonction * 2 et tenez compte des tentatives et des appels en aval pour éviter les doublons.
• Rôles d’exécution Lambda trop permissifs : évitez Resource: "*" et ajoutez des conditions de service/source (aws:SourceArn, aws:SourceAccount) aux politiques d’invocation et de ressource.
• Ignorer les limites de simultanéité, ce qui provoque du throttling : utilisez la simultanéité réservée pour plafonner les fonctions, la simultanéité provisionnée pour les fonctions sensibles à la latence, et surveillez ConcurrentExecutions/Throttles.
• Manque de traçage à travers les frontières asynchrones : ajoutez des ID de corrélation aux événements et activez X-Ray ou propagez les en-têtes de trace pour reconstituer les flux.
• Mauvaise utilisation de l’intégration directe SNS vers Lambda pour des besoins de durabilité : préférez SNS->SQS->Lambda lorsque vous avez besoin d’une mise en mémoire tampon (buffering) durable, d’un contrôle de la visibilité et d’une gestion des DLQ plus simple.

Problème pratique : Scénario d’utilisation

AcmePayments reçoit un volume élevé d’événements de paiement via EventBridge et subit un throttling intermittent de Lambda ainsi qu’un traitement en double pendant les pics d’activité. Ils ont besoin d’un traitement fiable, sans perte de données, et d’une charge limitée en aval sur DynamoDB.

1. Créez un bus d’événements personnalisé EventBridge et une règle pour correspondre aux événements de paiement ; ajoutez une file d’attente SQS FIFO comme cible durable avec DeadLetterConfig et RetryPolicy dans la configuration de la cible.
2. Configurez Lambda pour interroger (poll) la file d’attente SQS (mappage de source d’événements) avec une taille de lot (batch size) ajustée à la capacité en aval et un délai de visibilité défini sur >= au timeout de la fonction * 2.
3. Réservez de la simultanéité pour la Lambda (aws lambda put-function-concurrency …) afin de limiter les rafales d’écriture sur DynamoDB ; mettez en œuvre de la simultanéité provisionnée pour un petit pool si une faible latence est requise.
4. Mettez en œuvre l’idempotence en utilisant des écritures conditionnelles DynamoDB basées sur le payment-id et stockez les enregistrements d’idempotence avec un TTL pour le nettoyage.
5. Activez le traçage X-Ray et les journaux structurés avec un ID de corrélation dans l’événement pour tracer le traitement ; définissez des alarmes CloudWatch sur les métriques ApproximateAgeOfOldestMessage, Throttles et de la DLQ.

Justification : Le découplage d’EventBridge vers SQS fournit une mise en mémoire tampon durable et une sémantique de nouvelle tentative ; la simultanéité réservée protège la base DynamoDB en aval des rafales, l’idempotence empêche les doublons, et le traçage/les alarmes offrent une visibilité opérationnelle sur les modes de défaillance.

← Bases de données et mise en cache · Tous les domaines · Gestion des coûts et étiquetage des ressources →

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

Parcourir Amazon →