API Gateway e GDPR: Kong a 16/25, KrakenD a 0/25 [2026]

Scegliere un API gateway non è più solo una decisione tecnica sulle prestazioni. Nel 2026, con NIS2 in vigore in Italia e il Cyber Resilience Act che stringe i tempi ai fornitori software, quella scelta determina anche dove finiscono i dati dei tuoi utenti e chi può richiederne l’accesso. Kong, Apigee, MuleSoft, Azure API Management e AWS API Gateway dominano il mercato enterprise, ma KrakenD, Apache APISIX e Gravitee stanno guadagnando terreno proprio perché offrono un profilo di rischio giurisdizionale diverso. Questo confronto mette a nudo specifiche tecniche, benchmark di velocità, prezzi reali e il punteggio di esposizione al CLOUD Act statunitense per ciascuna piattaforma, con dati verificabili alla fonte.

Il tema non riguarda solo grandi banche o multinazionali. Ogni azienda che espone anche una sola API verso partner esterni, app mobile o integrazioni cloud si trova a dover rispondere alla stessa domanda: chi ha accesso ai log di traffico, dove vengono elaborate le richieste e sotto quale legge nazionale ricade il fornitore scelto. Le risposte cambiano parecchio a seconda che si scelga una piattaforma con sede a San Francisco o uno strumento open source mantenuto da una community europea, e questa differenza si vede tanto nella fattura mensile quanto nel questionario di conformità che un cliente enterprise può chiedere prima di firmare un contratto.

Cos’è un API gateway e perché la sicurezza dipende da questa scelta

Un API gateway è il punto d’ingresso unico attraverso cui passano le richieste dirette ai microservizi di un’applicazione. Gestisce autenticazione, rate limiting, instradamento del traffico e, sempre più spesso, anche il controllo degli accessi verso modelli linguistici e agenti AI. È il primo muro difensivo contro attacchi come broken authentication o data scraping massivo, e per questo compare in cima a ogni checklist di sicurezza applicativa.

La superficie d’attacco di un’azienda cresce con il numero di API esposte, e il gateway è il collo di bottiglia dove si può bloccare o lasciar passare un’intrusione. Un errore di configurazione qui non resta isolato: si propaga a tutti i servizi a valle. È il motivo per cui l’OWASP inserisce da anni la gestione scorretta delle API tra le cause ricorrenti di violazioni di dati su larga scala, un tema che avevamo già affrontato nel nostro confronto tra OWASP Top 10 e API Security Top 10.

Negli ultimi due anni il numero di API pubblicate da una singola azienda media è cresciuto molto più in fretta del numero di persone dedicate a proteggerle. Ogni team di sviluppo aggiunge endpoint per integrare un nuovo fornitore, collegare un’app mobile o esporre dati a un partner, e spesso lo fa senza passare da una revisione di sicurezza centralizzata. Il gateway diventa quindi anche uno strumento di governance: un posto unico dove applicare regole uguali per tutti, indipendentemente da quale squadra abbia scritto il codice del microservizio a valle.

Chi lavora con architetture a microservizi si trova quindi davanti a due strade. La prima porta verso le piattaforme enterprise nordamericane, mature e ricche di funzionalità. La seconda punta su alternative open source, spesso europee, pensate per chi vuole controllo diretto sull’infrastruttura e minore esposizione a normative extra-UE. Questo articolo confronta otto soluzioni concrete su specifiche, prestazioni, costi e conformità.

Gli otto gateway a confronto: chi sono i protagonisti

Kong Gateway, sviluppato da Kong Inc. con sede a San Francisco, è costruito su NGINX/OpenResty con un runtime di plugin in Lua. Esiste in versione open source e in versione enterprise (Konnect), quest’ultima con controllo remoto della control plane. Apigee, di proprietà Google, è pensato per grandi organizzazioni che già vivono nell’ecosistema Google Cloud e integra governance API di livello enterprise. MuleSoft Anypoint, sotto Salesforce, punta invece sull’integrazione applicativa oltre che sulla gestione API pura.

