Ascoltatori per Application Load Balancer

Un ascoltatore è un processo che controlla le richieste di connessione utilizzando il protocollo e la porta configurata. Prima di iniziare a utilizzare l'Application Load Balancer, è necessario aggiungere almeno un ascoltatore. Se il sistema di bilanciamento del carico non ha un ascoltatore, non può ricevere traffico dai client. Le regole che definisci per i tuoi listener determinano il modo in cui il load balancer indirizza le richieste verso le destinazioni registrate, ad esempio le EC2 istanze.

Configurazione dei listener

I listener supportano i seguenti protocolli e porte:

È possibile utilizzare un listener HTTPS per deviare il lavoro di crittografia e decrittografia per il sistema di bilanciamento del carico, in modo che le applicazioni possano concentrarsi sulla loro logica di business. Se il listener utilizza un protocollo HTTPS, è necessario distribuire almeno un certificato del server SSL sul listener. Per ulteriori informazioni, consulta Creazione di un ascoltatore HTTPS per Application Load Balancer.

Se devi assicurarti che siano le destinazioni a decrittare il traffico HTTPS al posto del sistema di bilanciamento del carico, è possibile creare un Network Load Balancer con un ascoltatore TCP sulla porta 443. Con un ascoltatore TCP, il sistema di bilanciamento del carico passa il traffico crittografato alle destinazioni senza decrittarlo. Per ulteriori informazioni, consulta la Guida per l'utente dei Network Load Balancer.

Gli Application Load Balancer forniscono supporto nativo per. WebSockets È possibile aggiornare una connessione HTTP/1.1 esistente in una connessione WebSocket (wsowss) utilizzando un aggiornamento della connessione HTTP. Quando si esegue l'aggiornamento, la connessione TCP utilizzata per le richieste (al sistema di bilanciamento del carico e alla destinazione) diventa una WebSocket connessione persistente tra il client e la destinazione tramite il sistema di bilanciamento del carico. È possibile utilizzare sia WebSockets i listener HTTP che HTTPS. Le opzioni scelte per il listener si applicano sia alle WebSocket connessioni che al traffico HTTP. Per ulteriori informazioni, consulta How the WebSocket Protocol Works nella Amazon CloudFront Developer Guide.

Gli Application Load Balancer forniscono supporto nativo per HTTP/2 con ascoltatori HTTPS. È possibile inviare fino a 128 richieste in parallelo utilizzando una sola connessione HTTP/2. È possibile utilizzare la versione del protocollo per inviare richieste alle destinazioni utilizzando HTTP/2. Per ulteriori informazioni, consulta Versione del protocollo. Poiché HTTP/2 utilizza connessioni front-end in modo più efficiente, si potrebbe notare un minor numero di connessioni tra i client e il sistema di bilanciamento del carico. Non è possibile usare la funzione server push di HTTP/2.

Per ulteriori informazioni, consulta Routing della richiesta nella Guida per l'utente di Elastic Load Balancing.

Attributi del listener

Di seguito sono riportati gli attributi del listener per Application Load Balancers

Regole dei listener

Ogni ascoltatore ha un'operazione predefinita, nota anche come regola predefinita. La regola predefinita non può essere eliminata ed è sempre eseguita per ultima. È possibile creare regole aggiuntive e consistono in una priorità, una o più operazioni e una o più condizioni. Puoi aggiungere o modificare le regole in qualsiasi momento. Per ulteriori informazioni, consulta Modificare una regola.

Regole predefinite

Le operazioni per la regola predefinita vengono definite al momento della creazione del listener. Le regole predefinite non possono avere condizioni. Se non viene soddisfatta nessuna condizione per qualsiasi regola del listener, viene eseguita l'operazione per la regola predefinita.

Di seguito è riportato un esempio di una regola predefinita come illustrato nella console:

Priorità regola

Ogni regola ha una priorità. Le regole vengono valutate in base all'ordine di priorità, dal valore più basso a quello più alto. La regola predefinita è valutata per ultima. È possibile modificare la priorità di una regola non predefinita in qualsiasi momento. Non è possibile modificare la priorità della regola di default. Per ulteriori informazioni, consulta Aggiornare la priorità delle regole.

