API Gateway per PMI 2022: Kong vs Tyk vs AWS API Gateway, scelta architetturale

Quando un’azienda inizia a esporre API verso clienti B2B, integrare partner via webhook, federare servizi cloud e suddividere il monolite in microservizi, qualcosa di apparentemente banale diventa centrale: il traffico HTTP smette di essere lineare. Ogni endpoint ha le sue logiche di autenticazione, rate limiting, logging, versioning, trasformazione del payload. Replicare queste logiche dentro ogni microservizio significa duplicare codice, divergere nelle policy di sicurezza e perdere visibilità sul comportamento del sistema. Da qui nasce il concetto di API gateway: un unico punto di ingresso che fa da vigile urbano per tutto il traffico applicativo, separando le responsabilità trasversali (cross-cutting concerns) dalla logica di business.

Nel 2022 l’API economy è un mercato maturo. Twilio, Stripe, Shopify, Salesforce hanno dimostrato che le API non sono un dettaglio tecnico ma un canale di vendita. Anche per una PMI italiana che fattura 5-20 milioni e gestisce un gestionale custom collegato a 3 marketplace, due partner logistici e un’app mobile, la domanda non è più “mi serve un API gateway?” ma “quale scelgo, come lo deployo, quanto mi costa nei prossimi 36 mesi?”. In questo articolo confrontiamo i tre candidati che oggi monopolizzano le shortlist tecniche: Kong Gateway, Tyk e AWS API Gateway. Analizziamo architettura, pricing, performance, ecosistema plugin, lock-in e maturità del developer portal, con un occhio sempre puntato al contesto PMI: budget contenuti, team piccoli, esigenza di non scrivere infrastruttura per il gusto di scriverla.

Cos’è davvero un API gateway (e cosa non è)

Un API gateway è un reverse proxy specializzato che si interpone fra i client (browser, app mobile, partner B2B, altri microservizi) e il backend. Ma confonderlo con un reverse proxy generico come NGINX standalone o HAProxy è un errore comune. Un reverse proxy classico instrada il traffico e bilancia il carico. Un API gateway aggiunge consapevolezza del protocollo API: parsing JSON, validazione OpenAPI, gestione di token OAuth 2.0 e JWT, rate limiting per consumatore, trasformazione di payload fra REST e gRPC, caching contestuale, exposing di metriche per endpoint.

Va distinto anche da due figure architetturali con cui spesso viene confuso. L’Enterprise Service Bus (ESB) degli anni 2000 — IBM WebSphere, Oracle Service Bus, TIBCO — implementava trasformazioni complesse, orchestration di processi business e routing basato su contenuto, ma era pensato per ambienti SOA legacy con XML e SOAP. L’API gateway moderno è più leggero, più focalizzato, e delega l’orchestration ai microservizi stessi. Il service mesh (Istio, Linkerd, Kuma) opera invece a livello di traffico est-ovest fra microservizi interni, mentre l’API gateway si occupa del traffico nord-sud, cioè ingressi esterni. I due strumenti convivono: gateway al perimetro, mesh dentro al cluster.

Le sette responsabilità di un API gateway

Prima di scegliere uno strumento serve un check sulle responsabilità che dovrà coprire. Non tutti i gateway le implementano allo stesso modo, e alcune diventano fattori discriminanti.

1. Routing dinamico: mapping fra URL pubblici (api.azienda.it/v2/orders) e servizi interni (orders-svc.prod.svc.cluster.local). Deve supportare path matching, host matching, header matching.
2. Autenticazione e autorizzazione: validazione di chiavi API, JWT firmati, token OAuth 2.0 con introspection, mTLS per traffico machine-to-machine. Idealmente con delega a un Identity Provider esterno (Auth0, Keycloak, Okta).
3. Rate limiting e quota: limiti per IP, per consumer, per piano (free/pro/enterprise), per endpoint. Sliding window, token bucket, distribuito su più nodi gateway.
4. Trasformazione richieste/risposte: riscrittura header, rimozione campi sensibili dalle risposte, conversione fra formati (REST in ingresso, gRPC verso backend), aggregazione di chiamate per BFF (Backend For Frontend).
5. Caching: caching delle risposte GET a livello edge per ridurre carico sul backend, con invalidazione per tag o per evento.
6. Observability: metriche Prometheus, trace distribuiti via OpenTelemetry, log strutturati JSON spediti a un’aggregator (Loki, Elasticsearch, Datadog).
7. Developer portal: documentazione OpenAPI auto-generata, self-service per registrazione applicazioni e generazione chiavi, sandbox per testing.

