Amazon DVA-C02: Amazon API Gateway et Intégration d'applications — 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.

Conception d’API avec API Gateway (REST, HTTP, WebSocket) et intégrations

La conception commence par le choix du bon type d’API : les API REST (API Gateway REST) offrent des fonctionnalités granulaires au niveau de l’étape (stage), telles que la mise en cache par étape et des modèles de mappage sophistiqués ; les API HTTP (API Gateway v2) offrent une latence plus faible et un coût réduit pour les patterns de proxy courants et les autorisateurs JWT/OIDC natifs ; les API WebSocket fournissent des canaux client-serveur persistants avec des clés de route ($connect, $disconnect, $default) et nécessitent l’API de gestion d’API Gateway (PostToConnection) pour envoyer des messages. Pour l’architecture des intégrations, préférez AWS_PROXY/proxy Lambda pour une simple requête/réponse (utilisez

undefined

ou pour la v2, utilisez

undefined

sur

undefined

), et choisissez HTTP ou VPC Link pour les backends HTTP privés. Pour les backends à haut débit, utilisez NLB + VPC Link. Les intégrations de type mock (simulation) (

undefined

) et les modèles de réponse d’intégration permettent aux équipes frontend de commencer sans que le backend soit prêt. Lorsque vous placez des API derrière CloudFront, utilisez des points de terminaison d’API régionaux comme origines et définissez la politique de protocole d’origine (Origin Protocol Policy) sur HTTPS uniquement ; les API REST optimisées pour la périphérie (edge-optimized) sont déjà derrière CloudFront. Les pièges courants incluent une incompatibilité des versions de format de payload entre l’API et Lambda (v1.0 vs 2.0), l’oubli d’accorder à apigateway.amazonaws.com la permission d’invoquer Lambda (ajoutez la permission avec

undefined

), et des mauvaises configurations CORS qui bloquent les navigateurs.

Patterns de sécurité et d’autorisation (Cognito, IAM, autorisateurs personnalisés)

Les patterns de sécurité doivent correspondre aux types de clients et aux modèles d’accès : utilisez Amazon Cognito User Pools ou un fournisseur OIDC externe et configurez-les en tant qu’autorisateurs JWT pour les API HTTP (

undefined

dans apigatewayv2 avec

undefined

défini sur

undefined

), ou utilisez les autorisateurs Cognito pour API REST pour un accès utilisateur basé sur la session. Pour les API de service à service ou d’administration, préférez l’autorisation IAM (SigV4) et des politiques de ressources IAM étroitement délimitées sur les étapes et les méthodes. Les autorisateurs Lambda (personnalisés) offrent une flexibilité maximale pour implémenter des règles d’authentification sur mesure, mais n’oubliez pas qu’ils ajoutent de la latence et des modes de défaillance — mettez en cache les réponses de l’autorisateur avec un TTL pour réduire les démarrages à froid (cold starts) et éviter de lever des erreurs qui renvoient un code 500 aux clients. Protégez-vous contre les abus avec les plans d’utilisation (usage plans) et les clés d’API (

undefined

) combinés avec des quotas de limitation (throttling). Assurez-vous que les permissions IAM sont correctes : accordez à API Gateway la permission d’invoquer Lambda (

undefined

) et restreignez les rôles d’exécution Lambda au moindre privilège. Les pièges pour les développeurs incluent l’oubli d’activer l’extraction du jeton (token) pour les autorisateurs JWT, les délais d’expiration (timeouts) de l’autorisateur qui impactent la latence globale de l’API, et la transmission d’en-têtes/cookies par CloudFront qui peut involontairement contourner les caches ou fuiter des données utilisateur.

Gestion des étapes, versionnage, mise en cache et déploiements canary

Considérez les étapes (stages) comme des surfaces d’exécution indépendantes : les déploiements sont des instantanés (snapshots) (

undefined

), et les étapes pointent vers ces instantanés. Utilisez des variables d’étape ou, de préférence, des alias Lambda pour router le trafic entre les versions ; basculez les alias de manière atomique (

undefined

) ou utilisez les paramètres canary de l’étape API Gateway pour un déploiement progressif. Pour les API REST, activez la mise en cache au niveau de l’étape (

undefined

avec des

undefined

pour définir

undefined

) et contrôlez le TTL et les paramètres de la clé de cache dans les réglages de la méthode ; les API HTTP n’ont actuellement pas de mise en cache intégrée, utilisez donc CloudFront ou des caches au niveau applicatif. Invalidez le cache lors d’un déploiement ou lorsque les données sous-jacentes changent ; se fier uniquement au TTL peut renvoyer des données obsolètes. Patterns de versionnage : utilisez le versionnage sémantique d’API dans le chemin (/v1/…) ou appuyez-vous sur les déploiements par étape pour des flux bleu/vert. Les pièges courants incluent le fait de supposer que les variables d’étape sont sécurisées (elles sont visibles par les développeurs ayant accès à la console), de mal configurer les clés de cache (oublier d’inclure l’en-tête d’autorisation ou les paramètres de requête), et de ne pas coordonner le déploiement des changements de schéma avec la compatibilité des clients.