Sul fronte cloud nativo troviamo Azure API Management di Microsoft e AWS API Gateway di Amazon, entrambi pensati per chi opera già dentro quei rispettivi cloud pubblici. Sono comodi da attivare ma legano l’architettura al provider scelto. Azure API Management si distingue per i tier a consumo che permettono di partire gratis con il piano Developer, mentre AWS API Gateway è completamente serverless: non esiste un server da dimensionare, il servizio scala in automatico e la fattura segue esattamente il traffico reale, senza costi fissi quando non arrivano richieste.

Dall’altra parte del tavolo siedono le alternative open source. KrakenD, sviluppato in Spagna, è un gateway stateless pensato per l’aggregazione di richieste senza database esterno: legge la configurazione da un unico file dichiarativo e non mantiene stato tra un riavvio e l’altro, il che semplifica il deploy in container. Apache APISIX, progetto della Apache Software Foundation, gira su etcd e vanta un ecosistema di plugin molto ampio: secondo il blog ufficiale del progetto, alcuni dei suoi utenti più grandi lo eseguono su oltre 10.000 core CPU in produzione, come riportano gli stessi mantainer di Apache APISIX. Gravitee, con basi in Francia e Paesi Bassi, offre sia una versione self-hosted sia una gestita in cloud europeo, con un’architettura event-native pensata anche per proxy di flussi Kafka oltre alle classiche API REST. Tyk, gateway open-core britannico scritto in Go, completa il quadro con un dashboard di gestione integrato e un modello a licenza che permette di partire gratis e passare a un piano commerciale solo quando servono funzionalità avanzate come l’analytics multi-tenant.

Specifiche tecniche a confronto: la tabella completa

La tabella seguente riassume le caratteristiche strutturali di dieci soluzioni (includiamo anche Traefik, spesso citato nei benchmark indipendenti come riferimento). I dati su sede legale e punteggio di rischio CLOUD Act derivano dall’analisi pubblicata da Sota.io nell’agosto 2026, su una scala da 0 (nessuna esposizione) a 25 (massima esposizione).

Gateway	Sviluppatore	Sede legale	Licenza	Architettura	Punteggio CLOUD Act
Kong Gateway	Kong Inc.	Stati Uniti (Delaware)	Open source + Enterprise	NGINX/OpenResty, plugin Lua	16/25
Apigee	Google LLC	Stati Uniti (Delaware)	Proprietaria (managed)	Piattaforma cloud gestita	20/25
MuleSoft Anypoint	Salesforce Inc.	Stati Uniti (Delaware)	Proprietaria	Integration Platform as a Service	16-21/25 (fascia enterprise USA)
Azure API Management	Microsoft Corp.	Stati Uniti (Washington)	Proprietaria	Servizio gestito multi-tier	16-21/25 (fascia enterprise USA)
AWS API Gateway	Amazon.com Inc.	Stati Uniti (Delaware)	Proprietaria (pay-per-use)	Serverless, REST/HTTP/WebSocket	16-21/25 (fascia enterprise USA)
KrakenD	KrakenD (Devops Faith)	Spagna	Apache 2.0 (Community)	Stateless, senza database	0/25
Apache APISIX	Apache Software Foundation	Progetto Apache (no HQ unico)	Apache 2.0	Basato su etcd, plugin nativi	0/25
Gravitee	Gravitee.io	Francia / Paesi Bassi	Open source + Cloud EU	Event-native, self-host o cloud	2/25 (versione cloud)
Tyk	Tyk Technologies	Regno Unito	Open-core	Go, dashboard integrato	Non incluso nell’analisi Sota.io
Traefik	Traefik Labs	Francia	MIT (open source)	Reverse proxy cloud-native	Non incluso nell’analisi Sota.io

Il punteggio CLOUD Act misura quanto un fornitore, per via della propria sede legale statunitense, resta soggetto a richieste di accesso ai dati da parte di autorità USA anche quando i server fisici si trovano in Europa. Le tre alternative open source con sede fuori dagli Stati Uniti (KrakenD, Apache APISIX e Gravitee) evitano questo rischio quasi del tutto, come confermano i dati pubblicati da Sota.io.

OWASP API Security Top 10:2025: chi copre cosa