Operazioni delle regole

Ogni operazione della regola dispone di un tipo, di una priorità e delle informazioni necessarie per eseguire l'operazione. Per ulteriori informazioni, consulta Tipi di operazioni delle regole.

Condizioni della regola

Ogni condizione della regola ha informazioni su tipo e configurazione. Quando le condizioni di una regola vengono soddisfatte, l'operazione viene eseguita. Per ulteriori informazioni, consulta Tipi di condizioni della regola.

Tipi di operazioni delle regole

I tipi di operazione supportati per una regola dell'ascoltatore sono i seguenti:

Viene eseguita per prima l'operazione con priorità minore. Ogni regola deve includere esattamente una delle seguenti operazioni: forward, redirect o fixed-response e deve essere l’ultima operazione da eseguire.

Se la versione del protocollo è gRPC o HTTP/2, le uniche operazioni supportate sono le operazioni forward.

Operazioni con risposta fissa

È possibile utilizzare le operazioni fixed-response per archiviare le richieste client e restituire una risposta HTTP personalizzata. È possibile utilizzare questa operazione per inviare un codice di risposta 2XX, 4XX o 5XX e un messaggio opzionale.

Quando viene eseguita un'operazione fixed-response, l'operazione e l'URL del target di reindirizzamento vengono registrate nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni fixed-response avvenute con successo viene segnalato dal parametro HTTP_Fixed_Response_Count. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

Operazioni di inoltro

È possibile utilizzare le operazioni forward per instradare le richieste a uno o più gruppi di destinazioni. Se si specificano più gruppi di destinazioni per un'operazione forward, è necessario specificare un peso per ciascun gruppo di destinazioni. Ogni peso del gruppo di destinazioni è un valore compreso tra 0 e 999. Le richieste che corrispondono a una regola del listener con gruppi di destinazioni ponderati vengono distribuite a questi gruppi di destinazioni in base ai rispettivi pesi. Ad esempio, se specifichi due gruppi di destinazioni, ciascuno con un peso di 10, ogni gruppo di destinazioni riceve la metà delle richieste. Se specifichi due gruppi di destinazioni, uno con un peso di 10 e l'altro con un peso di 20, il gruppo di destinazioni con un peso di 20 riceve il doppio delle richieste rispetto all'altro gruppo di destinazioni.

Per impostazione predefinita, la configurazione di una regola per distribuire il traffico tra gruppi di destinazioni ponderati non garantisce che le sticky session vengano rispettate. Per garantire che le sticky session siano rispettate, abilitare la persistenza del gruppo di destinazioni per la regola. Quando il load balancer indirizza per la prima volta una richiesta a un gruppo target ponderato, genera un cookie denominato AWSALBTG che codifica le informazioni sul gruppo target selezionato, crittografa il cookie e include il cookie nella risposta al client. Il client deve includere il cookie ricevuto nelle richieste successive al sistema di bilanciamento del carico. Quando il sistema di bilanciamento del carico riceve una richiesta che corrisponde a una regola con la persistenza del gruppo di destinazioni abilitata e contiene il cookie, la richiesta viene instradata al gruppo di destinazioni specificato nel cookie.

Gli Application Load Balancer non supportano i valori dei cookie codificati con URL.

Con le richieste CORS (cross-origin resource sharing), alcuni browser richiedono a SameSite=None; Secure di abilitare la stickness. In questo caso, Elastic Load Balancing genera un secondo cookie AWSALBTGCORS, che include le stesse informazioni dello stickiness cookie originale più questo attributo. SameSite I clienti ricevono entrambi i cookie.

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

Operazioni di reindirizzamento

È possibile utilizzare le operazioni redirect per reindirizzare le richieste client da un URL a un altro. È possibile configurare i reindirizzamenti come temporanei (HTTP 302) o permanenti (HTTP 301) in base alle esigenze.

Un URI è costituito dai componenti seguenti:

