Tipi di azione per le regole del listener

Le azioni determinano il modo in cui un sistema di bilanciamento del carico gestisce le richieste quando le condizioni per una regola del listener sono soddisfatte. Ogni regola deve avere almeno un'azione che specifichi come gestire le richieste corrispondenti. Ogni azione della regola ha un tipo e informazioni di configurazione. Gli Application Load Balancer supportano i seguenti tipi di azioni per le regole del listener.

Tipi di operazione

authenticate-cognito

[Ascoltatori HTTPS] Utilizzare Amazon Cognito per autenticare gli utenti. Per ulteriori informazioni, consulta Configurazione dell'autenticazione utente.

authenticate-oidc

[Listener HTTPS] Utilizzare un provider di identità compatibile con OpenID Connect (OIDC) per autenticare gli utenti. Per ulteriori informazioni, consulta Configurazione dell'autenticazione utente.

fixed-response

Restituire una risposta HTTP personalizzata. Per ulteriori informazioni, consulta Operazioni con risposta fissa.

forward

Inoltrare le richieste verso il gruppo di destinazioni indicato. Per ulteriori informazioni, consulta Operazioni di inoltro.

redirect

Reindirizzare le richieste da un URL a un altro. Per ulteriori informazioni, consulta Operazioni di reindirizzamento.

Nozioni di base sulle azioni

• Ogni regola deve includere esattamente una delle seguenti azioni di routing: forwardredirect,fixed-response, o e deve essere l'ultima azione da eseguire.

• Un listener HTTPS può avere una regola con un'azione di autenticazione utente e un'azione di routing.

• Quando sono presenti più azioni, l'azione con la priorità più bassa viene eseguita per prima.

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

Operazioni con risposta fissa

Un'fixed-responseazione elimina le richieste del client e restituisce 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.

Esempio di azione a risposta fissa per AWS CLI

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. Le seguenti operazioni inviano una risposta fissa con il codice di stato specificato e il corpo del messaggio.

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

Operazioni di inoltro

Un'operazione forward instrada le richieste verso il gruppo target. Prima di aggiungere un’operazione forward, crea il gruppo target e aggiungi i target. Per ulteriori informazioni, consulta Crea un gruppo target per il tuo Application Load Balancer.

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.

Se si configura una regola per distribuire il traffico tra gruppi target ponderati e uno dei gruppi target è vuoto o contiene solo obiettivi non integri, il sistema di bilanciamento del carico non esegue automaticamente il failover su un gruppo target con obiettivi integri.

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 di destinazione 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.

Esempio di operazione di inoltro con un gruppo di destinazioni

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente operazione inoltra le richieste al gruppo di destinazioni specificato.

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

Esempio di operazione di inoltro con due gruppi di destinazioni ponderati

L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, in base al peso di ciascun gruppo di destinazioni.

[
  {
      "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
              }
          ]
      }
  }
]

Esempio di operazione di inoltro con persistenza abilitata

Se si dispone di un'operazione di inoltro con più gruppi di destinazioni e per uno o più gruppi di destinazioni sono abilitate le sessioni permanenti, è necessario abilitare la persistenza del gruppo di destinazioni.

L'operazione seguente inoltra le richieste ai due gruppi di destinazioni specificati, con la persistenza del gruppo di destinazioni abilitata. Le richieste che non contengono il cookie AWSALBTG vengono instradate in base al peso di ciascun gruppo di destinazioni.

[
  {
      "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

Un'redirectazione reindirizza le richieste dei 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.

protocol

Il protocollo (HTTP o HTTPS). È possibile reindirizzare i protocolli HTTP a HTTP, HTTP a HTTPS e HTTPS a HTTPS. Non è possibile reindirizzare i protocolli HTTPS a HTTP.

hostname

Il nome host. Il nome host non prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?) e trattini (-).

port

La porta (da 1 a 65535).

path

Il percorso assoluto, partendo da "/". Il percorso prevede la distinzione tra lettere maiuscole e minuscole, può contenere fino a 128 caratteri di lunghezza e può contenere caratteri alfanumerici, caratteri jolly (* e ?), & (con &) e i seguenti caratteri speciali: _-.$/~"'@:+

query

I parametri di query La lunghezza massima è 128 caratteri.

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

• #{protocol} - Mantiene il protocollo. Utilizzare nel protocollo e nei componenti query.

• #{host} - Mantiene il dominio. Utilizzare nel nome host, nel percorso e nei componenti query.

• #{port} - Mantiene la porta. Utilizzare nella porta, nel percorso e nei componenti query.

• #{path} - Mantiene il percorso. Utilizzare nel percorso e nei componenti query.

• #{query} - Mantiene i parametri di query. Utilizzare nel componente query.

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}".

Esempio di azione di reindirizzamento per AWS CLI

Puoi specificare un’operazione quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente azione reindirizza una richiesta HTTP a una richiesta HTTP sulla porta 443, con lo stesso nome host, percorso e stringa di query della richiesta HTTOP:

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