Throttling, caching en usage plans

API Gateway gebruikt voor het beperken van aanvragen een algoritme met een tokenbucket. Tokens worden verzameld in een bucket tot aan de pieklimiet (de maximale directe capaciteit). Elke aanvraag verbruikt één token. Tokens worden aangevuld met de snelheidslimiet (de stabiele RPS). Als de bucket leeg is, worden aanvragen afgeremd. Voorbeeld: burst=5000, rate=1000 RPS. Bij de start kun je 5000 gelijktijdige aanvragen verwerken; de bucket wordt aangevuld met 1000 tokens per seconde. Zo kun je korte verkeerspieken opvangen en tegelijkertijd langetermijnlimieten voor de snelheid afdwingen.

Antwoordcaching (beschikbaar voor REST API-stages) slaat backendantwoorden op in een door API Gateway beheerde cache, zodat identieke aanvragen vanuit de cache worden geleverd zonder de backend aan te roepen. Dit verlaagt de belasting van de backend en de latentie, en kan de kosten van Lambda-aanroepen voor API's met veel leesbewerkingen aanzienlijk verlagen. De cache gebruikt de aanvraag als sleutel (methode, pad, querystrings en headers volgens de configuratie). De TTL van de cache kan worden ingesteld van 0 tot 3600 seconden (standaard 300 seconden).

Standaard bestaat de cachesleutel uit de volledige URL van het verzoek. Je kunt aanpassen welke elementen bijdragen aan de cachesleutel: neem specifieke queryparameters op (bijvoorbeeld pageSize en filter), maar sluit irrelevante parameters uit (bijvoorbeeld timestamp). Je kunt ook specifieke headers opnemen in de cachesleutel. Sluit gevoelige headers uit van de cachesleutel om te voorkomen dat privégegevens gedeelde cache-items vervuilen. Stem de cachesleutel af om het aantal cachetreffers te maximaliseren en er tegelijkertijd voor te zorgen dat verschillende logische verzoeken verschillende gecachte antwoorden krijgen.

Clients kunnen de cache voor een specifiek verzoek ongeldig maken door de header Cache-Control: max-age=0 op te nemen. Je kunt de volledige cache van een fase ook leegmaken via de console of API. Configureer of clients de cache ongeldig mogen maken. Beperk dit in productie om te voorkomen dat clients caching opzettelijk omzeilen. Om selectief toestemming te geven voor het leegmaken, koppel je een resourcebeleid of gebruik je een Lambda-authoriser die controleert of de aanroeper toestemming heeft om de cache leeg te maken.

Een Usage Plan definieert vertragingslimieten en quotumlimieten voor een groep API-clients. Koppel een API-fase aan een gebruiksplan en koppel vervolgens API keys aan het plan. Elke API-sleutel dwingt de limieten van het plan onafhankelijk af. Met gebruiksplannen kun je gelaagde toegang aanbieden: een Free-plan met 100 RPM/10.000 verzoeken per dag en een Pro-plan met 1.000 RPM/100.000 verzoeken per dag. Dit model wordt gebruikt voor API's waarvoor betaling vereist is en voor integraties met partners waarbij verschillende clients verschillende snelheidslimieten nodig hebben.

API keys zijn ondoorzichtige tekenreekstokens die clients opnemen in de requestheader x-api-key. API Gateway valideert de sleutel en koppelt het verzoek aan het bijbehorende gebruiksplan. API-sleutels zijn GEEN beveiligingsmechanisme: ze identificeren clients alleen voor vertragings- en quotumdoeleinden. Combineer API-sleutels voor beveiliging altijd met de juiste autorisatie (IAM, Lambda-authoriser of Cognito). Op API-sleutels die niet aan een gebruiksplan zijn gekoppeld, worden geen vertragingslimieten toegepast.

Naast vertragingssnelheden per seconde ondersteunen gebruiksplannen quotumlimieten: een maximumaantal verzoeken gedurende een bepaalde periode (DAY, WEEK of MONTH). Zodra een client het quotum heeft opgebruikt, retourneren volgende verzoeken 429 totdat het quotum wordt gereset. Quotumlimieten zijn nuttig om gratis gebruik af te dwingen, misbruik van de API te voorkomen en API-gebruik af te stemmen op facturering. Quotumtellers zijn uiteindelijk consistent, waardoor een client het quotum licht kan overschrijden voordat deze wordt geblokkeerd.

Bewaak de status van API Gateway met deze CloudWatch-metrieken:

• Count: totaal aantal API-aanroepen
• 4XXError: clientfouten, waaronder vertragingen met statuscode 429
• 5XXError: fouten in de backend
• Latency: totale verwerkingstijd van het verzoek
• IntegrationLatency: tijd die op de backend wordt gewacht
• CacheHitCount / CacheMissCount: effectiviteit van de cache

Stel alarmen in voor pieken in 4XXError om vertragingsproblemen te detecteren voordat ze gebruikers raken, en voor CacheMissCount om problemen met de cacheconfiguratie te identificeren.

Gebruik caching voor API's met voornamelijk leesbewerkingen waarvan de antwoorden zelden veranderen, zoals zoekopdrachten voor productcatalogi, referentiegegevens en statische configuraties. Caching werkt averechts voor gebruikersspecifieke of zeer dynamische gegevens. Gebruik throttling altijd, ook voor interne API's, om backendservices tegen overbelasting te beschermen. Combineer beide: cache veelgebruikte gegevens om de belasting van de backend te verlagen en pas strenge vertraging toe om te voorkomen dat één client de API overheerst. Voor het SAA-C03-examen verlaagt caching de kosten en latentie; throttling waarborgt de beschikbaarheid.

In deze les heb je geleerd dat throttling op account-, fase- en methodeniveau backends beschermt met behulp van een token-bucketalgoritme met instelbare snelheids- en burstlimieten, dat Response Caching backendantwoorden gedurende instelbare TTL's opslaat om de backendbelasting en latentie voor endpoints met veel leesbewerkingen te verlagen, en dat Usage Plans with API Keys snelheidslimieten en quota per client afdwingen, waardoor gelaagde toegangscontrole voor partner- en openbare API's mogelijk wordt. Hierna verkennen we ECS-clusters, taakdefinities en services voor workloads met containers.