La revisione OWASP Top 10:2025, pubblicata a fine 2025, ha portato tre cambiamenti che toccano direttamente chi gestisce un API gateway. Il primo: A01:2025, Broken Access Control, resta al primo posto ma ora include esplicitamente le vulnerabilità BOLA (Broken Object Level Authorization) e BFLA (Broken Function Level Authorization), come riporta la documentazione ufficiale OWASP.

Broken Object Level Authorization, il rischio numero uno

Nella OWASP API Security Top 10:2025, API1 resta proprio la Broken Object Level Authorization: un utente autenticato riesce ad accedere a oggetti che non gli appartengono semplicemente modificando un identificativo nella richiesta. Un test su applicazioni web condotto da Kensai ha rilevato problemi di controllo degli accessi nel 94% delle applicazioni analizzate, secondo quanto pubblicato nella guida OWASP Top 10 2025 di Kensai. Un gateway ben configurato non elimina il problema da solo (la logica di autorizzazione resta compito del backend), ma può bloccare pattern di richieste anomale prima che raggiungano il servizio vulnerabile.

La configurazione errata è salita al secondo posto

A02:2025, Security Misconfiguration, è passata dal quinto al secondo posto rispetto all’edizione 2021, un salto che riflette quanto spesso gateway e proxy vengano lasciati con impostazioni predefinite insicure, CORS permissivi o TLS mal configurato. È qui che le piattaforme con community ampia e documentazione capillare, come Kong e Apache APISIX, offrono un vantaggio pratico: template di configurazione testati riducono il margine di errore umano. A03:2025, Software Supply Chain Failures, è invece una categoria completamente nuova e riguarda i plugin di terze parti che ogni gateway carica: più un ecosistema di estensioni è ampio, più vale la pena controllare la provenienza di ogni modulo installato, un tema che avevamo già trattato nel nostro approfondimento su audit di sicurezza cloud con Prowler e Trivy.

Sul fronte specifico delle API, la nuova OWASP API Security Top 10:2025 ha anche fuso due categorie precedenti (Excessive Data Exposure e Mass Assignment) in un’unica voce, API3:2025, Broken Object Property Level Authorization. Il cambiamento riflette una realtà tecnica precisa: molti endpoint restituiscono più campi di quanti il client ne debba vedere, oppure accettano in scrittura proprietà che l’utente non dovrebbe poter modificare, come un ruolo amministrativo nascosto in un payload JSON. Un gateway può contribuire filtrando gli schemi di risposta e convalidando lo schema delle richieste in ingresso, ma la responsabilità principale resta comunque nel codice applicativo che decide quali campi esporre e quali proteggere.

GDPR, NIS2, DORA e il rischio giurisdizionale del CLOUD Act

Il CLOUD Act statunitense del 2018 consente alle autorità USA di richiedere dati detenuti da aziende sotto giurisdizione americana, anche quando quei dati risiedono fisicamente su server europei. Per un’azienda italiana soggetta a GDPR, NIS2 o DORA questo crea una frizione legale reale: se il tuo API gateway è gestito da un’azienda con sede negli Stati Uniti, quella catena di responsabilità passa anche da lì.

L’analisi di Sota.io attribuisce ad Apigee un punteggio di 20 su 25, il più alto tra i grandi fornitori enterprise, motivato dalla partecipazione di Google a programmi come PRISM e dalla certificazione FedRAMP High, elementi che indicano un livello elevato di integrazione con le richieste governative statunitensi. Kong Enterprise si ferma a 16/25, penalizzato dal fatto che la control plane di Konnect gira su infrastruttura AWS nella regione us-east-1. Le alternative europee, invece, azzerano quasi del tutto questo fattore di rischio: KrakenD e Apache APISIX segnano 0/25, mentre Gravitee.io Cloud, grazie alla propria incorporazione franco-olandese, si ferma a un modesto 2/25.

Questo non significa che le piattaforme statunitensi siano automaticamente fuori norma: molte offrono region europee dedicate e clausole contrattuali standard. Significa però che, per chi deve rispondere a un audit NIS2 o dimostrare la minimizzazione del rischio secondo i principi del GDPR, la giurisdizione del fornitore del gateway è ormai una voce che compare nei questionari di due diligence, non un dettaglio tecnico secondario. Lo stesso ragionamento vale per chi ha già affrontato il confronto tra obblighi NIS2 e DORA nel proprio settore.

