2.4 - Performance, débit et services d'intégration
L'objectif 2.4 de l'AWS Solutions Architect Professional couvre la conception pour la performance, le débit et l'intégration de services. Tu protèges les Lambdas backend avec des limites de throttling API Gateway plus des usage plans et clés d'API pour les quotas par partenaire, et tu traites chaque commande exactement une fois et dans l'ordre avec une file SQS FIFO utilisant un deduplication ID et un message group ID. Kinesis Data Streams monte en charge en ajoutant des shards et donne à chaque consommateur un canal dédié avec enhanced fan-out, DynamoDB obtient des lectures à la microseconde via DynamoDB Accelerator (DAX) sans changer les appels d'API, et une virtual tape library Tape Gateway remplace les bandes physiques avec un minimum de changement. Le routage latency-based envoie les utilisateurs vers la région la plus proche, le step scaling ajoute des instances par paliers gradués, AWS Global Accelerator plus routage latency frontent des NLB régionaux, un crawler Glue découvre automatiquement les tables pour Athena, et le schema registry EventBridge avec discovery permet aux consommateurs de générer du code typé. Attends-toi à des mises en situation sur l'ordonnancement exactement-une-fois, un consommateur de flux en retard ou des lectures à la microseconde, et à choisir la bonne fonctionnalité de débit ou d'intégration.
Exactement-une-fois, ordonné par client = SQS FIFO avec dedup ID + message group ID. Donner à chaque consommateur de flux son canal de lecture = enhanced fan-out Kinesis. Lectures DynamoDB à la microseconde, sans changer le code = DAX.
Questions d'entraînement
1. Un nouveau tier web doit survivre à la perte d'une zone de disponibilité entière sans action manuelle. Quelle conception y parvient ?
- Un Auto Scaling group réparti sur plusieurs AZ derrière un Application Load Balancer (bonne réponse)
- Une unique grosse instance EC2 avec une Elastic IP réattachée en cas de panne
- Des instances dans une seule AZ avec des AMI horaires copiées vers une autre AZ
- Une base RDS Multi-AZ devant des instances sans état dans une seule AZ
Un ASG sur plusieurs AZ derrière un ALB remplace automatiquement les instances perdues et l'ALB cesse de router vers l'AZ défaillante : une perte d'AZ est gérée sans action manuelle. Les autres options concentrent le calcul dans une AZ ou dépendent d'une reprise manuelle/lente.
2. Une API REST publique sera bâtie sur Amazon API Gateway adossée à Lambda. Les architectes doivent protéger les fonctions backend des pics de trafic et des clients abusifs tout en offrant aux partenaires enregistrés des quotas de requêtes prévisibles. Quelles DEUX fonctionnalités d'API Gateway répondent à ces besoins ? (Choisissez DEUX réponses.)
- Déployer chaque fonction Lambda dans un VPC dédié avec des sous-réseaux privés
- Configurer des limites de throttling (débit stable et burst) sur le stage ou la méthode (bonne réponse)
- Attacher des usage plans avec des clés d'API pour imposer des quotas et débits par partenaire (bonne réponse)
- Activer le tracing actif AWS X-Ray sur l'API pour visualiser la latence des requêtes et repérer les goulots d'étranglement
Le throttling de stage ou de méthode plafonne le débit stable et le burst, protégeant Lambda des pics et abus, tandis que les usage plans liés aux clés d'API donnent à chaque partenaire un quota et un débit prévisibles. Mettre Lambda dans un VPC ne limite pas le trafic entrant de l'API, et X-Ray observe la latence sans réguler la charge.
3. Une API serverless subit des rafales de trafic qui dépassent brièvement la capacité sûre du backend, et l'équipe veut que la couche API lisse les requêtes à un débit fixe et rejette le surplus avec une erreur claire. Quel réglage d'API Gateway le permet ?
- Un throttling au niveau méthode qui renvoie un HTTP 429 au-delà du débit configuré (bonne réponse)
- Un timeout d'intégration plus long pour que le backend absorbe les rafales lentes
- La mise en cache de chaque réponse quelques secondes pour éviter de solliciter le backend
- Le passage du type d'endpoint de régional à edge-optimized pour réduire la latence
Le throttling au niveau méthode impose un débit de requêtes fixe et renvoie un HTTP 429 (Too Many Requests) pour le surplus, lissant les rafales avant qu'elles n'atteignent le backend. Un timeout plus long ne limite pas le débit, le cache n'aide que pour des lectures répétées identiques, et le type d'endpoint change la latence, pas la protection en débit.
4. Une fonction Lambda sensible à la latence subit des cold starts lors des montées de trafic, et une autre fonction moins importante du même compte consomme parfois tant de concurrence que la fonction sensible est throttlée. Quelle combinaison règle les deux problèmes ?
- Augmenter la taille mémoire de la fonction sensible et activer SnapStart sur la fonction voisine bruyante pour la réchauffer
- De la provisioned concurrency sur la fonction sensible et de la reserved concurrency pour plafonner la bruyante (bonne réponse)
- Déplacer la fonction sensible sur $LATEST et relever le quota de concurrence du compte
- Ajouter une file SQS devant la fonction sensible pour tamponner les requêtes
La provisioned concurrency garde des environnements d'exécution chauds prêts pour que la fonction sensible évite les cold starts, et la reserved concurrency sur la fonction bruyante lui garantit une part tout en la plafonnant pour qu'elle n'affame pas la sensible. Plus de mémoire n'arrête pas le throttling du voisin bruyant, $LATEST n'ajoute pas de capacité, et tamponner avec SQS ajoute de la latence sans régler les cold starts.
5. Une distribution CloudFront doit exécuter une logique légère sur chaque requête viewer pour réécrire des URL et ajouter des en-têtes de sécurité à très grande échelle, avec la latence et le coût les plus bas possibles, et sans aucun appel réseau vers d'autres services. Quelle option convient le mieux ?
- Des fonctions Lambda@Edge sur l'événement origin-request s'exécutant dans les caches edge régionaux
- CloudFront Functions exécutant du JavaScript aux points de présence sur les événements viewer (bonne réponse)
- Une fonction Lambda dédiée invoquée depuis l'origine pour chaque requête entrante
- Une flotte EC2 derrière l'origine qui réécrit les URL et injecte les en-têtes par requête
CloudFront Functions exécutent de petits scripts JavaScript à la périphérie sur les événements viewer request/response avec un démarrage sous la milliseconde et un coût très bas, idéal pour la réécriture d'URL et la manipulation d'en-têtes sans appel réseau. Lambda@Edge est plus puissant mais plus lourd et plus latent, et un Lambda ou EC2 côté origine annulent l'objectif de périphérie à faible latence.
6. Une tache Step Functions appelle un service en aval qui applique par intermittence du throttling. L'architecte veut des reprises automatiques avec backoff exponentiel puis un chemin d'echec route si les reprises sont epuisees. Que faut-il configurer sur l'etat de tache ?
- Un champ Retry avec backoff plus un Catch vers un etat gestionnaire (bonne réponse)
- Un bloc try/catch ecrit dans le code Lambda qui relance chaque erreur vers le moteur de la machine a etats
- Un Parallel state enveloppant la tache pour qu'une seconde branche reprenne silencieusement des que la premiere echoue
- Un timeout Lambda plus long, en comptant sur API Gateway pour reprendre tout le workflow a chaque reponse 5xx observee
Step Functions dispose nativement des champs Retry (avec IntervalSeconds, BackoffRate, MaxAttempts) et Catch sur un etat, donc le throttling est repris avec backoff exponentiel puis, une fois epuise, le Catch route vers un etat gestionnaire. Gerer les reprises uniquement dans Lambda perd le controle declaratif de la machine a etats, un Parallel state ne modelise pas la reprise, et API Gateway n'orchestre pas les reprises Step Functions.