Quando un’applicazione moderna espone decine o centinaia di API, gestirle senza un punto di controllo centralizzato diventa rapidamente un incubo. Autenticazione duplicata in ogni microservizio, rate limiting implementato in modo difforme, log sparsi su sistemi diversi, versioning gestito a mano: chiunque abbia provato a scalare un’architettura a microservizi conosce questo dolore. La risposta a questi problemi si chiama API gateway.
In questa guida confrontiamo le principali soluzioni di API gateway disponibili nel 2021 — Kong API gateway, Tyk, AWS API Gateway, Azure API Management e Apigee gateway — analizzando funzionalità, costi, casi d’uso e criteri di scelta. L’obiettivo è offrire a CTO, IT manager, developer senior e DevOps engineer un riferimento operativo per orientarsi tra opzioni open source e commerciali, evitando errori di valutazione che si pagano poi in produzione.
API gateway: cosa è e perché serve
Un API gateway è un componente software che si frappone tra i client (browser, app mobile, sistemi terzi) e i servizi backend. Tutte le richieste passano attraverso il gateway, che si occupa di instradarle al servizio corretto, applicare regole di sicurezza, controllare i flussi di traffico e raccogliere metriche. È il “front door” delle API, il punto unico in cui concentrare logiche trasversali che altrimenti finirebbero replicate in ogni microservizio.
L’esigenza nasce con l’affermazione delle architetture a microservizi. Un monolite espone tipicamente una manciata di endpoint pubblici; un sistema a microservizi può avere decine di servizi, ciascuno con la propria API. Senza un gateway, ogni client dovrebbe conoscere l’indirizzo di ogni servizio, gestire l’autenticazione separatamente, implementare retry e circuit breaker. Il gateway astrae questa complessità: i client parlano con un solo endpoint stabile, mentre dietro le quinte l’architettura può evolvere liberamente.
Per chi si sta avvicinando al mondo delle API è utile partire dalla nostra guida di base “Cos’è una API REST” (link interno: guida non sviluppatori): il gateway è il livello successivo, lo strumento che entra in gioco quando le API smettono di essere uno strato tecnico e diventano un prodotto da governare.
Le 7 funzionalità essenziali di un API gateway
Non tutti gli API gateway sono uguali. Esistono prodotti minimali pensati per il routing di base e piattaforme complete che includono portali developer, marketplace e analytics avanzate. Le funzionalità che dovrebbero essere presenti in qualsiasi soluzione professionale sono sette.
1. Routing intelligente. Il gateway riceve una richiesta su un percorso (ad esempio /api/v2/orders) e la inoltra al servizio backend corretto. Le regole di routing possono basarsi su path, header, parametri di query, hostname o versione dell’API. Routing avanzato include canary deployment, blue-green deployment, traffic mirroring per testare nuove versioni in produzione su una percentuale del traffico.
2. Rate limiting e throttling. Limitare il numero di richieste per client, per API key, per IP o per utente è essenziale per proteggere i servizi backend da picchi accidentali o attacchi DoS. Le policy tipiche prevedono finestre temporali (richieste al secondo, al minuto, all’ora) e differenziazione per piano commerciale (free tier vs paid tier).
3. Autenticazione e autorizzazione. Il gateway centralizza la verifica delle credenziali: API key, OAuth 2.0, JWT, mutual TLS, integrazione con identity provider esterni (Okta, Auth0, Keycloak). I servizi backend ricevono richieste già autenticate, riducendo la superficie di attacco e semplificando la logica applicativa.
4. Trasformazione di request e response. Il gateway può modificare il payload prima di inoltrarlo al backend o prima di restituirlo al client: aggiungere o rimuovere header, convertire XML in JSON, adattare formati legacy. Questa funzionalità è cruciale per esporre API moderne sopra sistemi datati senza dover modificare il codice esistente.
5. Caching delle risposte. Risposte a richieste GET possono essere memorizzate sul gateway e servite direttamente, evitando di colpire il backend. Per API ad alto traffico con dati che cambiano lentamente (cataloghi, configurazioni, dati di riferimento) il caching riduce drasticamente latenza e carico.
6. Monitoring e observability. Il gateway è il punto naturale dove raccogliere metriche aggregate: numero di chiamate per endpoint, latenza media, error rate, status code distribution. Integrazione con Prometheus, Grafana, ELK Stack, Datadog è ormai standard. Senza monitoring centralizzato è impossibile capire cosa sta accadendo a livello di API.
7. Sicurezza applicativa. WAF integrato, protezione contro injection, rilevamento di pattern anomali, IP whitelisting/blacklisting, validazione di schema (OpenAPI/Swagger). La sicurezza al livello del gateway è il primo strato di difesa; per approfondire il tema rimandiamo all’articolo dedicato alle best practice di API security.
Open source vs commerciali: pro e contro
La scelta tra una soluzione open source self-hosted e un servizio gestito commerciale è probabilmente la decisione architetturale più rilevante. Ci sono vantaggi e svantaggi su entrambi i fronti.
Le soluzioni open source (Kong Community, Tyk Open Source, KrakenD, Express Gateway) offrono pieno controllo: nessun vendor lock-in, possibilità di personalizzare il codice, costi di licenza zero. Lo svantaggio è il costo operativo nascosto: serve un team in grado di installare, aggiornare, monitorare, scalare il gateway. Per realtà piccole questo costo può superare quello di un servizio gestito.
Le soluzioni commerciali managed (AWS API Gateway, Azure API Management, Apigee, Kong Konnect) offrono setup rapido, SLA, supporto dedicato, integrazione nativa con il resto dell’ecosistema cloud. Il rovescio della medaglia è il vendor lock-in (migrare da AWS API Gateway a Kong richiede sforzo significativo) e costi che crescono con il volume di traffico, talvolta in modo non lineare.
Il criterio di scelta non è ideologico ma economico-organizzativo. Una PMI con due developer e nessun DevOps dedicato dovrebbe quasi sempre orientarsi su soluzioni managed. Un’azienda con team infrastrutturale strutturato e volumi elevati può trovare nelle soluzioni open source un risparmio significativo, oltre alla flessibilità di personalizzazione.
Kong: il leader open source
Kong API gateway è probabilmente la soluzione open source più diffusa nel 2021. Costruita sopra Nginx e OpenResty, Kong nasce nel 2015 dall’azienda Mashape, che nel 2017 si rinomina Kong Inc. Il prodotto core è scritto in Lua e offre prestazioni eccellenti — milioni di richieste al secondo su hardware modesto.
L’architettura di Kong è basata su plugin: routing, autenticazione, rate limiting, trasformazione, logging sono tutti plugin caricabili dinamicamente. La community ha sviluppato decine di plugin aggiuntivi, e scriverne di propri in Lua o Go è relativamente semplice. La configurazione avviene via API REST o via file YAML dichiarativi (DB-less mode), con supporto nativo a Kubernetes tramite l’Ingress Controller ufficiale.
Kong esiste in tre edizioni: Kong Gateway (Community Edition) open source e gratuita; Kong Enterprise con plugin avanzati (RBAC, OAuth 2.0 server, portali developer); Kong Konnect, l’offerta SaaS managed lanciata nel 2020. La forza di Kong è la maturità della codebase, la community attiva, la documentazione eccellente. Lo svantaggio è che il setup self-hosted richiede competenze su PostgreSQL/Cassandra (o su modalità DB-less) e sull’ecosistema Nginx.
Tyk: alternativa open source matura
Tyk è la principale alternativa open source a Kong. Scritto in Go, è nato nel 2014 e offre un’architettura monolitica più semplice da deployare rispetto a Kong: un singolo binario, configurazione via JSON, nessuna dipendenza esterna obbligatoria oltre a Redis per le cache distribuite.
Le funzionalità sono comparabili a Kong: routing, multiple authentication schemes (JWT, OAuth 2.0, HMAC, basic auth), rate limiting, quotas per utente, transformation, analytics integrate. Tyk include nativamente un developer portal, mentre su Kong è una funzionalità della Enterprise Edition. Il dashboard di amministrazione di Tyk è considerato più immediato di quello di Kong, soprattutto per team alle prime armi.
Tyk è una scelta sensata quando si vuole un’unica soluzione integrata (gateway + developer portal + analytics) senza dipendere da Nginx. La community è meno ampia di quella di Kong, ma il supporto commerciale è disponibile e l’azienda è solida.
AWS API Gateway, Azure API Management, Google Apigee
I tre cloud provider principali offrono servizi managed di API gateway con caratteristiche distintive.
AWS API Gateway è il più anziano, lanciato nel 2015. Esiste in tre tipologie: REST API (la versione classica, ricca di funzionalità ma più costosa), HTTP API (più leggera ed economica, lanciata nel 2020) e WebSocket API. L’integrazione nativa con Lambda permette architetture serverless pure, mentre la connessione a servizi VPC consente di esporre API verso backend tradizionali. Il modello di pricing è pay-per-request, vantaggioso per traffici discontinui ma costoso per volumi elevati. La curva di apprendimento è ripida — la console AWS è notoriamente complessa — ma l’ecosistema è ineguagliabile.
Azure API Management è il prodotto Microsoft, disponibile in tier diversi (Consumption, Developer, Basic, Standard, Premium) con prezzi mensili fissi (eccetto Consumption pay-per-use). Si integra nativamente con Azure AD per l’autenticazione, con Application Insights per il monitoring, con Azure Functions per il serverless. Include un developer portal personalizzabile e un sistema di “policy” basato su XML per applicare logiche custom. È la scelta naturale per organizzazioni già investite nell’ecosistema Microsoft.
Apigee gateway, acquisita da Google nel 2016 e integrata in Google Cloud Platform, è storicamente il prodotto più orientato all’enterprise: sviluppato per gestire programmi API mission-critical, offre funzionalità avanzate di monetization (fatturazione delle chiamate API a clienti terzi), analytics di alto livello, machine learning per individuare anomalie nel traffico. Il pricing è significativamente superiore agli altri (parte da migliaia di euro al mese), giustificato da feature che PMI raramente usano. Apigee è la scelta giusta quando le API sono il prodotto, non un dettaglio implementativo.
API Gateway vs Service Mesh
Una confusione comune nel 2021 riguarda il rapporto tra API gateway e service mesh (Istio, Linkerd, Consul Connect). Entrambi gestiscono traffico di rete, entrambi offrono routing, observability, sicurezza. Eppure rispondono a problemi diversi.
L’API gateway gestisce il traffico nord-sud: dall’esterno (client pubblici, app, sistemi terzi) verso l’interno (i microservizi). Il service mesh gestisce il traffico est-ovest: tra microservizi all’interno del cluster. Un gateway tipicamente espone qualche centinaio di endpoint pubblici; un service mesh può governare migliaia di chiamate inter-servizio al secondo.
Le due tecnologie sono complementari, non alternative. Un’architettura matura può prevedere entrambe: un API gateway in front per il traffico pubblico e un service mesh dietro per il traffico interno. Iniziare con il solo gateway è normale: il service mesh introduce complessità operativa significativa e ha senso solo quando il numero di microservizi e di chiamate inter-servizio diventa rilevante.
Casi d’uso pratici per PMI italiane
Nelle PMI italiane gli scenari ricorrenti in cui un API gateway porta valore concreto sono cinque.
Esposizione di API pubbliche. Un’azienda B2B che vuole offrire integrazioni ai propri clienti (gestionale che parla con il sistema cliente, marketplace che espone catalogo a partner) ha bisogno di API documentate, autenticate, monitorate. Il gateway è il punto di partenza per costruire un programma API serio.
Modernizzazione di sistemi legacy. Un ERP on-premise scritto vent’anni fa può essere “wrappato” da API moderne esposte tramite gateway. Il client esterno parla REST/JSON al gateway, che traduce e dialoga con il sistema legacy nei suoi protocolli nativi. È un pattern di facade che permette di rinnovare l’integrazione senza riscrivere il core.
Backend for frontend (BFF). Un’app mobile e un sito web hanno bisogno di dati simili ma aggregati in modo diverso. Il gateway può fornire endpoint specifici per ciascun frontend, aggregando chiamate a microservizi multipli e restituendo solo i campi rilevanti. Il pattern BFF riduce il numero di round-trip dal client e semplifica il codice frontend.
Multi-tenant SaaS. Una piattaforma SaaS con clienti multipli può usare il gateway per applicare quote per tenant, rate limiting differenziato per piano commerciale, isolamento dei log per cliente. Funzionalità che sarebbero complesse da implementare a livello applicativo diventano configurazione del gateway.
Integrazioni con servizi terzi. Un’azienda che orchestra chiamate verso decine di servizi esterni (Stripe, SendGrid, sistemi di shipping) può usare il gateway come punto di centralizzazione, con retry policy, circuit breaker, log uniformi. Per progetti di integrazione API custom questo approccio è ormai lo standard.
Costi indicativi 2021 (free tier vs enterprise)
I costi variano enormemente in base a soluzione, volume e modalità di deployment. Diamo un’idea di massima dei valori 2021.
Open source self-hosted: licenza zero, ma serve hardware/cloud (per Kong su un cluster Kubernetes minimale parliamo di 100-300 €/mese) più tempo persona per setup e mantenimento (calcolare almeno mezza giornata persona/mese in regime stabile, di più nelle prime settimane).
AWS API Gateway: REST API costa circa 3,50 USD per milione di richieste; HTTP API circa 1,00 USD per milione. Per un servizio con 10 milioni di chiamate al mese parliamo di 10-35 USD, più i costi di Lambda o backend collegati.
Azure API Management: tier Developer (per ambienti non produttivi) costa circa 50 €/mese; tier Basic parte da 130 €/mese; tier Standard intorno ai 600 €/mese; tier Premium oltre i 2.500 €/mese con SLA del 99,99% e multi-region.
Kong Enterprise: pricing su richiesta, tipicamente parte da circa 25.000 USD/anno per deployment medi; Kong Konnect (managed) ha tier Plus a partire da 250 USD/mese per un singolo control plane.
Apigee: tier Evaluation gratuito per sviluppo; pricing produzione su richiesta, tipicamente da 25.000 USD/anno in su, fino a centinaia di migliaia per le edizioni enterprise.
Una valutazione TCO seria deve includere costi nascosti: tempo persona per gestione, costi di formazione, costi di migrazione futura, eventuali aumenti tariffari del provider.
Errori frequenti nelle implementazioni
Vedere errori ricorrenti aiuta a evitarli. Cinque sono i più comuni nelle implementazioni che abbiamo osservato sul campo.
Gateway come monolite. Concentrare nel gateway logica applicativa specifica (validazioni di business, calcoli, trasformazioni complesse) lo trasforma in un nuovo monolite. Il gateway deve restare “thin”: routing, sicurezza, observability, niente più. La logica di business sta nei servizi, non nel gateway.
Single point of failure non gestito. Se tutto il traffico passa dal gateway e il gateway cade, l’intera piattaforma è offline. Cluster ad alta disponibilità, health check, deployment multi-region (per servizi critici) sono prerequisiti operativi, non optional.
Sottovalutazione delle latenze. Ogni hop aggiunge latenza. Un gateway ben tunato aggiunge 1-3 ms; uno mal configurato può aggiungerne 50-100. Il caching aggressivo e la scelta corretta di plugin sono fondamentali. Profilare le latenze prima di andare in produzione è obbligatorio.
Versioning trascurato. Le API evolvono. Senza una strategia di versioning chiara fin dal giorno uno, ci si ritrova a non poter aggiornare endpoint perché client legacy ne dipendono. URL versioning (/v1/, /v2/) o header versioning sono entrambi validi: l’importante è scegliere e applicare consistentemente.
Documentazione assente. Un gateway senza OpenAPI/Swagger aggiornato è un gateway difficile da consumare. Auto-generare la documentazione da specifiche OpenAPI mantenute nel codice, esporre un developer portal, fornire esempi di chiamate è ciò che separa un’API “tecnicamente disponibile” da un’API “effettivamente usabile”.
Roadmap di scelta
Non esiste l’API gateway “migliore” in assoluto. Esiste quello giusto per il proprio contesto. Una roadmap di scelta in cinque passi può aiutare a strutturare la decisione.
Passo 1: definire i requisiti. Volume di traffico atteso (richieste/secondo medie e di picco), numero di API da gestire, tipologia di client (browser, mobile, partner B2B), requisiti normativi (GDPR, settori regolamentati), SLA target.
Passo 2: valutare il contesto cloud. L’organizzazione è già su AWS, Azure, GCP, on-premise, multi-cloud? La risposta orienta verso il gateway nativo del provider o verso una soluzione cloud-agnostic.
Passo 3: stimare i costi. Calcolare il TCO a 3 anni includendo licenze, infrastruttura, tempo persona, formazione, migrazione. Confrontare almeno tre alternative.
Passo 4: PoC su scenario reale. Mai scegliere senza una proof-of-concept di 2-4 settimane su un caso d’uso reale. Un gateway che funziona bene su slide può rivelarsi inadeguato su workload specifici.
Passo 5: definire la strategia di exit. Cosa succede se tra due anni vogliamo cambiare gateway? Quanto costa la migrazione? Tenere il codice di routing e le policy in formato dichiarativo (YAML/JSON) facilita future migrazioni; logica embedded in plugin proprietari le complica.
Per architetture enterprise ben progettate consigliamo di valutare anche la sinergia con altre componenti del sistema: web app e PWA moderne, soluzioni cloud scalabili e gestionali personalizzati sono tasselli che insieme al gateway disegnano architetture coerenti.
Domande frequenti
Quando un’azienda dovrebbe iniziare a usare un API gateway? Nel momento in cui ha più di 3-4 servizi backend che espongono API, oppure quando una singola API è consumata da più tipologie di client (web + mobile + partner). Sotto quella soglia un reverse proxy semplice (Nginx, HAProxy) può bastare.
Kong API gateway o AWS API Gateway? Dipende dal contesto. AWS API Gateway è la scelta naturale se l’architettura è già serverless su AWS. Kong è preferibile per architetture cloud-agnostic, multi-cloud, o quando si vuole evitare il vendor lock-in. Non sono mutuamente esclusivi: ci sono casi in cui hanno senso entrambi.
Un API gateway sostituisce un Web Application Firewall (WAF)? No. Sebbene molti gateway includano funzionalità di security di base, un WAF dedicato (Cloudflare, AWS WAF, ModSecurity) offre protezione più approfondita contro OWASP Top 10. In architetture mature il WAF sta davanti al gateway, non al posto.
È possibile mantenere un API gateway interno (private) e uno esterno (public)? Sì, è un pattern comune. Il gateway esterno gestisce traffico pubblico con regole di sicurezza stringenti; il gateway interno gestisce traffico tra business unit con policy meno restrittive. Si parla di “two-tier gateway pattern”.
Service mesh come Istio sostituisce un API gateway? No. Istio gestisce traffico est-ovest tra microservizi, l’API gateway gestisce traffico nord-sud. Sono complementari, non alternativi. Esistono soluzioni che combinano entrambi (Kong Gateway + Kong Mesh, Istio Gateway), ma le due funzioni restano distinte concettualmente.
Per approfondimenti generali rimandiamo alla voce di API management su Wikipedia e al sito ufficiale di Kong, che offre tutorial gratuiti e documentazione tecnica di alto livello.
Hai bisogno di un’architettura API enterprise?
Brentasoft sviluppa architetture API custom con API Gateway (Kong, AWS, Azure) per PMI italiane: routing, rate limiting, monitoring, integrazioni multi-sistema.