Il Cyber Resilience Act aggiunge un ulteriore livello di attenzione, perché impone requisiti di sicurezza by design anche ai componenti software che un’azienda integra da terze parti, gateway compreso. Un’organizzazione che documenta la propria catena di fornitura API, incluso il paese di incorporazione del vendor del gateway e il luogo fisico della control plane, arriva più preparata a un controllo dell’Agenzia europea per la cybersicurezza (ENISA) rispetto a chi scopre questi dettagli solo al momento dell’ispezione. Per i settori regolati, come sanità e servizi finanziari, questo tipo di mappatura preventiva sta diventando parte integrante del piano di gestione del rischio, non un esercizio facoltativo di compliance.

Benchmark di velocità: throughput e latenza in laboratorio

I numeri di velocità cambiano parecchio a seconda di chi pubblica il test e con quale hardware. Per questo motivo distinguiamo tra benchmark ufficiali dei singoli vendor, quasi sempre condotti nelle condizioni più favorevoli al proprio prodotto, e test indipendenti pubblicati da terze parti nel 2026.

Gateway	Richieste al secondo	Latenza p99	Fonte	Tipo
Kong Gateway (senza plugin)	127.257 RPS	7,11 ms	Documentazione ufficiale Kong	Vendor
Kong Gateway (rate limit attivo)	108.439 RPS	8,74 ms	Documentazione ufficiale Kong	Vendor
Apache APISIX (passthrough)	148.200 RPS	n.d.	Techoral, benchmark 2026	Indipendente
Kong 3.7 DB-less (passthrough)	112.400 RPS	n.d.	Techoral, benchmark 2026	Indipendente
Apache APISIX (4 worker)	~142.000 RPS	2,1 ms	Pistack, benchmark 2026	Indipendente
Kong (4 worker)	~104.000 RPS	3,4 ms	Pistack, benchmark 2026	Indipendente
Tyk (4 goroutine)	~72.000 RPS	4,8 ms	Pistack, benchmark 2026	Indipendente
KrakenD	~18.000 RPS (laptop standard)	<1 ms overhead	Documentazione ufficiale KrakenD	Vendor

Il pattern che emerge da fonti diverse è coerente: Apache APISIX tende a guidare la classifica di throughput puro nei test indipendenti, Kong resta competitivo e particolarmente solido quando servono centinaia di plugin enterprise attivi insieme, mentre KrakenD punta su un’altra metrica, la prevedibilità della latenza sotto carico costante, più che sul numero assoluto di richieste al secondo. Secondo il blog ufficiale di Kong, una configurazione di base del proprio gateway regge fino a 137.850 richieste al secondo con una latenza di 3,82 ms al 95° percentile, numero però auto-dichiarato e quindi da leggere come riferimento, non come garanzia in produzione.

Sul fronte della latenza sotto carico costante, un test pubblicato da Futurepicker nel giugno 2026 su hardware AWS c5.2xlarge (8 vCPU, 16 GB di RAM) ha misurato KrakenD a 50.000 richieste al secondo con una latenza mediana di 1,2 ms, contro i 12.000 req/s e 3,8 ms di Tyk nello stesso ambiente. Un’altra analisi, firmata Khimananda, ha confrontato l’overhead di latenza puro introdotto dal gateway stesso: meno di 0,5 ms al 99° percentile per KrakenD, tra 2 e 10 ms per Kong a seconda dei plugin attivi, e un intervallo compreso tra 20 e 100 ms per AWS API Gateway nei casi di cold start, il tempo di avvio a freddo tipico delle architetture serverless. Nessuno di questi numeri va preso come valore assoluto: hardware, numero di plugin attivi e dimensione del payload cambiano il risultato anche del 30-40% da un ambiente all’altro, motivo per cui ogni migrazione dovrebbe includere un test di carico condotto sul proprio traffico reale prima di fidarsi ciecamente di un benchmark pubblicato online.

Prezzi a confronto: dal gratuito ai contratti a sei cifre

Il costo totale di possesso di un API gateway raramente coincide con il prezzo di listino. Un gateway open source è gratuito da scaricare, ma richiede personale che lo gestisca, lo aggiorni e lo monitori. Un gateway enterprise costa di più a monte, ma include supporto, SLA e funzionalità pronte all’uso.