Se hai più di 5 microservizi o stai per superare i 50 endpoint pubblici, queste responsabilità diventano critiche e replicarle a mano in ogni servizio non è più sostenibile. È a questo punto che un API gateway non è un nice-to-have ma un requisito infrastrutturale.

Kong Gateway: il colosso open source diventato piattaforma

Kong nasce nel 2015 come fork specializzato di OpenResty (NGINX + Lua) e in pochi anni diventa de facto lo standard open source per API gateway. La release 2.8 di febbraio 2022 consolida il supporto a gRPC, le policy di routing basate su header e il pacchetto di plugin Enterprise. L’architettura è semplice: un control plane (database PostgreSQL o configurazione dichiarativa via YAML) e un data plane stateless che processa il traffico. Si scala orizzontalmente aggiungendo nodi data plane dietro un load balancer.

Il vero asset di Kong è l’ecosistema plugin. Su Kong Hub trovi oltre cento plugin ufficiali e community: rate limiting (locale, Redis, cluster), OAuth 2.0, JWT validation, IP restriction, request transformer, Prometheus, Datadog, OpenTelemetry, ACL, response rate limiting, bot detection. Se ti manca qualcosa scrivi un plugin in Lua o, dalla versione 2.x, in Go o Python via PDK. Per una PMI questo si traduce in libertà operativa: nessun vendor lock-in, nessun rebuild dell’architettura se cambi cloud provider.

Sul fronte pricing nel 2022 lo scenario è il seguente. Kong Gateway OSS è gratuito a vita, anche per uso commerciale. Kong Enterprise (con RBAC granulare, developer portal commerciale, vitals analytics, plugin enterprise come Mocking e GraphQL rate limiting) è in vendita con quote a partire da circa 25-50k euro/anno per le piccole installazioni. Kong Konnect, l’offerta SaaS lanciata in beta nel 2021 e GA nel 2021, parte da circa $250 per utente al mese sul piano Plus, con consumo nodi gateway separato. Per molte PMI italiane il sweet spot resta Kong OSS self-hosted su Kubernetes managed (EKS, GKE, AKS): costo cloud pulito, zero licenze, controllo totale.

Lato performance Kong gestisce facilmente 10-20k richieste al secondo per nodo su hardware modesto (2 vCPU, 4 GB RAM), con latenza overhead nell’ordine dei 2-5 millisecondi. Per la maggior parte delle PMI italiane, un cluster di 2-3 nodi è abbondantemente sovradimensionato.

Tyk: l’alternativa pragmatica con dashboard inclusa

Tyk è il principale challenger di Kong nel mondo open source. Scritto in Go (Kong è Lua su NGINX), ha un footprint memoria più contenuto e un avvio più rapido. Tyk Gateway è open source (Mozilla Public License) e include nativamente molte funzionalità che Kong distribuisce come plugin separati: rate limiting per chiave, quotas, transformation middleware, version routing, blueprint OpenAPI, analytics in-memory. Per chi non ama mettere insieme un mosaico di plugin, questa integrazione verticale ha il suo fascino.

L’offerta commerciale del 2022 si articola in tre piani. Tyk Self Managed è la versione enterprise on-premise o cloud privato, con dashboard avanzata, sviluppatore portal, multi-tenancy, RBAC, MDCB (Multi Data Center Bridge). I prezzi pubblicati partono da circa $600 al mese per ambienti small. Tyk Cloud è il SaaS multi-region, con piano Launch a partire da poche centinaia di dollari al mese e scaling fino al piano Enterprise. Tyk Open Source resta gratuito e include gateway, dashboard community e developer portal community.

Il punto forte per PMI è proprio la dashboard inclusa nell’OSS. Kong OSS non ha dashboard ufficiale (esistono Konga e Kong Manager community, ma con limiti), Tyk sì. Significa che un team di 2 dev può configurare API, chiavi, policy senza scrivere YAML, riducendo l’onboarding di settimane. L’observability è solida: integrazione nativa con MongoDB o Redis per analytics, export Prometheus, plugin per Datadog e New Relic.

