Limitation, mise en cache et plans d’utilisation

Sans limitation du débit, un client défaillant ou un pic de trafic pourrait submerger vos services principaux : capacité d’exécution simultanée de Lambda, connexions RDS ou API en aval. La limitation du débit dans API Gateway restreint le nombre de requêtes par seconde et autorise de courtes pointes au-dessus du débit stable. Les requêtes limitées reçoivent immédiatement une réponse 429 Too Many Requests, sans atteindre votre service principal, ce qui protège les ressources en aval contre la surcharge.

La limitation du débit fonctionne à plusieurs niveaux. La limite au niveau du compte est de 10 000 requêtes par seconde (RPS), avec une pointe de 5 000 requêtes (limite souple, qui peut être augmentée). Au niveau de l’étape, vous pouvez définir un débit limite par défaut (RPS) et une limite de pointe qui s’appliquent à toutes les méthodes de l’étape. Au niveau de la méthode, vous pouvez remplacer les valeurs par défaut de l’étape pour certains points de terminaison, par exemple en accordant une limite de débit plus élevée à un point de terminaison GET principalement dédié à la lecture qu’à un point de terminaison POST principalement dédié à l’écriture.

La limitation du débit d’API Gateway utilise un algorithme de compartiment de jetons. Les jetons s’accumulent dans un compartiment jusqu’à la limite de pointe (capacité instantanée maximale). Chaque requête consomme un jeton. Les jetons sont reconstitués au débit limite (RPS stable). Si le compartiment est vide, les requêtes sont limitées. Exemple : burst=5000, rate=1000 RPS. Au départ, vous pouvez gérer 5 000 requêtes simultanées ; le compartiment se remplit à nouveau à raison de 1 000 jetons par seconde. Cela permet d’absorber de brèves pointes de trafic tout en appliquant des limites de débit à long terme.

La mise en cache des réponses (disponible pour les étapes REST API) stocke les réponses du service principal dans un cache géré par API Gateway, afin que les requêtes identiques soient servies depuis le cache sans atteindre le service principal. Cela réduit la charge du service principal, diminue la latence et peut réduire considérablement les coûts d’invocation Lambda pour les API principalement dédiées à la lecture. La clé du cache est fondée sur la requête (méthode, chemin, chaînes de requête et en-têtes, selon la configuration). La TTL du cache peut être configurée de 0 à 3600 secondes (300 secondes par défaut).

Par défaut, la clé de cache correspond à l’URL complète de la requête. Vous pouvez personnaliser les éléments qui contribuent à cette clé : inclure certains paramètres de chaîne de requête (par exemple, pageSize et filter), tout en excluant ceux qui ne sont pas pertinents (par exemple, l’horodatage). Vous pouvez également inclure certains en-têtes dans la clé de cache. Excluez les en-têtes sensibles afin d’éviter que des données privées ne contaminent les entrées de cache partagées. Ajustez la clé de cache pour maximiser le taux de succès du cache, tout en veillant à ce que des requêtes logiquement différentes obtiennent des réponses mises en cache différentes.

Les clients peuvent invalider le cache pour une requête donnée en incluant l’en-tête Cache-Control: max-age=0. Vous pouvez également vider l’intégralité du cache de l’étape depuis la console ou l’API. Configurez si les clients sont autorisés à invalider le cache ; en production, limitez cette possibilité afin d’éviter qu’ils ne contournent intentionnellement la mise en cache. Pour accorder sélectivement les autorisations de vidage, associez une stratégie de ressources ou utilisez un autoriseur Lambda qui vérifie si l’appelant a l’autorisation de vider le cache.

Un plan d’utilisation définit des limites de régulation et de quota pour un groupe de clients d’API. Associez une étape d’API à un plan d’utilisation, puis associez des clés API à ce plan. Chaque clé API applique indépendamment les limites du plan. Les plans d’utilisation vous permettent de proposer un accès par niveaux : un plan gratuit à 100 RPM et 10 000 requêtes par jour, ainsi qu’un plan Pro à 1 000 RPM et 100 000 requêtes par jour. Il s’agit du modèle utilisé pour les API monétisées et les intégrations de partenaires lorsque différents clients nécessitent des limites de débit différentes.

Les clés API sont des jetons opaques sous forme de chaînes de caractères que les clients incluent dans l’en-tête de requête x-api-key. API Gateway valide la clé et associe la requête au plan d’utilisation correspondant. Les clés API ne constituent PAS un mécanisme de sécurité : elles servent uniquement à identifier les clients pour la régulation et les quotas. Pour assurer la sécurité, associez toujours les clés API à une autorisation appropriée (IAM, autoriseur Lambda ou Cognito). Les clés API qui ne sont associées à aucun plan d’utilisation ne sont soumises à aucune limite de régulation.

En plus des débits de régulation par seconde, les plans d’utilisation prennent en charge les limites de quota : un nombre maximal de requêtes sur une période donnée (DAY, WEEK ou MONTH). Une fois le quota d’un client épuisé, les requêtes suivantes renvoient le code 429 jusqu’à la réinitialisation du quota. Les limites de quota sont utiles pour appliquer les offres gratuites, empêcher les abus de l’API et aligner la consommation de l’API sur la facturation. Les compteurs de quota sont cohérents à terme ; un client peut donc dépasser légèrement son quota avant d’être bloqué.

Surveillez l’état d’API Gateway à l’aide des métriques CloudWatch suivantes :

• Count : nombre total d’appels d’API
• 4XXError : erreurs côté client, y compris les régulations 429
• 5XXError : erreurs du service principal
• Latency : durée totale de la requête
• IntegrationLatency : durée d’attente du service principal
• CacheHitCount / CacheMissCount : efficacité du cache

Définissez des alarmes sur les pics de 4XXError afin de détecter les problèmes de régulation avant qu’ils n’affectent les utilisateurs, ainsi que sur CacheMissCount pour identifier les problèmes de configuration du cache.

Utilisez la mise en cache pour les API principalement dédiées à la lecture, dont les réponses changent peu : recherches dans un catalogue de produits, données de référence ou configurations statiques. La mise en cache est contre-productive pour les données propres à un utilisateur ou très dynamiques. Utilisez toujours la régulation, même pour les API internes, afin de protéger les services principaux contre la surcharge. Combinez les deux : mettez les données courantes en cache pour réduire la charge du service principal et appliquez une régulation stricte pour empêcher un seul client de monopoliser l’API. Pour l’examen SAA-C03, la mise en cache réduit les coûts et la latence ; la régulation garantit la disponibilité.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que la régulation aux niveaux du compte, de l’étape et de la méthode protège les services principaux grâce à un algorithme de compartiment à jetons avec des limites de débit et de rafale configurables ; que la mise en cache des réponses stocke les réponses des services principaux pendant des durées de vie configurables afin de réduire leur charge et la latence des points de terminaison principalement dédiés à la lecture ; et que les plans d’utilisation avec des clés API appliquent des débits de régulation et des quotas par client, permettant un contrôle d’accès par niveaux pour les API destinées aux partenaires et au public. Nous allons maintenant découvrir les clusters ECS, les définitions de tâches et les services pour les charges de travail conteneurisées.