Gateway	Versione self-hosted	Versione enterprise/managed	Fonte
Kong Gateway	Gratuita (Apache 2.0)	Konnect Plus da circa 105 $/mese per servizio, contratti Enterprise 30.000-50.000 $/anno per implementazioni piccole	Zuplo, TCO analysis 2026
Apigee X	Non disponibile self-hosted	Ambiente di produzione base tra 6.000 e 9.000 $/mese, più costo per chiamata a partire da 3 $ ogni milione	NoSaveNoPay, pricing 2026
AWS API Gateway	Non applicabile (serverless)	3,50 $ per milione di richieste REST, 1,00 $ per milione di richieste HTTP API	Pagina ufficiale prezzi AWS
Azure API Management	Tier Developer gratuito (senza SLA produzione)	Tier Basic v2 da circa 0,21 $/ora, circa 150 $/mese per unità	Pagina ufficiale prezzi Azure
KrakenD	Gratuita (Community Edition)	Enterprise Edition su licenza commerciale, prezzo su richiesta	Sito ufficiale KrakenD
Apache APISIX	Gratuita (Apache 2.0)	Supporto enterprise tramite API7.ai, prezzo su richiesta	Apache APISIX / API7.ai
Gravitee	Gratuita (Community Edition)	Gravitee Cloud EU, prezzo su richiesta	Sito ufficiale Gravitee
Tyk	Gratuita (open-core)	Tyk Cloud e Self-Managed, prezzo su richiesta	Sito ufficiale Tyk

La differenza più netta riguarda il modello di fatturazione. AWS API Gateway e Apigee applicano un costo per singola chiamata, il che li rende convenienti a basso volume ma potenzialmente onerosi a scala (per esempio, superare i 300 milioni di richieste mensili su AWS fa scattare condizioni diverse rispetto al primo scaglione). Kong, KrakenD, Apache APISIX, Gravitee e Tyk seguono invece un modello a licenza o per nodo, più prevedibile quando il traffico cresce in modo aggressivo ma imprevedibile mese su mese.

Ai numeri di listino vanno sempre sommati i costi nascosti: il traffico di uscita (egress) fatturato separatamente dal cloud provider, i costi di osservabilità se non inclusi nel piano base, e il tempo del personale che scrive e mantiene le policy di sicurezza. Una PMI italiana con volumi contenuti spesso trova più conveniente partire da un gateway open source su una singola macchina virtuale, mentre un gruppo con decine di migliaia di richieste al secondo distribuite su più region ammortizza più facilmente il costo di un contratto enterprise, perché il supporto con SLA garantito riduce il rischio di downtime che, in caso di incidente, costa quasi sempre più della licenza stessa.

Cinque aziende che hanno già scelto (e perché)

I casi reali raccontano più di qualsiasi scheda tecnica. Ecco cinque esempi documentati di adozione nel 2025-2026.

• BMW ha adottato Kong per risolvere problemi di scalabilità e latenza di rete nella propria infrastruttura API, come indicato nella pagina dei Kong Innovator Awards 2025.
• United Airlines ha usato Kong Konnect per standardizzare e rendere scalabile la gestione di API e microservizi, secondo la stessa fonte.
• Siemens, premiata come Top Innovator per l’Europa nella stessa iniziativa, ha centralizzato l’esposizione governata di dati basati su eventi come API tramite Kong.
• Mercedes-Benz ha scelto Kong per la semplicità di configurazione su istanze sia piccole sia grandi, ottenendo una riduzione dell’85% nel carico operativo di gestione, come riportato dalla pagina prodotto ufficiale di Kong.
• Honor, produttore di smartphone, ha costruito il proprio gateway su Apache APISIX: entro fine anno la piattaforma supportava tutti i progetti di business dell’azienda, secondo il blog ufficiale del progetto Apache APISIX.
• Cashfree Payments, azienda di pagamenti digitali, è migrata su API7 Enterprise (basato su Apache APISIX) per gestire circa 6.000 transazioni al secondo e 280.000 consumer con un uptime del 99,99%, secondo il case study pubblicato da API7.