Punto debole: ecosistema più piccolo. La community Tyk è circa un quarto di quella Kong in termini di estensioni third-party, quindi se il tuo caso d’uso richiede plugin esotici potresti dover scriverteli. Su gRPC, GraphQL e WebSocket Tyk era nel 2022 ancora qualche passo indietro rispetto a Kong, ma con copertura sufficiente per la maggior parte delle PMI.

AWS API Gateway: zero ops, lock-in totale

AWS API Gateway è il servizio managed più diffuso in assoluto, semplicemente perché chi è già su AWS lo trova a portata di click. Nel 2022 esistono tre varianti: REST API (la più ricca, con caching nativo, validation OpenAPI, WAF integration, API keys, usage plans), HTTP API (più snella e più economica, ottimizzata per JWT/OIDC e Lambda proxy), WebSocket API (per real-time bidirectional). La differenza di costo è significativa: REST API costa $3,50 per milione di chiamate, HTTP API costa $1,00 per milione, oltre al data transfer.

Per una PMI con 50 milioni di chiamate al mese su HTTP API si parla di circa $50 di gateway puro più il traffico. Su REST API gli stessi volumi diventano $175. Aggiungendo CloudWatch logs, X-Ray tracing, WAF rules e Cognito user pools si arriva facilmente a $200-500/mese per ambienti production. Lo zero-ops ha un prezzo, ma se metti sul piatto i costi nascosti di gestire un cluster Kong (Kubernetes, monitoring, patching, on-call), per volumi piccoli e medi AWS può essere competitivo.

I vantaggi sono evidenti: nessuna infrastruttura da patchare, integrazione nativa con Lambda (proxy integration), Cognito per autenticazione, IAM per autorizzazione machine-to-machine, WAF per protezione applicativa, X-Ray per tracing, CloudWatch per metriche, Step Functions per orchestrazione. Se il backend è già una collezione di Lambda + DynamoDB + S3, AWS API Gateway è la scelta obbligata.

Lo svantaggio è altrettanto evidente: lock-in. La configurazione è AWS-specific (Swagger esteso con x-amazon-apigateway-*), i plugin sono limitati a quanto AWS espone, la portabilità verso GCP o Azure è praticamente nulla senza una riscrittura completa. Per PMI con strategia multi-cloud o con timore di future migrazioni, questo è un fattore bloccante.

Confronto tabellare: Kong vs Tyk vs AWS

Scegliere in base al contesto PMI

Le decisioni non si prendono leggendo solo le feature matrix. Ecco tre profili tipici di PMI italiana e la scelta consigliata.

Profilo A — SaaS B2B in crescita, 8-12 microservizi su Kubernetes, multi-cloud strategy. L’azienda eroga un software gestionale con API pubbliche consumate da 50 clienti enterprise, ha un team DevOps di 3 persone e un budget cloud di circa 4-6k euro/mese. Qui Kong Gateway OSS self-hosted è la scelta ottimale: portabilità totale, plugin ecosystem ricco, possibilità di estendere in Go o Lua. Si parte gratis con la versione OSS, si aggiunge Konnect o Enterprise solo quando il developer portal e l’RBAC granulare diventano effettivamente bloccanti. Costo realistico: 200-400 euro/mese di compute Kubernetes per il cluster gateway.

Profilo B — PMI manifatturiera con e-commerce headless, 4-6 servizi, budget contenuto. Team di 2 sviluppatori full-stack, no DevOps dedicato, esigenza di dashboard self-service per partner che consumano API ordini e stock. Qui Tyk OSS è il sweet spot: dashboard inclusa, configurazione meno verbosa di Kong, footprint ridotto. Si può fare partire un cluster a 2 nodi su VPS economici (Hetzner, OVH) per circa 50-80 euro/mese. Se in futuro emerge il bisogno di multi-region o RBAC, l’upgrade a Tyk Cloud è graduale.

Profilo C — Startup serverless full AWS, backend interamente Lambda + DynamoDB. Niente Kubernetes in casa, niente desiderio di averlo. Qui AWS API Gateway HTTP API è la scelta obbligata: integrazione nativa con Lambda proxy, Cognito user pools, WAF, X-Ray. Si parte con poche decine di euro/mese, si scala in modo predicibile. L’unica accortezza è isolare la business logic dal binding al gateway: usare schemi OpenAPI standard e una struttura di handler portabile, così che un’eventuale migrazione futura sia ipotizzabile senza riscrittura totale.

Sicurezza: OAuth 2.0, JWT, mTLS

La sicurezza è il caso d’uso numero uno per cui le PMI introducono un API gateway. Esporre direttamente i microservizi a Internet senza un layer di autenticazione centralizzato è un rischio sistemico: ogni servizio implementa la propria validazione, e ogni divergenza è un buco potenziale. Il gateway centralizza la validazione del token e passa al backend l’identità già verificata.

I tre pattern dominanti nel 2022 sono: API keys per scenari B2B semplici (chiave statica per partner, rate limit per chiave); JWT bearer tokens firmati da un Identity Provider esterno con chiavi pubbliche distribuite via JWKS endpoint (il gateway valida la firma senza chiamare l’IdP a ogni richiesta); OAuth 2.0 con introspection per scenari che richiedono revoca immediata dei token (il gateway chiama l’IdP per validare a runtime, con caching aggressivo per non saturare). Per traffico machine-to-machine fra servizi interni o partner fidati, mTLS è la scelta più robusta: certificato client validato dal gateway, identità derivata dal subject del certificato.

Tutti e tre i gateway supportano questi pattern. Kong lo fa via plugin (key-auth, jwt, oauth2, mtls-auth), Tyk via middleware nativi configurabili da dashboard, AWS via Lambda authorizer custom o integrazione diretta con Cognito. Su mTLS AWS API Gateway ha aggiunto il supporto nel 2020, Kong e Tyk lo offrono da anni. Il vero discriminante è la facilità di rotazione dei segreti: Kong e Tyk si integrano con Vault per il key management dinamico, AWS si appoggia a Secrets Manager. Per una PMI con compliance ISO 27001 o requisiti contrattuali su rotazione chiavi ogni 90 giorni, questa integrazione fa la differenza.

Service mesh: quando serve davvero

Una domanda ricorrente in fase di scelta è: ho bisogno anche di un service mesh? La risposta breve: probabilmente no, almeno non subito. Il service mesh (Istio, Linkerd, Kuma) gestisce il traffico est-ovest fra microservizi interni, aggiungendo mTLS automatico, retry policy, circuit breaker, traffic shifting per canary release. È una mannaia potente, ma complessa: Istio richiede competenze Kubernetes avanzate e introduce un overhead operativo significativo.

Per una PMI con meno di 15 microservizi e traffico interno gestibile, un API gateway perimetrale è sufficiente. Il service mesh entra in gioco quando si superano i 30-50 servizi, quando si ha bisogno di policy di rete fine-grained per compliance, quando si fanno deploy canary frequenti. Kong ha la sua proposta integrata (Kong Mesh, basato su Kuma) che semplifica la convivenza fra gateway e mesh con un control plane unico. Tyk si integra con Istio. AWS offre App Mesh, ma con adozione più limitata rispetto alle alternative open source.

Errori comuni da evitare

Dopo aver visto decine di rollout di API gateway in PMI italiane, ecco i cinque errori che si ripetono più spesso.

1. Over-engineering iniziale. Partire con un cluster Kong multi-region quando hai 3 microservizi e 50 richieste al minuto è un suicidio operativo. Inizia con un nodo, scala quando serve.
2. Nessuna strategia di versioning. Esporre /api/orders senza /v1/ è una bomba a orologeria: quando dovrai rompere la retrocompatibilità sarai costretto a forzare tutti i client. Usa /v1/ dal primo giorno.
3. Logiche di business dentro al gateway. Trasformazioni complesse, orchestration di chiamate multiple, calcoli su payload appartengono ai microservizi (o a un BFF dedicato), non al gateway. Il gateway deve restare sottile.
4. Nessuna API governance. Lasciare che ogni team esponga endpoint come vuole, senza naming convention né schemi OpenAPI, porta in 18 mesi a un catalogo ingestibile. Imponi linting OpenAPI in CI fin dal primo endpoint.
5. Mancanza di observability. Senza metriche per endpoint (latenza, error rate, traffico), il gateway è una scatola nera. Configura Prometheus, Grafana e alerting prima del go-live in produzione, non dopo.

Roadmap di implementazione 90 giorni

Per una PMI che parte da zero, un rollout sostenibile di API gateway si articola in tre fasi da circa 30 giorni ciascuna.

