# REL05-BP02 Limiter les demandes
Limitez les demandes pour atténuer l'épuisement des ressources en cas d'augmentation imprévue de la demande. Les demandes inférieures à la limite sont traitées tandis que celles dépassant la limite définie sont rejetées et présentent un message de retour indiquant que la demande a dépassé la limite.
**Résultat souhaité :** les pics de volume importants, qu'ils soient dus à une augmentation soudaine du trafic client, à des inondations ou à des tempêtes de nouvelles tentatives, sont atténués par la limitation des demandes, ce qui permet aux charges de travail de poursuivre le traitement normal du volume de demandes pris en charge.
**Anti-modèles courants :**
+ Les limitations des points de terminaison de l'API ne sont pas implémentées ou leurs valeurs par défaut sont conservées sans tenir compte des volumes attendus.
+ Les points de terminaison de l'API ne sont pas testés en termes de charge ou les limites de régulation ne sont pas testées.
+ Limiter les taux de demandes sans tenir compte de la taille ou de la complexité des demandes.
+ Tester les taux de demande maximaux ou la taille maximale des demandes, mais pas les deux simultanément.
+ Les ressources ne sont pas provisionnées selon les mêmes limites établies lors des tests.
+ Aucun plan d'utilisation n'a été configuré ni envisagé pour les utilisateurs d'API d'application à application (A2A).
+ Les utilisateurs de files d'attente qui redimensionnent horizontalement ne disposent pas de paramètres de simultanéité maximaux configurés.
+ La limitation du débit par adresse IP n'a pas été mise en œuvre.
**Avantages liés au respect de cette bonne pratique :** Les charges de travail qui fixent des limites peuvent fonctionner normalement et traiter correctement le chargement des demandes acceptées en cas de pics de volume inattendus. Les pics soudains ou soutenus de demandes adressées aux API et aux files d'attente sont limités et n'épuisent pas les ressources de traitement des demandes. Les limites de débit limitent les requêtes individuelles afin que les volumes élevés de trafic provenant d'une seule adresse IP ou d'un seul utilisateur d'API n'épuisent pas les ressources et n'aient pas d'impact sur les autres consommateurs.
**Niveau de risque exposé si cette bonne pratique n'est pas respectée :** Élevé
## Directives d'implémentation
Les services doivent être conçus pour traiter une capacité connue de demandes ; cette capacité peut être établie par des tests de charge. Si les taux d'arrivée des demandes dépassent les limites, la réponse appropriée indique qu'une demande a été limitée. Cela permet au consommateur de gérer l'erreur et de réessayer ultérieurement.
Lorsque votre service nécessite une implémentation de limitation, pensez à implémenter l'algorithme du compartiment à jetons, dans lequel un jeton compte pour une demande. Les jetons sont rechargés à une vitesse limitée par seconde et vidés de manière asynchrone à raison d'un jeton par demande.
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implémente l'algorithme du compartiment à jetons en fonction des limites du compte et de la région et il peut être configuré par client avec des plans d'utilisation. En outre, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) et [Amazon Kinesis](https://aws.amazon.com/kinesis/) peuvent mettre en mémoire tampon les demandes afin de lisser le taux de demandes et de permettre des taux de limitation plus élevés pour les demandes pouvant être traitées. Enfin, vous pouvez implémenter la limitation du débit avec [AWS WAF](https://aws.amazon.com/waf/) afin de limiter les utilisateurs d'API spécifiques qui génèrent une charge anormalement élevée.
## Étapes d'implémentation
Vous pouvez configurer API Gateway avec des limites de régulation pour vos API et retourner `des erreurs 429 Demandes trop nombreuses` lorsque les limites sont dépassées. Vous pouvez utiliser AWS WAF avec vos points de terminaison API Gateway et AWS AppSync pour activer la limitation du débit par adresse IP. En outre, lorsque votre système peut tolérer un traitement asynchrone, vous pouvez placer les messages dans une file d'attente ou un flux pour accélérer les réponses aux clients du service, ce qui vous permet d'atteindre des taux d'accélération plus élevés.
Avec le traitement asynchrone, lorsque vous avez configuré Amazon SQS en tant que source d'événements pourAWS Lambda, vous pouvez [configurer la simultanéité maximale](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) afin d'éviter que des taux d'événements élevés n'épuisent le quota d'exécution simultanée disponible du compte requis pour d'autres services de votre charge de travail ou de votre compte.
Bien qu'API Gateway propose une implémentation gérée du compartiment à jetons, lorsque vous ne pouvez pas utiliserAPI Gateway, vous pouvez tirer parti des implémentations open source spécifiques à la langue (voir les exemples associés dans Ressources) du compartiment à jetons pour vos services.
+ Comprenez et configurez [les limitations API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) au niveau du compte par région, de l'API par étape et de la clé d'API par niveau de plan d'utilisation.
+ Appliquez [les règles de limitation de débit AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) vers les points de terminaison API Gateway et AWS AppSync pour vous protéger contre les inondations et bloquer les adresses IP malveillantes. Les règles de limitation de débit peuvent également être configurées sur les clés d'API AWS AppSync pour les consommateurs A2A.
+ Déterminez si vous avez besoin d'un contrôle plus limitant qu'une limitation du débit pour les API AWS AppSync et, si c'est le cas, configurez un API Gateway devant votre point de terminaison AWS AppSync.
+ Lorsque des files d'attente Amazon SQS sont configurées comme déclencheurs pour les utilisateurs de files d'attente Lambda, définissez [la simultanéité maximale](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) sur une valeur capable d'effectuer un traitement suffisant pour vous permettre d'atteindre vos objectifs de niveau de service sans pour autant dépasser les limites de simultanéité affectant les autres fonctions Lambda. Envisagez de définir une concurrence réservée pour d'autres fonctions Lambda du même compte et de la même région lorsque vous utilisez des files d'attente avec Lambda.
+ Utilisez API Gateway avec des intégrations de services natives vers Amazon SQS ou Kinesis pour mettre des demandes en mémoire tampon.
+ Si vous ne pouvez pas utiliser API Gateway, examinez les bibliothèques spécifiques à la langue pour implémenter l'algorithme de compartiment à jetons adapté à votre charge de travail. Consultez la section des exemples et faites vos propres recherches pour trouver une bibliothèque appropriée.
+ Testez les limites que vous envisagez de définir ou d'autoriser à augmenter, et documentez les limites testées.
+ N'augmentez pas les limites au-delà de ce que vous avez établi lors des tests. Lorsque vous augmentez une limite, vérifiez que les ressources provisionnées sont déjà équivalentes ou supérieures à celles des scénarios de test avant d'appliquer l'augmentation.
## Ressources
**Bonnes pratiques associées :**
+ [REL04-BP03 Effectuer un travail constant](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
**Documents connexes :**
+ [Amazon API Gateway : limiter les demandes d'API pour un meilleur débit](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF : déclaration de règle basée sur le débit ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introduction d'une simultanéité maximale de AWS Lambda en utilisant Amazon SQS comme source d'événements ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda : simultanéité maximale ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Exemples connexes :**
+ [ Les trois principales règles AWS WAF basées sur le débit ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Bucket4j Java ](https://github.com/bucket4j/bucket4j)
+ [ Jeton-compartiment Python ](https://pypi.org/project/token-bucket/)
+ [ Nœud jeton-compartiment ](https://www.npmjs.com/package/tokenbucket)
+ [ Limitation du débit de threading du système .NET ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Vidéos connexes :**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Outils associés :**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)