Il filo conduttore è chiaro: le grandi aziende automobilistiche e i vettori aerei che devono governare centinaia di microservizi legacy tendono a preferire l’ecosistema di plugin maturo di Kong, mentre le aziende che gestiscono volumi di traffico estremi con vincoli di costo per core scelgono più spesso Apache APISIX. Nessuno di questi casi documenta però l’adozione di alternative europee come KrakenD o Gravitee da parte di marchi altrettanto noti, un segnale che quelle piattaforme restano per ora più diffuse tra scale-up e aziende di medie dimensioni che tra le grandi multinazionali, complice anche una minore forza commerciale rispetto ai team enterprise di Kong o Google.

Pro e contro di ogni approccio

I giganti enterprise americani

Kong, Apigee, MuleSoft, Azure API Management e AWS API Gateway condividono alcuni vantaggi concreti: documentazione estesa, supporto contrattuale con SLA garantiti, integrazione nativa con l’AI Gateway per governare traffico verso modelli linguistici e un ecosistema di partner enormemente più ampio. Il rovescio della medaglia è la dipendenza dal fornitore (vendor lock-in), un profilo di rischio CLOUD Act più alto e, nel caso delle soluzioni completamente gestite, minore controllo diretto sull’infrastruttura sottostante in caso di incidente.

Le alternative open source ed europee

KrakenD, Apache APISIX, Gravitee e Tyk offrono codice ispezionabile, nessun costo di licenza per la versione community e, per le tre europee, un profilo di rischio giurisdizionale quasi nullo. Il compromesso è che serve competenza interna per operarli in produzione: senza un team che sappia gestire configurazione, aggiornamenti e osservabilità, il risparmio sulla licenza si trasforma in ore di lavoro extra per il reparto infrastruttura. APISIX in particolare richiede familiarità con etcd come archivio di configurazione distribuito, un requisito che allunga la curva di apprendimento iniziale.

C’è anche una differenza culturale tra i due gruppi che vale la pena notare. Le community open source europee tendono a rispondere alle segnalazioni di sicurezza tramite canali pubblici (issue tracker, mailing list), il che garantisce trasparenza ma anche tempi di risposta meno prevedibili di un contratto di supporto enterprise con SLA scritto nero su bianco. Chi opera in un settore dove un’ora di downtime costa migliaia di euro dovrebbe considerare questo fattore tanto quanto il prezzo della licenza, perché un incidente non gestito in tempo utile annulla in fretta qualsiasi risparmio ottenuto scegliendo la versione gratuita.

Quale API gateway scegliere in base al caso d’uso

• Startup con budget limitato e traffico moderato: KrakenD Community Edition o Apache APISIX. Zero costi di licenza, prestazioni solide e nessuna dipendenza da fornitori esterni.
• Azienda già radicata in AWS con carichi variabili: AWS API Gateway. Il modello serverless evita di dover dimensionare server per i picchi di traffico stagionali.
• Grande impresa con centinaia di microservizi legacy da governare: Kong Enterprise. L’ecosistema di plugin maturo copre casi d’uso che un team interno impiegherebbe mesi a replicare da zero.
• Organizzazione pubblica o sanitaria soggetta a GDPR stringente: Apache APISIX o Gravitee self-hosted in un data center europeo, per azzerare l’esposizione al CLOUD Act e mantenere i dati fisicamente e legalmente in UE.
• Azienda già su Google Cloud con esigenze di governance API complesse: Apigee, per l’integrazione nativa con l’ecosistema Google e le funzionalità di analytics incluse.
• Team che gestisce traffico verso modelli AI e agenti autonomi: Kong AI Gateway o Apache APISIX AI Gateway, entrambi con funzionalità dedicate al governo di token, caching semantico e controllo della spesa verso i provider LLM.
• Fintech soggetta a DORA con necessità di controllo diretto sull’infrastruttura: Tyk Self-Managed o Gravitee self-hosted, per mantenere piena visibilità operativa senza affidarsi a una control plane di terze parti.

Guida alla migrazione verso un altro gateway

Cambiare API gateway in produzione senza causare interruzioni richiede un approccio graduale. La sequenza che segue riflette la pratica comune per migrazioni da un gateway enterprise verso un’alternativa self-hosted.

I passaggi tecnici da seguire