Giorni 1-30 — Discovery e proof of concept. Inventario degli endpoint esistenti, definizione di naming convention, scrittura degli schemi OpenAPI mancanti. Setup di un ambiente non-production con il gateway scelto, migrazione di 2-3 endpoint pilota. Configurazione di authentication base (API keys o JWT) e rate limiting elementare. Output atteso: gateway funzionante in dev, documentazione OpenAPI per gli endpoint pilota, metriche Prometheus esposte.

Giorni 31-60 — Hardening e migrazione progressiva. Migrazione del 50-70% degli endpoint dietro al gateway, configurazione observability completa (Grafana dashboards, alerting su error rate ed SLO di latenza), definizione di RBAC per il team. Onboarding del primo partner B2B su developer portal. Test di carico per validare capacità del cluster gateway.

Giorni 61-90 — Go-live e governance. Cutover finale in produzione, deprecazione dei vecchi endpoint diretti, pubblicazione del developer portal pubblico. Definizione del processo di API change management (RFC per breaking changes, periodo di deprecation di almeno 6 mesi). Retrospettiva e definizione di SLO/SLA per ogni API esposta.

Come implementare un API gateway in 5 passi

1. Inventario e schemi OpenAPI: censisci tutti gli endpoint esistenti e produci o aggiorna gli schemi OpenAPI 3.0/3.1. Senza questa base nessuno strumento ti salverà.
2. Scelta del gateway: applica il framework persona (cloud-agnostic, budget OSS, AWS-native) per filtrare le opzioni, poi prova due candidati su un POC di 2 settimane.
3. Setup ambiente non-production: deploy del gateway su staging, integrazione con IdP, configurazione di un primo subset di endpoint pilota.
4. Migrazione progressiva: sposta endpoint dietro al gateway in batch settimanali, validando metriche e error rate dopo ogni batch.
5. Go-live e governance: cutover produzione con feature flag, deprecation dei vecchi endpoint, processo formale per future API change.

FAQ — Risposte alle domande più frequenti

Posso usare NGINX al posto di un API gateway?

NGINX standalone risolve routing e load balancing, ma non gestisce nativamente OAuth 2.0, rate limiting per consumer, developer portal, observability per endpoint. Per scenari semplici (1-2 servizi, niente auth complessa) può bastare. Sopra i 5 servizi o con esigenze B2B serie, un API gateway dedicato fa risparmiare mesi di lavoro custom.

Kong Konnect vale i $250 per utente al mese?

Konnect ha senso se non vuoi gestire il control plane Kong in casa e hai esigenza di governance multi-team (più gruppi di sviluppatori che gestiscono API separate). Per team singoli o piccoli, Kong OSS self-hosted resta più conveniente.

Tyk Cloud o Tyk Self Managed?

Tyk Cloud è la scelta giusta se non hai un team operations dedicato e accetti latenze leggermente maggiori per la natura SaaS. Self Managed conviene se hai requisiti di data residency stringenti (per esempio, dati che non possono uscire dall’UE) o se vuoi performance ottimali in colocation con il backend.

Quanto costa davvero AWS API Gateway?

Per una PMI con 30-50 milioni di chiamate al mese su HTTP API si parla di $30-50 di gateway puro, più data transfer (variabile, tipicamente $50-150), più CloudWatch e X-Ray se attivati ($30-80). Conto totale realistico: $150-300/mese all-inclusive.

Posso passare da AWS API Gateway a Kong in futuro?

Tecnicamente sì, ma il costo è proporzionale a quanta logica AWS-specific hai messo nelle configurazioni (Lambda authorizer, integrations dirette con servizi AWS, schemi Swagger estesi). Se mantieni schemi OpenAPI standard e handler Lambda portabili, la migrazione è fattibile in 2-3 mesi. Altrimenti è una riscrittura.

Serve un API gateway anche per API solo interne?

Se le API sono consumate solo da altri microservizi interni e non hai esigenze di rate limiting o auth centralizzata, un service mesh può bastare. Il gateway diventa necessario quando l’API è esposta verso client esterni o quando vuoi un unico punto di policy enforcement.

Quanto tempo serve per il rollout in una PMI?

Con un team di 2-3 sviluppatori e un perimetro di 10-15 endpoint, una roadmap realistica è 60-90 giorni dal POC al go-live, includendo definizione di OpenAPI mancanti, setup observability, migrazione progressiva e onboarding del developer portal. Tempi inferiori sono possibili solo se gli schemi OpenAPI sono già completi e maturi.