protocol://hostname:port/path?query

È necessario modificare almeno uno dei componenti seguenti per evitare un reindirizzamento loop: protocollo, nome host, porta o percorso. I componenti che non vengono modificati mantengono i loro valori originali.

È possibile riutilizzare i componenti URI dell'URL originale nell'URL di destinazione utilizzando le seguenti parole chiave riservate:

Quando viene eseguita un'operazione redirect, l'operazione viene registrata nei log di accesso. Per ulteriori informazioni, consulta Voci dei log di accesso. Il conteggio delle operazioni redirect avvenute con successo viene segnalato dal parametro HTTP_Redirect_Count. Per ulteriori informazioni, consulta Parametri di Application Load Balancer.

Esempio di operazioni di reindirizzamento tramite la console

Ad esempio, la regola seguente consente di configurare un reindirizzamento permanente a un URL che usa il protocollo HTTPS e la porta specificata (40443), ma mantiene il nome host, il percorso e i parametri di query originali. Questa schermata è equivalente a "https://#{host}:40443/#{path}?#{query}".

La regola seguente consente di configurare un reindirizzamento permanente a un URL che mantiene il protocollo, la porta, il nome host e i parametri di query originali e utilizza la parola chiave #{path} per creare un percorso modificato. Questa schermata è equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

Tipi di condizioni della regola

I tipi di operazione supportati per una regola sono i seguenti:

Ogni regola può facoltativamente includere al massimo una delle seguenti condizioni: host-header, http-request-method, path-pattern e source-ip. Ogni regola può anche includere facoltativamente una o più delle seguenti condizioni: http-header e query-string.

Puoi specificare fino a tre valutazioni di corrispondenze per condizione. Ad esempio, per ogni condizione http-header è possibile specificare fino a tre stringhe da paragonare al valore dell’intestazione HTTP nella richiesta. La condizione è soddisfatta se una delle stringhe corrisponde al valore dell’intestazione HTTP. Per fare in modo che tutte le stringhe siano una corrispondenza, crea una condizione per valutazione di corrispondenza.

Puoi specificare fino a cinque valutazioni di corrispondenze per regola. Ad esempio, puoi creare una regola con cinque condizioni in cui ogni condizione ha una valutazione di corrispondenza.

Nelel valutazioni di corripondenza è possibile includere caratteri jolly per le condizioni http-header,host-header, path-pattern e query-string. Esiste un limite di cinque caratteri jolly per regola.

Le regole vengono applicate solo ai caratteri ASCII visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.

Per le demo, consulta Instradamento avanzato delle richieste.

Condizioni nell'intestazione HTTP

Puoi usare le condizioni dell’intestazione HTTP per configurare le regole che instradano le richieste in base alle intestazioni HTTP per la richiesta. Puoi specificare i nomi dei campi delle intestazioni HTTP standard o personalizzate. Il nome dell'intestazione e la valutazione della corrispondenza non fanno distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati nelle stringhe di confronto: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere). I caratteri jolly non sono supportati nel nome dell’intestazione.

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

Condizioni del metodo di richiesta HTTP

Puoi usare le condizioni del metodo di richiesta HTTP per configurare le regole che instradano le richieste in base al metodo di richiesta HTTP della richiesta. Puoi specificare metodi HTTP standard o personalizzati. La valutazione della corrispondenza prevede la distinzione tra lettere maiuscole e minuscole. I caratteri jolly non sono supportati; pertanto, il nome del metodo deve essere una corrispondenza esatta.

Consigliamo di instradare le richieste GET e HEAD nello stesso modo, perché la risposta alla richiesta HEAD può essere inserita nella cache.

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Condizioni host

È possibile utilizzare le condizioni host per definire regole in grado di inoltrare le richieste in base al nome host nell'intestazione host (noto anche come instradamento basato su host). In questo modo è possibile supportare più sottodomini e domini di primo livello diversi utilizzando un singolo sistema di bilanciamento del carico.

Un nome host non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti:

