Amazon DVA-C02: Sans serveur et AWS Lambda — Guide d'étude
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.
Versions, alias, couches et empaquetage
Les versions Lambda sont des instantanés immuables du code et de la configuration, créés avec l’API PublishVersion (par exemple,
undefined
). Utilisez les versions pour fournir des déploiements reproductibles, puis créez des alias (
undefined
ou
undefined
) comme des pointeurs stables qui peuvent également comporter une configuration de routage pour répartir le trafic entre les versions pour des déploiements progressifs. Les couches (Layers) fournissent un moyen de partager des bibliothèques natives communes ou des paquets d’exécution ;
undefined
vous permet d’attacher des dépendances (par ex., des binaires compilés) séparément de votre paquet de fonction afin que les builds soient plus petits et les démarrages à froid plus rapides. Pour l’empaquetage, préférez les petites archives zip pour des déploiements rapides (ou des téléversements via S3 pour les artefacts plus volumineux) et adoptez les images de conteneur lorsque vous avez besoin de binaires conséquents ou de runtimes personnalisés ;
undefined
enregistrera les images stockées dans ECR (les images de conteneur supportent des tailles beaucoup plus grandes). Les pièges courants incluent l’intégration d’informations d’identification dans les variables d’environnement, le dépassement des limites de taille du paquet de déploiement, et l’oubli que les couches sont versionnées et immuables : mettez à jour les dépendances en publiant une nouvelle version de couche et en mettant à jour la configuration de la fonction. Pour les restaurations programmatiques (rollbacks), mettez à jour l’alias pour qu’il pointe vers une version précédente (
undefined
) afin de minimiser l’impact opérationnel.
Environnement d’exécution, optimisation des performances et atténuation des démarrages à froid
Le CPU de Lambda évolue avec la mémoire, donc l’amélioration des charges de travail limitées par le CPU (CPU-bound) se fait généralement en augmentant le paramètre MemorySize (via
undefined
) plutôt qu’en modifiant un réglage de CPU distinct ; mesurez avec les métriques AWS X-Ray et CloudWatch pour trouver le juste milieu entre la durée et le coût. Les démarrages à froid sont influencés par la taille du paquet, le code d’initialisation, l’utilisation du réseau VPC (latence de l’attachement de l’ENI) et le runtime du langage ; atténuez-les en réduisant l’initialisation, en déplaçant les bibliothèques lourdes dans des couches, en utilisant la Concurrence Provisionnée (Provisioned Concurrency) (
undefined
), ou en utilisant des images de conteneur avec des points d’entrée (entrypoints) optimisés. Pour les fonctions attachées à un VPC, évitez les pics de démarrage à froid en utilisant des points de terminaison VPC (VPC endpoints) pour S3/DynamoDB ou RDS Proxy pour limiter le renouvellement excessif des connexions (connection churn) et les coûts de la passerelle NAT ; assurez-vous que le rôle d’exécution Lambda inclut la politique gérée AWSLambdaVPCAccessExecutionRole et que les sous-réseaux disposent d’un espace d’adressage IP suffisant pour les ENI. Soyez conscient des pièges tels que les délais d’attente (timeouts) synchrones : définissez le timeout de la fonction à une valeur inférieure à celle des dépendances en aval pour garantir que les appelants externes voient un modèle d’échec cohérent, et utilisez des jetons d’idempotence pour les nouvelles tentatives car des services comme SQS, SNS et Kinesis offrent une sémantique de livraison « au moins une fois » (at-least-once).
Accès VPC, stockage éphémère et contrôles de sécurité
Lorsque vous placez une fonction Lambda dans un VPC, vous devez configurer les ID de sous-réseau (subnet IDs) et les groupes de sécurité sur la configuration de la fonction ; la fonction utilise alors des ENI dans ces sous-réseaux et a besoin de chemins réseau vers les services externes. Pour atteindre S3 ou DynamoDB sans NAT, créez des points de terminaison VPC (VPC endpoints) (Gateway pour S3, Interface pour de nombreux services). Pour les bases de données, préférez RDS Proxy pour mutualiser les connexions (pool) et réduire la création de connexions en rafale. Le répertoire /tmp fournit un stockage éphémère pour l’environnement d’exécution et est accessible en écriture pendant l’invocation ; configurez un stockage éphémère plus grand si nécessaire (paramètre EphemeralStorage) mais concevez des fonctions sans état (stateless) lorsque c’est possible. Sécurisez les secrets en les stockant dans AWS Secrets Manager ou Parameter Store (SSM) et en accordant au rôle Lambda le moindre privilège (least privilege) ; récupérez les secrets au démarrage à froid en utilisant
undefined
ou utilisez des variables d’environnement chiffrées avec une clé KMS spécifiée dans le KMSKeyArn de la fonction. Les écueils courants pour les développeurs incluent l’absence de points de terminaison VPC menant à des timeouts, l’intégration de clés en clair dans le code, et l’oubli de faire la rotation ou de mettre en cache efficacement les secrets pour éviter la limitation (throttling) des appels à l’API de Secrets Manager.
Intégrations d’événements, gestion des erreurs, tests locaux et stratégies de déploiement
Lambda s’intègre nativement avec de nombreuses sources d’événements : notifications d’événements S3, DynamoDB Streams, Kinesis, SQS et API Gateway. Pour les sources de type flux (stream), ajustez la taille des lots (batch size) et le parallelizationFactor, surveillez l’IteratorAge et gérez les échecs partiels, car Lambda réessaiera les lots échoués et peut bloquer le traitement en aval lorsque les erreurs persistent. Pour les invocations asynchrones, utilisez des DLQ ou des Destinations pour capturer les échecs (configurez l’invocation asynchrone avec des destinations onFailure/onSuccess). Les fonctions déclenchées par S3 doivent se prémunir contre les invocations récursives lorsque vous réécrivez dans le même bucket en vérifiant les clés d’objet ou en utilisant des tags d’objet. Les tests locaux se font de préférence avec l’AWS SAM CLI (sam build ; sam local invoke ; sam local start-api) ou des runtimes Lambda conteneurisés ; les tests unitaires peuvent utiliser moto ou du mocking local, mais les tests d’intégration devraient s’exécuter sur de vraies ressources AWS dans des comptes de test éphémères. Les déploiements devraient utiliser des fonctions versionnées + des alias et la répartition du trafic (traffic shifting) via CodeDeploy ou UpdateAlias avec une RoutingConfig pour effectuer des déploiements canary ou linéaires ; implémentez des hooks PreTraffic et PostTraffic pour la vérification. Les pièges typiques sont d’ignorer l’idempotence pour les nouvelles tentatives, de ne pas gérer les réponses partielles de BatchGetItem (vérifier UnprocessedKeys) et d’utiliser des rôles IAM d’exécution aux permissions trop larges.
Problème pratique : Scénario d’utilisation
Scénario : La société PhotoSpot Inc exécute une Lambda en Python qui traite des images téléversées sur S3, écrit des métadonnées dans DynamoDB et appelle une API tierce d’optimisation d’images. La fonction nécessite des performances rapides au démarrage à froid (cold start), des identifiants d’API sécurisés, des restaurations (rollbacks) sûres et un accès à un proxy RDS hébergé dans un VPC pour l’enrichissement des métadonnées.
Défi : Réduire la latence de démarrage à froid pour les téléversements visibles par l’utilisateur, protéger et effectuer la rotation de la clé d’API tierce, et permettre des restaurations sûres sans interruption de service ainsi qu’une répartition contrôlée du trafic.
Approche recommandée :
- Construire et publier des versions immuables : utilisez l’AWS CLI ou boto3 pour mettre à jour le code, puis
undefined
et créez/mettez à jour l’alias
undefined
. 2. Atténuer les démarrages à froid : configurez la Provisioned Concurrency pour l’alias
undefined
et déplacez les bibliothèques natives lourdes dans une couche (layer) publiée (
undefined
). 3. Sécuriser les identifiants : stockez la clé d’API tierce dans AWS Secrets Manager, accordez au rôle de la Lambda le moindre privilège, et récupérez-la au démarrage à froid avec
undefined
plutôt que d’intégrer les secrets dans le code ou dans des variables d’environnement en clair. 4. Gestion du VPC et des connexions : placez la fonction dans des subnets privés avec des groupes de sécurité, utilisez RDS Proxy pour l’accès à la base de données afin d’éviter les tempêtes de connexions, et créez un VPC endpoint pour S3 afin que les lectures d’images ne nécessitent pas de NAT.
Justification : L’utilisation de versions et d’alias avec répartition du trafic permet des déploiements sûrs et une restauration immédiate en redirigeant un alias. La Provisioned Concurrency et les couches réduisent la latence d’initialisation, tandis que Secrets Manager centralise la rotation des identifiants et minimise l’exposition des secrets. RDS Proxy et les VPC endpoints réduisent la latence et les coûts opérationnels en diminuant le renouvellement constant des connexions (connection churn) et la dépendance au NAT.
Tous les domaines · Amazon API Gateway et Intégration d’applications →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →