Cloud & IT Cert Prep · Lezione

Regole dei listener e routing basato sul percorso

Scriverete regole del listener sull'ALB per instradare le richieste verso target group diversi in base agli header host, ai pattern dei percorsi o alle query string.

Regole dei listener e routing basato sul percorso è una lezione Cloud & IT Cert Prep gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cloud & IT Cert Prep, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.

Spiegazione dei listener ALB

Un listener ALB è un processo che verifica le richieste di connessione utilizzando un protocollo e una porta specificati (ad esempio HTTP sulla porta 80 o HTTPS sulla porta 443). Ogni listener dispone di una o più regole che determinano dove inoltrare le richieste in base al loro contenuto.

Un listener deve avere una regola predefinita (l'azione catch-all applicata quando nessun'altra regola corrisponde) e può avere fino a 100 regole aggiuntive. Le regole vengono valutate in ordine di priorità (il numero più basso indica la priorità più alta). Quando una richiesta soddisfa la condizione di una regola, viene applicata l'azione corrispondente e non vengono valutate ulteriori regole.

# Create an HTTP listener on port 80
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/default-tg/def456

Condizioni delle regole

Le regole del listener verificano le richieste in base a condizioni. È possibile combinare più condizioni in un'unica regola (tutte le condizioni devono essere soddisfatte affinché la regola venga applicata). Tipi di condizioni disponibili:

