1.3 - Intégration d'applications (URL présignées, SQS FIFO, filtres d'événements)
L'objectif 1.3 de l'AWS Certified Developer Associate couvre l'intégration des composants applicatifs. Pour donner à des clients navigateur un lien temporaire de téléchargement d'un objet privé, un développeur crée une URL GET présignée avec le SDK, accordant un accès limité dans le temps sans rendre l'objet public. Avec SQS FIFO, pour garantir que les messages d'un même client sont traités strictement dans l'ordre, le message group ID identifie ce client, car l'ordre est préservé par groupe tandis que des groupes différents s'exécutent en parallèle. Quand une Lambda est déclenchée par un flux DynamoDB mais ne doit s'exécuter que pour certains éléments, ajouter un motif de filtre d'événements sur le mapping de source d'événements laisse AWS filtrer avant d'invoquer la fonction, réduisant le coût. Tu dois aussi connaître le fan-out SNS, EventBridge et les files de lettres mortes. Attends-toi à des mises en situation demandant la bonne technique.
Lien temporaire pour télécharger un objet S3 privé = URL GET présignée (SDK). Ordre strict par client en SQS FIFO = message group ID. N'invoquer Lambda que pour certains éléments du flux = motif de filtre sur le mapping de source d'événements.
Questions d'entraînement
1. Un flux de commande a plusieurs étapes séquentielles avec relances et branchements. Quel service l'orchestre en machine à états gérée ?
- Amazon SQS
- AWS Step Functions (bonne réponse)
- Amazon EventBridge
- AWS AppConfig
Step Functions orchestre des flux multi-étapes en machine à états avec relances intégrées, gestion d'erreurs, branchements et parallélisme, idéal pour coordonner des Lambda et des services.
2. Quel motif évite qu'un appelant sature une API en aval quand de nombreux appels SDK sont limités ?
- Augmenter le délai par requête à plusieurs minutes
- Supprimer entièrement toutes les relances côté client
- Ouvrir beaucoup plus de connexions TCP en parallèle
- Relances avec backoff exponentiel et jitter (bonne réponse)
En cas de limitation (HTTP 429/ThrottlingException), rejouer avec un backoff exponentiel plus un jitter aléatoire espace les relances et évite les tempêtes de relances synchronisées. Les SDK AWS le font par défaut.
3. Un développeur veut que les abonnés SNS ne reçoivent que les messages correspondant à certains attributs, sans filtrer dans le consommateur. Qu'est-ce qui permet cela ?
- Une politique de filtre d'abonnement sur les attributs de message (bonne réponse)
- Une file de lettres mortes attachée au sujet
- Une clé d'ordre FIFO sur chaque message publié
- Une alarme CloudWatch sur les métriques du sujet
Les politiques de filtre d'abonnement SNS évaluent les attributs de message (ou le corps) pour que chaque abonné ne reçoive que les messages correspondants, déplaçant le filtrage vers le courtier et réduisant la charge des consommateurs.
4. Un développeur doit exécuter une tâche planifiée chaque jour à 06:00 UTC de façon serverless et événementielle. Quelle est l'approche la plus appropriée ?
- Un attribut TTL DynamoDB expirant à 06:00
- Une instance EC2 toujours active interrogeant une horloge
- Une file SQS à délai avec un minuteur de 24 heures
- Une règle planifiée EventBridge invoquant une Lambda (bonne réponse)
EventBridge (ex CloudWatch Events) prend en charge des règles planifiées cron/rate qui invoquent de façon fiable des cibles comme Lambda. La suppression par TTL DynamoDB est au mieux et n'est pas un planificateur.
5. Une Lambda est configurée avec une source d'événement SQS. Quel réglage contrôle combien de messages sont livrés à la fonction par invocation ?
- La taille de lot sur le mappage de source d'événement (bonne réponse)
- La limite de concurrence réservée de la fonction
- La période de rétention des messages de la file SQS
- L'allocation de stockage éphémère de la Lambda
La taille de lot du mappage de source d'événement définit combien de messages SQS sont regroupés dans une invocation Lambda (jusqu'à 10000 pour standard avec fenêtre de traitement, selon les limites de charge utile), ajustant débit et travail par invocation.
6. Un même événement doit déclencher simultanément plusieurs consommateurs indépendants (e-mail, analytique, audit). Quel modèle convient le mieux ?
- Une seule file SQS interrogée par un worker
- La diffusion SNS vers plusieurs endpoints abonnés (bonne réponse)
- Une table DynamoDB stockant l'événement pour interrogation
- Une seule Lambda appelant chaque consommateur en série
La diffusion SNS publie un message vers de nombreux abonnés (files SQS, Lambda, HTTP) en même temps, découplant le producteur des consommateurs indépendants. Une seule file ou une Lambda en série couple les consommateurs entre eux.