Performance, Observabilité et Diagnostics

Instrumentez les API de bout en bout : activez les journaux d’exécution et les journaux d’accès sur API Gateway et produisez du JSON structuré (variables $context) vers CloudWatch Logs ; activez X-Ray sur API Gateway et Lambda (définissez tracingEnabled dans le déploiement/stage ou utilisez le SDK : PutFunctionConcurrency/UpdateFunctionConfiguration avec TracingConfig) pour corréler les traces. Surveillez les métriques API Gateway (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) et les métriques Lambda (Duration, Throttles, ConcurrentExecutions) dans CloudWatch ; utilisez les mathématiques sur les métriques pour identifier où la latence s’accumule. Pour WebSocket, suivez le nombre de connexions et les pics de 5XX sur API Gateway. Les étapes de dépannage incluent la comparaison de IntegrationLatency à Latency pour voir si le backend ou la passerelle ajoute de la surcharge, l’exploration des segments X-Ray pour les démarrages à froid ou les ENI de VPC, et la vérification des journaux CloudWatch Logs pour les erreurs de modèle de mappage. Utilisez les DLQ et les destinations pour les échecs de Lambda asynchrones, et définissez la concurrence réservée ou la concurrence provisionnée pour les fonctions critiques. Pièges pour les développeurs : journaliser des PII sensibles dans les traces (expurger à la source ou désactiver l’échantillonnage X-Ray pour ces flux), certificats de fournisseur manquants pour les domaines personnalisés (ACM régional vs us-east-1 pour les déploiements edge), et se fier à la limitation de requêtes (throttling) par défaut du compte sans plans d’utilisation pour les API publiques.

Problème Pratique : Scénario d’Utilisation

Scénario : BrightCart exploite un frontend e-commerce régional sur une application monopage (SPA) hébergée dans S3/CloudFront et expose une API de paiement via API Gateway (API HTTP régionale) qui invoque des fonctions Lambda dans un VPC et écrit les commandes dans DynamoDB. L’environnement utilise un pipeline CI/CD qui déploie les versions de Lambda sur des alias de production et expose /checkout sur un stage de production.

Défi : Suite au déploiement d’une nouvelle fonctionnalité, la latence de l’API de production a augmenté et certaines requêtes de paiement retournent des erreurs 502/504 par intermittence ; les développeurs ont besoin d’un mécanisme de restauration (rollback) sûr et de diagnostics immédiats.

Approche recommandée :

Créez une restauration de déploiement en faisant pointer le stage de l’API de production vers le déploiement précédent : utilisez aws apigatewayv2 create-deployment --api-id <api> --description "rollback" puis aws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id>.
Basculez le trafic en toute sécurité à l’aide des alias Lambda : mettez à jour l’alias prod de la Lambda vers la version précédente avec aws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version> et vérifiez le comportement.
Activez et collectez les diagnostics : activez le traçage X-Ray pour l’API et la Lambda (aws apigatewayv2 update-stage --tracing-enabled true et aws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active) et activez les journaux d’accès détaillés ($context.requestTime, $context.integrationErrorMessage) vers CloudWatch Logs.
Analysez les métriques et les traces : comparez IntegrationLatency et Latency de API Gateway dans CloudWatch, examinez les segments X-Ray pour identifier les démarrages à froid des ENI du VPC, et vérifiez les limitations (throttles) de Lambda ou les écritures conditionnelles de DynamoDB ; si la latence des ENI du VPC est la cause principale, envisagez la concurrence provisionnée (aws lambda put-provisioned-concurrency-config) ou passez à Lambda avec des optimisations de point de terminaison VPC.

Justification : Le redéploiement atomique du stage et la bascule d’alias Lambda fournissent une restauration rapide et à faible risque sans modification du code. L’activation de X-Ray et des journaux d’accès structurés permet aux développeurs de déterminer avec précision si API Gateway, les démarrages à froid de Lambda, le réseau VPC ou les appels en aval vers DynamoDB sont à l’origine des erreurs, guidant ainsi la bonne mesure d’atténuation (concurrence provisionnée, augmentation du débit ou corrections de configuration).

← Sans serveur et AWS Lambda · Tous les domaines · Amazon DynamoDB et Conception NoSQL →

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