host-header: verifica l'header HTTP Host (ad esempio api.example.com)
path-pattern: verifica il percorso URL (ad esempio /api/*, /images/*.jpg)
http-header: verifica il nome e il pattern del valore di qualsiasi header HTTP
http-request-method: verifica i metodi HTTP (GET, POST, DELETE ecc.)
query-string: verifica le coppie chiave-valore nella stringa di query
source-ip: verifica gli intervalli CIDR degli IP client

Routing basato sul percorso

Il routing basato sul percorso indirizza le richieste verso target group diversi in base al percorso URL. È il pattern di routing più comune per i microservizi che si trovano dietro un singolo ALB. Esempio di regole su un ALB:

Il percorso è /api/* → Target Group: api-service
Il percorso è /images/* → Target Group: image-processor
Il percorso è /admin/* → Target Group: admin-app
Predefinito → Target Group: frontend-app

Questo consente a un singolo ALB di gestire più servizi distinti senza richiedere più load balancer, riducendo i costi e la complessità del DNS.

# Create a path-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789

Routing basato sull'host

Il routing basato sull'host instrada le richieste in base all'header HTTP Host, consentendo di servire più nomi di dominio (virtual host) tramite un singolo ALB. Esempio:

L'host è api.example.com → target group api-service
L'host è admin.example.com → target group admin-app
L'host è www.example.com → target group frontend

Ogni nome di dominio dispone di un record CNAME o ALIAS che punta allo stesso nome DNS dell'ALB, ma l'ALB instrada ciascuna richiesta verso il backend appropriato in base all'header host. Il routing basato sull'host è ideale per il SaaS multi-tenant o per applicazioni monolitiche che vengono suddivise in microservizi.

# Create a host-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 5 \
  --conditions '[{"Field":"host-header","HostHeaderConfig":{"Values":["api.example.com"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789"}]'

Azioni delle regole

Quando le condizioni di una regola corrispondono, l'ALB esegue una delle seguenti azioni:

forward: inoltra la richiesta a uno o più target group (con pesi opzionali)
redirect: restituisce un redirect HTTP (301 o 302) verso un nuovo URL; utile per i redirect da HTTP a HTTPS
fixed-response: restituisce una risposta HTTP statica con codice di stato, tipo di contenuto e corpo specificati; utile per pagine di manutenzione o semplici risposte ai controlli dello stato
authenticate-cognito: autentica gli utenti tramite un Cognito User Pool prima dell'inoltro
authenticate-oidc: autentica gli utenti tramite qualsiasi identity provider compatibile con OIDC

# Create a redirect rule: HTTP to HTTPS
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/http80 \
  --priority 1 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/*"]}}]' \
  --actions '[{"Type":"redirect","RedirectConfig":{"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Pattern di redirect da HTTP a HTTPS

Il pattern più comune per le regole dei listener consiste nel reindirizzare HTTP a HTTPS:

Creare un listener HTTP sulla porta 80 con una regola: reindirizzare tutto il traffico (/*) a HTTPS con codice di stato 301
Creare un listener HTTPS sulla porta 443 con le regole di routing effettive che puntano ai target group

In questo modo, gli utenti che digitano http:// o seguono vecchi link HTTP vengono reindirizzati a HTTPS in modo trasparente, senza modifiche a livello applicativo. Il redirect viene gestito interamente a livello di load balancer.

Azione di risposta fissa

L'azione fixed-response restituisce una risposta HTTP statica dall'ALB senza inoltrare la richiesta ad alcun target. Può essere utilizzata per:

restituire una pagina di manutenzione 503 per percorsi specifici durante la manutenzione
fornire un endpoint leggero per il controllo dello stato direttamente dall'ALB (restituisce immediatamente 200 OK senza sovraccaricare il backend)
bloccare percorsi specifici con una risposta 403 Forbidden

Le risposte fisse sono utili per disattivare temporaneamente alcuni percorsi senza modificare il codice dell'applicazione o eseguire nuovamente il deployment, modificando dinamicamente le regole del listener.

# Return 503 maintenance page for a specific path
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 20 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/checkout/*"]}}]' \
  --actions '[{"Type":"fixed-response","FixedResponseConfig":{"StatusCode":"503","ContentType":"text/html","MessageBody":"<h1>Maintenance</h1>"}}]'

Autenticazione ALB con Cognito

L'azione authenticate-cognito dell'ALB si integra con Amazon Cognito User Pools per gestire l'autenticazione degli utenti prima di inoltrare le richieste all'applicazione. Quando un utente non autenticato raggiunge una regola del listener protetta, l'ALB lo reindirizza all'interfaccia ospitata da Cognito per il login. Dopo l'autenticazione, l'ALB imposta un cookie crittografato e inoltra la richiesta con gli header relativi all'identità dell'utente.

In questo modo la logica di autenticazione viene completamente demandata all'esterno dell'applicazione. Il backend riceve gli header X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data e X-Amzn-Oidc-Access-Token contenenti le claim dell'utente autenticato.

Routing basato su query string e intestazioni

Le regole del listener ALB possono eseguire il routing in base ai parametri della query string e alle intestazioni HTTP, consentendo un routing delle richieste molto preciso:

Instradare i client mobili rilevando l'intestazione User-Agent: *Mobile* verso un backend ottimizzato per dispositivi mobili
Instradare le richieste API premium verificando l'intestazione personalizzata X-API-Tier: premium e inviandole a un gruppo di destinazione più veloce
Instradare le varianti di un test A/B leggendo il parametro della query string ?variant=beta

Il routing basato sulle intestazioni consente di implementare feature flag e suddivisione del traffico a livello dell'infrastruttura senza modificare il codice dell'applicazione.

Priorità delle regole e ordine di valutazione

Le regole vengono valutate in ordine crescente di priorità. I numeri di priorità più bassi vengono valutati per primi. Viene applicata l'azione della prima regola corrispondente e non vengono valutate altre regole. La regola predefinita non ha un numero di priorità e viene sempre valutata per ultima come regola generale.

Procedura consigliata: assegnate numeri di priorità con incrementi di 10 (10, 20, 30...) invece di utilizzare interi consecutivi. In questo modo lasciate spazio per inserire nuove regole tra quelle esistenti senza doverle rinumerare. Le regole più specifiche (ad esempio, con percorso + intestazione host) devono avere numeri più bassi (priorità maggiore) rispetto alle regole generiche.

# List rules for a listener (shows priorities)
aws elbv2 describe-rules \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --query 'Rules[*].{Priority:Priority,Conditions:Conditions[0].Field,Actions:Actions[0].Type}' \
  --output table

Regole del listener per i microservizi

Un singolo ALB può essere posto davanti a un'intera piattaforma di microservizi utilizzando le regole del listener. Ecco un esempio reale che combina tutti e tre i tipi di condizioni:

Priorità 10: Host=api.example.com + Path=/v2/* → gruppo di destinazione api-v2
Priorità 20: Host=api.example.com + Path=/v1/* → gruppo di destinazione api-v1
Priorità 30: Host=auth.example.com → gruppo di destinazione auth-service
Priorità 40: Host=www.example.com + Path=/static/* → reindirizzamento CloudFront
Predefinita: Host=www.example.com → gruppo di destinazione frontend

Questo design riduce i costi eliminando la necessità di utilizzare load balancer separati per ogni servizio.

Verifica rapida

Verificate la vostra comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

Riepilogo della lezione

In questa lezione avete imparato che: le regole del listener instradano le richieste in base a host, percorso, intestazioni, metodi e query string, le regole vengono valutate in ordine di priorità e vince la prima corrispondenza, mentre le azioni includono forward, redirect, fixed-response e autenticazione Cognito. Il routing basato su percorso e host consente a un singolo ALB di gestire più microservizi. Nel prossimo modulo esploreremo la terminazione SSL e le sessioni persistenti.

Domande Frequenti

La lezione «Regole dei listener e routing basato sul percorso» è gratuita?

Sì — il testo completo di «Regole dei listener e routing basato sul percorso» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cloud & IT Cert Prep, passa a CoddyKit PRO. Il corso Cloud & IT Cert Prep include 4 lezioni in totale.

Cosa imparerò in «Regole dei listener e routing basato sul percorso»?

Scriverete regole del listener sull'ALB per instradare le richieste verso target group diversi in base agli header host, ai pattern dei percorsi o alle query string. Eserciti Cloud & IT Cert Prep con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Cloud & IT Cert Prep?

Non è richiesta alcuna esperienza precedente. Cloud & IT Cert Prep su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Regole dei listener e routing basato sul percorso»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Cloud & IT Cert Prep?

Sì. Ogni lezione Cloud & IT Cert Prep include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

ALB vs NLB vs GLB: quale usare e quando
Target group e health check
Regole dei listener e routing basato sul percorso
Terminazione SSL e sessioni persistenti

← Torna a Cloud & IT Cert Prep