API Gateway: Kong, Traefik e AWS – Guida Operativa agli Schemi di Deploy per Microservizi

Il tuo microservizio parla solo HTTP? Ottimo. Ma quando ne hai cinque, dieci, cinquanta, devi decidere chi gestisce autenticazione, rate limiting, routing, logging. Se ogni servizio si arrangia, il tuo sistema diventa una giungla di duplicazioni e vulnerabilità. Noi ci siamo passati, e la risposta si chiama API Gateway.

In questa guida vediamo tre attori principali: Kong, Traefik e AWS API Gateway. Non ti raccontiamo quale sia il migliore in astratto: ti mostriamo come sceglierli in base al contesto, con pattern pronti per produzione.

Cos’è un API Gateway e perché ti serve

Un API Gateway è un punto di ingresso unico per tutte le chiamate ai tuoi microservizi. Gestisce autenticazione, rate limiting, routing, caching, trasformazione delle richieste/risposte. Senza, ogni servizio deve implementare da sé queste funzionalità: duplicazione di codice, rischi di sicurezza, difficoltà di manutenzione.

Noi, di Meteora Web, abbiamo lavorato su sistemi dove l’API Gateway ha ridotto del 40% il tempo di sviluppo di nuove feature: basta aggiungere un plugin al gateway invece di riscrivere logica in ogni servizio.

Il problema che risolve

Scenario tipico: hai un microservizio utenti, uno prodotti, uno ordini. Vuoi limitare a 100 richieste al minuto per utente, autenticare con JWT, loggare tutte le chiamate. Senza gateway: codice duplicato in tre servizi, con probabile deriva di versioni e bug. Con gateway: configuri tutto centralmente.

Errori comuni da evitare: pensare che il gateway sia solo un proxy. In realtà è il primo layer di difesa e il punto di controllo della tua architettura. Sbagliare la configurazione qui significa esporre tutto.

Kong: il cavallo di battaglia enterprise

Kong nasce come API Gateway open source basato su Nginx. Offre un ecosistema di plugin (autenticazione, rate limiting, trasformazione, logging) e un database (PostgreSQL o Cassandra) per la configurazione. È maturo, performante, utilizzato da aziende come Airbus, Samsung, Nasdaq.

Pattern di deploy consigliato per Kong

Kong si presta a due pattern principali: data-plane + control-plane (architettura ibrida) e standalone. Per produzione, consigliamo l’architettura ibrida con Kong Manager (UI) o Konga (UI open source) per gestire le route.

Esempio di configurazione di una route con rate limiting via Kong declarative config (decK):

_format_version: "3.0"
services:
  - name: user-service
    url: http://user-svc.internal:3000
    routes:
      - name: user-route
        paths:
          - /users
        methods:
          - GET
          - POST
        plugins:
          - name: rate-limiting
            config:
              minute: 60
              policy: local
          - name: key-auth
            config:
              key_names:
                - apikey

Come testarlo: dopo aver applicato con deck sync, chiama curl http://localhost:8000/users -H "apikey: your-key".

Vantaggi e limiti di Kong

• Vantaggi: maturità, plugin ricchi, gestione centralizzata, supporto DB per persistenza.
• Limiti: richiede database (manutenzione), configurazione via file dichiarativi può diventare complessa per team grandi.

Traefik: il gateway nativo per container e Kubernetes

Traefik nasce per ambienti cloud-native: rileva automaticamente i servizi da Docker, Kubernetes, Consul, etc. Si integra con Let's Encrypt per TLS, ha supporto nativo per middleware come rate limiting, autenticazione, retry. È pensato per essere configurabile via etichette (labels) o annotazioni Kubernetes.

Pattern di deploy con Docker Compose

Uno scenario molto comune: hai un'applicazione con microservizi in container, vuoi esporli tutti su una singola porta con routing basato su host o path.