Si deve includere il carattere "." almeno una volta. Dopo l'ultimo carattere "." è possibile includere solo caratteri alfabetici.

La regola *.example.com si applica a test.example.com ma non a example.com.

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Condizioni percorso

È possibile utilizzare le condizioni percorso per definire regole in grado di inoltrare le richieste in base all'URL nella richiesta (noto anche come instradamento basato su host).

Il modello di percorso viene applicato solo al percorso dell'URL, non ai suoi parametri di query. Viene applicato solo ai caratteri ASCII visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.

La valutazione della regola viene eseguita solo dopo la normalizzazione dell'URI.

Un modello di percorso non distingue tra maiuscole e minuscole, può avere una lunghezza massima di 128 caratteri e contenere qualsiasi carattere tra i seguenti.

Se la versione del protocollo è gRPC, le condizioni possono essere specifiche per un pacchetto, un servizio o un metodo.

Il modello di percorso viene utilizzato per instradare le richieste, ma non le modifica. Ad esempio, se una regola ha un modello di percorso /img/*, la regola inoltra una richiesta per /img/picture.jpg al gruppo target specificato come una richiesta per /img/picture.jpg.

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Condizioni delle stringhe di query

Puoi usare le condizioni delle stringhe di query per configurare le regole che instradano le richeste in base alle coppie chiave/valore o i valori nella stringa di query. La valutazione della corrispondenza non prevede la distinzione tra lettere maiuscole e minuscole. I seguenti caratteri jolly sono supportati: * (corrisponde a 0 o a più caratteri) e ? (corrisponde esattamente a 1 carattere).

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Condizioni indirizzo IP di origine

Puoi usare le condizioni dell’indirizzo IP di origine per configurare le regole che instradano le richieste in base all’indirizzo IP di origine della richiesta. L’indirizzo IP deve essere in formato CIDR. È possibile utilizzare entrambi IPv4 gli IPv6 indirizzi. I caratteri jolly non sono supportati. Non è possibile specificare il CIDR 255.255.255.255/32 come condizione della regola dell'IP di origine.

Se un client è al di là di un proxy, si tratta dell'indirizzo IP del proxy, non dell'indirizzo IP del client.

Questa condizione non è soddisfatta dagli indirizzi nell' X-Forwarded-Forintestazione. Per cercare gli indirizzi nell' X-Forwarded-Forintestazione, utilizza una http-header condizione.

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]

Intestazioni HTTP e Application Load Balancer

Le richieste e le risposte HTTP utilizzano i campi intestazione per inviare informazioni sui messaggi HTTP. Le intestazioni HTTP vengono aggiunte automaticamente. I campi intestazione sono costituti da coppie nome-valore separati da due punti e intervallati da un ritorno a capo e un avanzamento riga. Un insieme standard di campi dell'intestazione HTTP è definito nella RFC 2616 intestazioni di messaggi. Sono anche disponibili intestazioni HTTP non standard che vengono aggiunte automaticamente e sono ampiamente utilizzate dalle applicazioni. Alcune delle intestazioni HTTP non standard hanno un prefisso X-Forwarded. Gli Application Load Balancer supportano le seguenti intestazioni X-Forwarded.

Per ulteriori informazioni sulle connessioni HTTP, consulta Routing della richiesta nella Guida per l'utente di Elastic Load Balancing.

X-Forwarded-For

L'intestazione della richiesta X-Forwarded-For consente di identificare l'indirizzo IP di un client quando utilizzi un sistema di bilanciamento del carico HTTP o HTTPS. Poiché i sistemi di bilanciamento del carico intercettano il traffico tra client e server, i log di accesso al server contengono solo l'indirizzo IP del sistema di bilanciamento del carico. Per visualizzare l'indirizzo IP del client, utilizza l'attributo routing.http.xff_header_processing.mode. Questo attributo consente di modificare, mantenere o rimuovere l'intestazione X-Forwarded-For nella richiesta HTTP prima che Application Load Balancer la invii alla destinazione. I valori possibili per questo attributo sono append, preserve e remove. Il valore predefinito per questo attributo è append.

Append

Per impostazione predefinita, Application Load Balancer memorizza l'indirizzo IP del client nell'intestazione della richiesta X-Forwarded-For e passa l'intestazione al server. Se l'intestazione della richiesta X-Forwarded-For non è inclusa nella richiesta originale, il sistema di bilanciamento del carico ne crea una con l'indirizzo IP del client come valore della richiesta. In caso contrario, il load balancer aggiunge l'indirizzo IP del client all'intestazione esistente e quindi passa l'intestazione al server. L'intestazione della richiesta X-Forwarded-For può contenere più indirizzi IP separati da virgole.

L'intestazione della richiesta X-Forwarded-For assume la seguente forma:

X-Forwarded-For: client-ip-address

Di seguito è riportata un'intestazione della richiesta X-Forwarded-For di esempio per un client con l'indirizzo IP 203.0.113.7.

X-Forwarded-For: 203.0.113.7

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un indirizzo di. IPv6 2001:DB8::21f:5bff:febf:ce22:8a2e

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Quando l'attributo di conservazione della porta del client (routing.http.xff_client_port.enabled) è abilitato nel sistema di bilanciamento del carico, l'intestazione della richiesta X-Forwarded-For include il client-port-number aggiunto al client-ip-address, separato da due punti. L'intestazione assume così la seguente forma:

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number

IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

Si noti IPv6 infatti che quando il sistema di bilanciamento del carico aggiunge il client-ip-address all'intestazione esistente, racchiude l'indirizzo tra parentesi quadre.

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un IPv4 indirizzo e un numero di porta di. 12.34.56.78 8080

X-Forwarded-For: 12.34.56.78:8080

Di seguito è riportato un esempio di intestazione di X-Forwarded-For richiesta per un client con un IPv6 indirizzo 2001:db8:85a3:8d3:1319:8a2e:370:7348 e un numero di porta di. 8080

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Preserve

La modalità preserve nell'attributo garantisce che l'intestazione X-Forwarded-For nella richiesta HTTP non venga modificato in alcun modo prima di essere inviata alle destinazioni.

Rimuovi

La modalità remove nell'attributo rimuove l'intestazione X-Forwarded-For nella richiesta HTTP prima di inviarla alle destinazioni.

La tabella seguente mostra esempi dell'intestazione X-Forwarded-For che la destinazione riceve quando si seleziona la modalità append, preserve o remove. In questo esempio, l'indirizzo IP dell'ultimo hop è 127.0.0.1.

Per modificare, conservare o rimuovere il X-Forwarded-For intestazione utilizzando il AWS CLI

Usa il modify-load-balancer-attributescomando con l'routing.http.xff_header_processing.modeattributo.

X-Forwarded-Proto

L'intestazione della richiesta X-Forwarded-Proto consente di identificare il protocollo (HTTP o HTTPS) utilizzato da un client per connettersi al tuo load balancer. I log di accesso al server contengono solo il protocollo utilizzato tra il server e il load balancer; non contengono informazioni sul protocollo utilizzato tra il client e il load balancer. Per determinare il protocollo utilizzato tra il client e il load balancer, utilizzare l'intestazione della richiesta X-Forwarded-Proto. Elastic Load Balancing archivia il protocollo utilizzato tra il client e il load balancer nell'intestazione della richiesta X-Forwarded-Proto e passa l'intestazione al server.

La tua applicazione o il tuo sito Web può utilizzare il protocollo memorizzato nell'intestazione della richiesta X-Forwarded-Proto per eseguire il rendering di una risposta che reindirizza all'URL appropriato.

L'intestazione della richiesta X-Forwarded-Proto assume la seguente forma:

X-Forwarded-Proto: originatingProtocol

L'esempio seguente contiene un'intestazione della richiesta X-Forwarded-Proto per una richiesta originata dal client come richiesta HTTPS:

X-Forwarded-Proto: https

X-Forwarded-Port

L'intestazione della richiesta X-Forwarded-Port consente di identificare la porta di destinazione utilizzata dal client per connettersi al load balancer.