• Mappa tutte le route esistenti. Esporta la configurazione attuale (plugin, policy di autenticazione, rate limit) prima di toccare qualsiasi cosa.
• Replica la configurazione in ambiente di staging. Traduci ogni plugin del vecchio gateway nell’equivalente della nuova piattaforma: l’autenticazione JWT, per esempio, ha implementazioni diverse tra Kong e KrakenD.
• Esegui un test di carico comparativo. Usa lo stesso strumento (per esempio wrk o k6) su entrambi i gateway con lo stesso traffico simulato, per validare i numeri di benchmark rispetto al tuo caso d’uso reale.
• Migra il traffico con un canary release. Instrada prima l’1-5% del traffico reale verso il nuovo gateway, monitorando tassi di errore e latenza per almeno 48 ore.
• Aumenta gradualmente la percentuale di traffico. Procedi a scaglioni (10%, 25%, 50%, 100%), mantenendo sempre la possibilità di rollback immediato al vecchio gateway.
• Verifica la compatibilità dei certificati e dei domini. Se il nuovo gateway termina il TLS con un certificato diverso, aggiorna in anticipo i pinning lato client e avvisa i partner che consumano le tue API con controlli di certificato rigidi.
• Aggiorna la documentazione e le chiavi di accesso dei partner esterni. Un cambio di gateway comporta spesso nuovi endpoint o nuovi formati di errore: comunica le modifiche con almeno due settimane di anticipo a chi consuma le API in produzione.
• Dismetti il vecchio gateway solo dopo un ciclo di fatturazione completo. Conserva i log del vecchio sistema per almeno 30 giorni, utili in caso di controversie o audit di conformità.

Un esempio minimo di configurazione di una route con autenticazione JWT su KrakenD, utile per confrontarla con l’equivalente plugin su Kong durante la fase di traduzione:

{
  "endpoint": "/api/utenti/{id}",
  "backend": [{ "url_pattern": "/utenti/{id}", "host": ["http://backend-interno:8080"] }],
  "extra_config": {
    "auth/validator": {
      "alg": "RS256",
      "jwk_url": "https://auth.example.it/.well-known/jwks.json",
      "cache": true
    }
  }
}

Chi arriva da un progetto Node.js gestito internamente può confrontare questo approccio dichiarativo con quanto descritto nella nostra guida su come costruire un API gateway sicuro in Node.js, utile come termine di paragone quando si valuta se affidarsi a un prodotto pronto all’uso o mantenere una soluzione custom.

Gli errori di configurazione più comuni

La maggior parte degli incidenti legati ai gateway non nasce da una falla nel software, ma da una configurazione lasciata a metà. Il primo errore ricorrente è il rate limiting assente o troppo permissivo su endpoint pubblici, che apre la porta a scraping massivo e attacchi di enumerazione. Il secondo è il CORS configurato con wildcard su domini di produzione, una scorciatoia comoda in fase di sviluppo che spesso sopravvive al deploy.

Il terzo errore riguarda le chiavi API con permessi eccessivi: una singola credenziale che apre l’accesso a tutte le route, invece di essere scoped ai soli endpoint necessari, trasforma una violazione minore in un incidente esteso. Il quarto è la mancata rotazione dei certificati TLS terminati sul gateway, spesso dimenticata perché la scadenza sembra lontana fino a quando non arriva. Il quinto errore, sempre più comune con la diffusione di funzionalità AI Gateway, è lasciare senza limiti di spesa le route che inoltrano richieste verso modelli linguistici esterni: senza un tetto sul numero di token o sul costo giornaliero, una chiave compromessa o un bug applicativo possono generare una bolletta fuori controllo in poche ore. Infine, molti team non monitorano i log del gateway in tempo reale: senza alert su pattern anomali di traffico, un attacco può proseguire per giorni prima di essere notato, un rischio che avevamo già descritto nel nostro pezzo su rate limiting e protezione delle API.

Il verdetto: chi vince, con i numeri alla mano