version: '3.8'
services:
  traefik:
    image: traefik:v3.0
    command:
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"

  user-service:
    image: myuser-service:latest
    labels:
      - "traefik.http.routers.users.rule=Host(`api.example.com`) && PathPrefix(`/users`)"
      - "traefik.http.services.users.loadbalancer.server.port=3000"

  product-service:
    image: myproduct-service:latest
    labels:
      - "traefik.http.routers.products.rule=Host(`api.example.com`) && PathPrefix(`/products`)"
      - "traefik.http.services.products.loadbalancer.server.port=3001"

Con questo setup, Traefik rileva automaticamente i servizi e instrada le richieste. Aggiungiamo rate limiting:

labels:
  - "traefik.http.middlewares.ratelimit.ratelimit.average=100"
  - "traefik.http.middlewares.ratelimit.ratelimit.burst=50"
  - "traefik.http.routers.users.middlewares=ratelimit@docker"

Vantaggi e limiti di Traefik

• Vantaggi: zero configurazione iniziale, si integra con orchestrator, TLS automatico, dashboard integrata.
• Limiti: meno plugin rispetto a Kong, non ha una UI enterprise nativa, può essere meno performante in scenari ad altissimo carico rispetto a Kong su Nginx.

AWS API Gateway: il gestito per chi è già su AWS

AWS API Gateway è un servizio completamente gestito: niente server da mantenere, scalabilità automatica, integrazione nativa con Lambda, DynamoDB, Step Functions. Supporta REST e HTTP API (più leggere) e WebSocket.

Pattern: API Gateway + Lambda per microservizi serverless

In questo pattern, ogni endpoint è mappato a una funzione Lambda. AWS API Gateway gestisce autenticazione (Cognito, IAM, API key), rate limiting, caching, trasformazione.

Esempio di configurazione via CloudFormation (snippet):

Resources:
  ApiGateway:
    Type: AWS::ApiGateway::RestApi
    Properties:
      Name: MyAPI

  UsersResource:
    Type: AWS::ApiGateway::Resource
    Properties:
      ParentId: !GetAtt ApiGateway.RootResourceId
      PathPart: users
      RestApiId: !Ref ApiGateway

  UsersGetMethod:
    Type: AWS::ApiGateway::Method
    Properties:
      HttpMethod: GET
      ResourceId: !Ref UsersResource
      RestApiId: !Ref ApiGateway
      AuthorizationType: NONE
      Integration:
        Type: AWS_PROXY
        IntegrationHttpMethod: POST
        Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${UsersFunction.Arn}/invocations

Per rate limiting: si configura con Usage Plan e API Key.

Vantaggi e limiti di AWS API Gateway

• Vantaggi: zero gestione server, scalabilità infinita, nativo con AWS, WAF integrato.
• Limiti: vendor lock-in, costi a chiamata (per alto traffico può diventare caro), latenza aggiuntiva rispetto a self-hosted.

Come scegliere: pattern pratici

La scelta dipende dal tuo contesto. Ecco tre regole che usiamo noi di Meteora Web nei progetti:

1. Sei su Kubernetes e ami l'automazione? Vai con Traefik. È nato per questo.
2. Hai bisogno di controllo granulare, plugin enterprise e non ti spaventa gestire un database? Kong è la scelta.
3. Sei già tutto su AWS e vuoi serverless? AWS API Gateway è la via più semplice, ma tieni d'occhio i costi.

Esistono anche pattern ibridi: puoi usare Traefik come load balancer edge e Kong internamente per routing avanzato, oppure AWS API Gateway davanti a servizi self-hosted su ECS.

In sintesi — cosa fare

1. Valuta il tuo ecosistema: container, Kubernetes o serverless? Questa è la domanda guida.
2. Prova un proof-of-concept con due microservizi: deploya Kong con decK, Traefik con Docker Compose, oppure AWS API Gateway con Lambda.
3. Misura la latenza aggiunta: un gateway mal configurato può aggiungere 50-100 ms. Con i tuning giusti (connection pooling, caching) scendi sotto i 10 ms.
4. Non dimenticare la sicurezza: implementa autenticazione e rate limiting subito. È il minimo per andare in produzione.

Per approfondire l’architettura dei microservizi, leggi la nostra Guida Pillar ai Microservizi.