Amazon API Gateway: REST API vs HTTP API

Amazon API Gateway espone endpoint HTTP verso backend come AWS Lambda, servizi HTTP o altri servizi AWS. La prima scelta d’esame è tra REST API e HTTP API. Le REST API offrono il set completo: caching gestito, request/response validation, API keys con usage plan, integrazione con AWS WAF ed endpoint privati. Le HTTP API sono più recenti, più economiche e a minore latenza, ma con feature ridotte: niente caching gestito, niente API key/usage plan nativi. Regola pratica: scegli HTTP API per proxy Lambda semplici a basso costo con auth JWT; scegli REST API quando servono caching, API keys, request validation o WAF.

Ogni API si distribuisce su uno stage (es. dev, prod), che è l’unità di deploy e porta la sua configurazione: throttling, caching e stage variables. Il throttling protegge il backend con limiti di rate e burst applicabili a livello di account, stage o singolo method; oltre il limite il client riceve 429 Too Many Requests e deve gestire retry con exponential backoff.

Authorizer e caching

Per l’autenticazione, API Gateway supporta più tipi di authorizer. Il Cognito authorizer valida i token emessi da un Cognito user pool senza codice custom (l’identity pool serve invece a scambiare token per credenziali AWS temporanee, uno scenario diverso). Il Lambda authorizer esegue logica custom e restituisce una policy IAM; il suo risultato può essere messo in cache per un TTL per evitare invocazioni ripetute. Le HTTP API supportano inoltre JWT authorizer nativi verso provider OIDC.

Il caching delle REST API memorizza le response per un TTL configurabile a livello di stage, riducendo latenza e carico sul backend; la chiave di cache si basa su parametri della richiesta. Poiché il caching riduce le invocazioni del backend, va escluso quando servono dati sempre freschi.

Disaccoppiamento: SQS ed EventBridge

Il decoupling tra produttori e consumatori si ottiene con code e bus di eventi. Amazon SQS offre due tipi di coda. Le standard hanno throughput quasi illimitato, consegna at-least-once (possibili duplicati) e ordinamento best-effort: i consumer devono essere idempotenti. Le FIFO garantiscono ordering e consegna esattamente-una-volta con throughput limitato; usano MessageGroupId per ordinare per gruppo e MessageDeduplicationId (o content-based deduplication) per scartare duplicati entro una finestra di 5 minuti. Il visibility timeout nasconde il messaggio in elaborazione; se non viene eliminato entro il timeout torna in coda, e dopo N tentativi finisce in una dead-letter queue.

Amazon EventBridge è un event bus per architetture event-driven. La sua forza è il content-based routing: le rule filtrano gli eventi con pattern sul contenuto del JSON e li instradano verso target diversi (Lambda, SQS, Step Functions). Differenza d’esame: SQS è punto-a-punto per il lavoro in coda, SNS è fan-out pub/sub, EventBridge aggiunge il routing basato sul contenuto e l’integrazione con sorgenti SaaS.

Orchestrazione con AWS Step Functions

AWS Step Functions coordina più servizi in un workflow (state machine) definito dichiarativamente, gestendo stato, retry, error handling e branching senza codice di orchestrazione custom. I workflow Standard servono per processi lunghi, durevoli e auditabili; gli Express per volumi elevati e brevi durate. Rispetto a una catena di Lambda che si invocano a vicenda, Step Functions rende visibile il flusso, centralizza i retry con backoff e semplifica passi paralleli e compensazioni.

Trappole tipiche d’esame

  • Serve caching, API keys o request validation → REST API: le HTTP API sono più economiche e veloci ma non offrono caching gestito né usage plan; se lo scenario li richiede, la risposta è REST API.
  • Ordine garantito e nessun duplicato → SQS FIFO: la coda standard è at-least-once con ordine best-effort; solo FIFO con MessageGroupId e deduplication garantisce ordering, a costo di throughput inferiore.
  • Coda standard scelta per throughput → consumer idempotenti: essendo la consegna at-least-once, il design corretto rende l’elaborazione idempotente invece di assumere zero duplicati.
  • Instradare eventi verso target diversi in base al payload → EventBridge: il content-based routing con event pattern è di EventBridge; SNS fa fan-out senza filtri ricchi sul contenuto e SQS non instrada.
  • Autenticare utenti su API Gateway senza scrivere codice → Cognito user pool authorizer: l’identity pool serve a ottenere credenziali AWS, non ad autorizzare le chiamate API; è un distrattore classico.
  • Coordinare più passi con retry e gestione errori → Step Functions: invece di Lambda che si invocano a catena, una state machine centralizza branching, retry con backoff e visibilità del flusso.