Throttling, caching e piani di utilizzo

Senza throttling, un singolo client che si comporta in modo anomalo o un picco di traffico potrebbe sovraccaricare i servizi backend: la concorrenza Lambda, le connessioni RDS o le API a valle. Il throttling in API Gateway limita il numero di richieste al secondo e consente brevi picchi al di sopra della velocità a regime. Le richieste sottoposte a throttling ricevono immediatamente una risposta 429 Too Many Requests, senza raggiungere il backend, proteggendo le risorse a valle dal sovraccarico.

Il throttling opera a più livelli. Il limite a livello di account è di 10.000 richieste al secondo (RPS), con un burst di 5.000 richieste (limite non rigido, aumentabile). A livello di stage, è possibile impostare una velocità di throttling predefinita (RPS) e un limite di burst applicati a tutti i metodi dello stage. A livello di metodo, è possibile sostituire i valori predefiniti dello stage per endpoint specifici, ad esempio assegnando a un endpoint GET con molte letture un limite di velocità superiore rispetto a un endpoint POST con molte scritture.

Il throttling di API Gateway usa un algoritmo token bucket. I token si accumulano in un bucket fino al limite di burst (capacità istantanea massima). Ogni richiesta consuma un token. I token vengono reintegrati alla velocità limite (RPS a regime). Se il bucket è vuoto, le richieste vengono sottoposte a throttling. Esempio: burst=5000, rate=1000 RPS. All'inizio è possibile gestire 5000 richieste simultanee; il bucket si ricarica alla velocità di 1000 token al secondo. In questo modo si assorbono brevi picchi di traffico, rispettando al contempo i limiti di velocità a lungo termine.

Il caching delle risposte (disponibile negli stage di REST API) memorizza le risposte del backend in una cache gestita da API Gateway, così le richieste identiche vengono servite dalla cache senza raggiungere il backend. Questo riduce il carico del backend e la latenza e può diminuire significativamente i costi delle invocazioni Lambda per le API con molte operazioni di lettura. La cache usa come chiave la richiesta (metodo, percorso, query string e intestazioni, secondo la configurazione). Il TTL della cache è configurabile da 0 a 3600 secondi (il valore predefinito è 300 secondi).

Per impostazione predefinita, la chiave della cache è l'URL completo della richiesta. È possibile personalizzare gli elementi che contribuiscono alla chiave della cache: includere parametri specifici della stringa di query (ad esempio pageSize, filter) ed escludere quelli irrilevanti (ad esempio il timestamp). È inoltre possibile includere intestazioni specifiche nella chiave della cache. Escluda dalla chiave della cache le intestazioni sensibili per impedire che dati privati contaminino le voci della cache condivisa. Ottimizzi la chiave della cache per massimizzare il tasso di cache hit, assicurandosi al contempo che richieste logicamente diverse ricevano risposte memorizzate nella cache diverse.

I client possono invalidare la cache per una richiesta specifica includendo nell'intestazione la direttiva Cache-Control: max-age=0. È inoltre possibile svuotare l'intera cache dello stage dalla console o tramite API. Configuri se i client possono invalidare la cache; in produzione limiti questa possibilità per impedire che i client aggirino intenzionalmente la memorizzazione nella cache. Per concedere selettivamente le autorizzazioni di svuotamento, associ una resource policy oppure utilizzi un autorizzatore Lambda che verifichi se il chiamante dispone dell'autorizzazione necessaria.

Un piano di utilizzo definisce i limiti di throttling e di quota per un gruppo di client API. Associe uno stage API a un piano di utilizzo, quindi associ al piano le chiavi API. Ogni chiave API applica i limiti del piano in modo indipendente. I piani di utilizzo consentono di offrire livelli di accesso differenziati: un piano Free a 100 RPM/10.000 richieste al giorno e un piano Pro a 1.000 RPM/100.000 richieste al giorno. Questo è il modello utilizzato per le API monetizzate e le integrazioni con partner, quando client diversi richiedono limiti di frequenza differenti.

Le chiavi API sono token stringa opachi che i client includono nell'intestazione della richiesta x-api-key. API Gateway convalida la chiave e associa la richiesta al piano di utilizzo corrispondente. Le chiavi API NON sono un meccanismo di sicurezza: servono esclusivamente a identificare i client ai fini del throttling e delle quote. Per la sicurezza, combini sempre le chiavi API con un'adeguata autorizzazione (IAM, autorizzatore Lambda o Cognito). Alle chiavi API non associate a un piano di utilizzo non vengono applicati limiti di throttling.

Oltre ai limiti di throttling al secondo, i piani di utilizzo supportano i limiti di quota: un numero massimo di richieste in un determinato periodo (DAY, WEEK o MONTH). Quando un client esaurisce la propria quota, le richieste successive restituiscono 429 fino al ripristino della quota. I limiti di quota sono utili per applicare i livelli gratuiti, prevenire l'abuso delle API e allineare il consumo delle API alla fatturazione. I contatori delle quote sono soggetti a consistenza eventuale, quindi un client potrebbe superare leggermente la propria quota prima che le richieste vengano bloccate.

Monitori lo stato di API Gateway con queste metriche CloudWatch:

• Count: numero totale di chiamate API
• 4XXError: errori del client, inclusi i throttling 429
• 5XXError: errori del backend
• Latency: tempo della richiesta end-to-end
• IntegrationLatency: tempo di attesa del backend
• CacheHitCount / CacheMissCount: efficacia della cache

Imposti allarmi sui picchi di 4XXError per rilevare i problemi di throttling prima che influiscano sugli utenti e su CacheMissCount per individuare i problemi di configurazione della cache.

Utilizzi il caching per le API con molte operazioni di lettura, le cui risposte cambiano raramente: ricerche nel catalogo prodotti, dati di riferimento e configurazioni statiche. Il caching è controproducente per i dati specifici dell'utente o altamente dinamici. Utilizzi sempre il throttling, anche per le API interne, per proteggere i servizi backend dal sovraccarico. Li combini entrambi: memorizzi nella cache i dati comuni per ridurre il carico sul backend e applichi un throttling deciso per impedire che un singolo client monopolizzi l'API. Per l'esame SAA-C03, il caching riduce i costi e la latenza; il throttling garantisce la disponibilità.

Verifichi la propria comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che il throttling a livello di account, stage e metodo protegge i backend utilizzando un algoritmo token bucket con limiti configurabili di frequenza e burst; il Response Caching memorizza le risposte del backend per TTL configurabili, riducendo il carico sul backend e la latenza degli endpoint con molte letture; infine, i piani di utilizzo con chiavi API applicano frequenze di throttling e quote per client, consentendo un controllo degli accessi a livelli per le API pubbliche e dei partner. Ora esamineremo i cluster ECS, le definizioni delle attività e i servizi per i carichi di lavoro containerizzati.