Non esiste un vincitore assoluto, ma tre scenari netti emergono dai dati raccolti. Per throughput puro in test indipendenti, Apache APISIX guida quasi sempre la classifica, con numeri tra 142.000 e 148.200 richieste al secondo a seconda del benchmark. Per copertura funzionale enterprise e maturità del supporto, Kong resta il riferimento, sostenuto da casi reali come BMW, United Airlines, Siemens e Mercedes-Benz. Per chi deve azzerare il rischio giurisdizionale sotto GDPR, NIS2 o DORA, KrakenD e Apache APISIX vincono con un punteggio CLOUD Act di 0/25 contro il 16-20/25 dei grandi fornitori statunitensi.

Se il tuo criterio principale è il costo totale a tre anni con traffico prevedibile, un’installazione self-hosted di KrakenD o Apache APISIX quasi sempre batte un contratto Apigee da 6.000-9.000 $ al mese. Se invece il tuo team non ha capacità interna per gestire infrastruttura critica H24, il prezzo più alto di una soluzione enterprise gestita compra tempo e riduce il rischio operativo. La scelta giusta dipende da quale rischio la tua organizzazione è più disposta ad accettare: quello di gestione interna, o quello giurisdizionale.

Vale la pena ribadire un punto pratico prima di chiudere: nessuno dei dati di questo confronto sostituisce un proof of concept condotto sulla tua architettura reale. I benchmark citati usano hardware, dataset e configurazioni di plugin diverse tra loro, e persino due test sullo stesso gateway possono divergere del 20-30% a seconda di quanti core CPU sono assegnati al processo. Prima di firmare un contratto pluriennale o migrare un servizio critico, il consiglio resta lo stesso da anni: testa con il tuo traffico, sul tuo hardware, per almeno una settimana, prima di fidarti di qualunque tabella comparativa, compresa questa.

Domande frequenti

Qual è la differenza principale tra Kong e KrakenD?

Kong usa un modello a plugin con database opzionale e un ecosistema enterprise molto ampio, mentre KrakenD è stateless, senza database esterno, pensato per aggregare più chiamate backend in un’unica risposta con overhead di latenza minimo.

Apache APISIX è davvero più veloce di Kong?

Nei benchmark indipendenti pubblicati da Techoral e Pistack nel 2026, Apache APISIX ha mostrato un throughput superiore a Kong in scenari di passthrough e con plugin di autenticazione attivi, ma la differenza si riduce con configurazioni enterprise complesse dove Kong offre più funzionalità pronte all’uso.

Un’azienda italiana soggetta a GDPR deve evitare per forza i gateway americani?

No, non è un obbligo automatico. Molti fornitori USA offrono region europee e clausole contrattuali standard che riducono il rischio. Il punteggio CLOUD Act è però un fattore che i team legali e di sicurezza devono considerare nella due diligence, specialmente per dati sanitari o finanziari.

Quanto costa gestire un API gateway open source in autonomia?

Il software è gratuito, ma il costo reale sta nel personale: infrastruttura, monitoraggio, aggiornamenti di sicurezza e supporto H24 richiedono almeno una persona dedicata part-time, oppure un contratto di supporto enterprise con il vendor del progetto open source.

Come si collega l’API gateway alla OWASP API Security Top 10:2025?

Il gateway può applicare policy di autenticazione, rate limiting e validazione dello schema che mitigano diversi rischi della classifica OWASP, ma non sostituisce controlli di autorizzazione a livello di oggetto che restano responsabilità del backend applicativo.

È possibile usare più gateway insieme nella stessa architettura?

Sì, è una pratica comune: un gateway edge (spesso Cloudflare o AWS API Gateway) gestisce il traffico pubblico globale, mentre un gateway interno come Kong o Apache APISIX instrada le richieste tra microservizi all’interno del cluster.

Quale gateway ha la community open source più attiva nel 2026?

Kong e Apache APISIX restano i progetti con il maggior numero di contributori e rilasci frequenti. APISIX, in particolare, viene usato in produzione da aziende che gestiscono oltre 10.000 core CPU, secondo quanto dichiarato dal team del progetto.

Serve per forza un API gateway se ho solo poche API interne?

Con un numero molto ridotto di endpoint interni, un reverse proxy semplice può bastare. Nel momento in cui compaiono autenticazione verso terze parti, requisiti di rate limiting per cliente o obblighi di audit trail, un API gateway dedicato riduce il lavoro manuale e centralizza i controlli di sicurezza in un unico punto verificabile.