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 alle destinazioni registrate, ad esempio le EC2 istanze.

Configurazione dei listener

I listener supportano i seguenti protocolli e porte:

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

Se devi assicurarti che le destinazioni decrittografino il HTTPS traffico anziché il load balancer, puoi creare un Network Load Balancer con TCP un listener sulla porta 443. Con un TCP listener, il load balancer trasmette il traffico crittografato alle destinazioni senza decrittografarlo. 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 WebSocket (wsowss) connessione utilizzando un HTTP aggiornamento della connessione. Quando si esegue l'aggiornamento, la TCP connessione 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 con gli ascoltatori che con gli HTTP ascoltatoriHTTPS. Le opzioni che scegli per il tuo listener si applicano sia alle WebSocket connessioni che al HTTP traffico. 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 listener. HTTPS È possibile inviare fino a 128 richieste in parallelo utilizzando una connessione HTTP /2. È possibile utilizzare la versione del protocollo per inviare la richiesta alle destinazioni utilizzando /2. HTTP Per ulteriori informazioni, consulta Versione del protocollo. Poiché HTTP /2 utilizza le connessioni front-end in modo più efficiente, potresti notare un minor numero di connessioni tra i client e il sistema di bilanciamento del carico. Non è possibile utilizzare la funzionalità server-push di /2. HTTP

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

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 è g RPC o HTTP /2, le uniche azioni supportate sono forward le azioni.

Operazioni con risposta fissa

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

Quando viene intrapresa un'fixed-responseazione, l'azione e la destinazione URL del 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. URL

Con le richieste CORS (condivisione di risorse tra origini), alcuni browser richiedono SameSite=None; Secure l'attivazione della viscosità. 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 redirect le azioni per reindirizzare le richieste dei client da una all'altraURL. Puoi configurare i reindirizzamenti come temporanei (HTTP302) o permanenti (HTTP301) in base alle tue esigenze.

A URI è costituito dai seguenti componenti:

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 URI i componenti dell'originale URL nella destinazione URL 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

La regola seguente imposta un reindirizzamento permanente a un URL che utilizza il HTTPS protocollo 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 imposta 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 per creare un percorso modificato. #{path} 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 http-header condizione, puoi specificare fino a tre stringhe da confrontare con il valore dell'HTTPintestazione 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 ASCII caratteri visibili; i caratteri di controllo (da 0x00 a 0x1f e 0x7f) sono esclusi.

Per le demo, consulta Instradamento avanzato delle richieste.

HTTPcondizioni dell'intestazione

È possibile utilizzare le condizioni di HTTP intestazione per configurare le regole che instradano le richieste in base alle HTTP intestazioni della richiesta. È possibile specificare i nomi dei campi di HTTP intestazione standard o personalizzati. 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*"]
      }
  }
]

HTTPcondizioni del metodo di richiesta

È possibile utilizzare le condizioni del metodo di HTTP richiesta per configurare le regole che instradano le richieste in base al HTTP metodo di richiesta della richiesta. È possibile specificare HTTP metodi 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.

È consigliabile effettuare l'instradamento GET e HEAD le richieste nello stesso modo, poiché la risposta a una HEAD richiesta può essere memorizzata 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 del percorso per definire regole che instradano le richieste in base a quanto URL contenuto nella richiesta (noto anche come routing basato sul percorso).

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

La valutazione della regola viene eseguita solo dopo la normalizzazione. 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 di un pacchetto, servizio o 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 specificato nel CIDR formato. È possibile utilizzare entrambi IPv4 gli IPv6 indirizzi. I caratteri jolly non sono supportati. Non è possibile specificare 255.255.255.255/32 CIDR la condizione della regola 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"]
      }
  }
]

HTTPheader e Application Load Balancer

HTTPle richieste e HTTP le risposte utilizzano i campi di intestazione per inviare informazioni sui messaggi. HTTP HTTPle intestazioni 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 set standard di campi di HTTP intestazione è definito in RFC 2616, Message Headers. Sono disponibili anche HTTP intestazioni non standard che vengono aggiunte automaticamente e ampiamente utilizzate dalle applicazioni. Alcune HTTP intestazioni non standard hanno un prefisso. X-Forwarded Gli Application Load Balancer supportano le seguenti intestazioni X-Forwarded.

Per ulteriori informazioni sulle HTTP connessioni, consulta Request routing nella Elastic Load Balancing User Guide.

X-Forwarded-For

L'intestazione della X-Forwarded-For richiesta consente di identificare l'indirizzo IP di un client quando si utilizza un sistema di bilanciamento del carico HTTP oHTTPS. 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, conservare o rimuovere l'X-Forwarded-Forintestazione nella HTTP richiesta prima che Application Load Balancer invii la richiesta 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 preserve modalità dell'attributo garantisce che l'X-Forwarded-Forintestazione della HTTP richiesta non venga modificata in alcun modo prima di essere inviata alle destinazioni.

Rimuovi

La remove modalità dell'attributo rimuove l'X-Forwarded-Forintestazione nella HTTP richiesta prima che venga inviata ai target.

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 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 X-Forwarded-Proto richiesta consente di identificare il protocollo (HTTPoHTTPS) utilizzato da un client per connettersi al sistema di bilanciamento del carico. 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.

L'applicazione o il sito Web possono utilizzare il protocollo memorizzato nell'intestazione della X-Forwarded-Proto richiesta per fornire una risposta che reindirizza a quella appropriata. URL

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

X-Forwarded-Proto: originatingProtocol

L'esempio seguente contiene un'intestazione di X-Forwarded-Proto richiesta per una richiesta proveniente 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.