Ascoltatori per Application Load Balancer - Sistema di bilanciamento del carico elastico

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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 definite per un ascoltatore determinano il modo in cui il sistema di bilanciamento del carico instrada le richieste alle destinazioni registrate, come le istanze EC2.

Configurazione dei listener

I listener supportano i seguenti protocolli e porte:

  • Protocolli: HTTP, HTTPS

  • Porte: 1-65535

È 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.

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:


                                La regola predefinita per un listener.

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:

authenticate-cognito

[Ascoltatori HTTPS] Utilizzare Amazon Cognito per autenticare gli utenti. Per ulteriori informazioni, consulta Autenticazione degli utenti tramite Application Load Balancer.

authenticate-oidc

[Listener HTTPS] Utilizzare un provider di identità compatibile con OpenID Connect (OIDC) per autenticare gli utenti.

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.

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.

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

È 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.

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

È 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.

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

New EC2 experience

                                    Una regola che reindirizza la richiesta a un URL che usa il protocollo HTTPS e la porta specificata (40443), ma mantiene il dominio, il percorso e i parametri di query originali dell'URL originale.
Old EC2 experience

                                    Una regola che reindirizza la richiesta a un URL che usa il protocollo HTTPS e la porta specificata (40443), ma mantiene il dominio, il percorso e i parametri di query originali dell'URL originale.

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

New EC2 experience

                                    Una regola che consente di reindirizzare la richiesta 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.
Old EC2 experience

                                    Una regola che consente di reindirizzare la richiesta 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.
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" } } ]

Tipi di condizioni della regola

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

host-header

Instradamento basato sul nome host di ogni richiesta. Per ulteriori informazioni, consulta Condizioni host.

http-header

Instradamento basato sulle intestazioni HTTP per ogni richiesta. Per ulteriori informazioni, consulta Condizioni nell'intestazione HTTP.

http-request-method

Instradamento basato sul metodo della richiesta HTTP di ogni richiesta. Per ulteriori informazioni, consulta Condizioni del metodo di richiesta HTTP.

path-pattern

Instradamento basato sui modelli di percorso negli URL di richiesta. Per ulteriori informazioni, consulta Condizioni percorso.

query-string

Instradamento basato su coppie chiave/valore nelle stringhe di query. Per ulteriori informazioni, consulta Condizioni delle stringhe di query.

source-ip

Instradamento basato sull’indirizzo IP di origine di ogni richiesta. Per ulteriori informazioni, consulta Condizioni indirizzo IP di origine.

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.

Esempio di condizione di intestazione HTTP per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un’intestazione Utente-Agente che corrisponde a una delle stringhe specificate.

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

Esempio di condizione del metodo HTTP per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La condizione seguente è soddisfatta dalle richieste che utilizzano il metodo specificato.

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

  • A-Z, a-z, 0-9

  • - .

  • * (corrisponde a 0 o più caratteri)

  • ? (corrisponde esattamente a 1 carattere)

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

Esempio di nomi host
  • example.com

  • test.example.com

  • *.example.com

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

Esempio di condizione di intestazione dell'host per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un’intestazione host che corrisponde alla stringa specificata.

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

  • A-Z, a-z, 0-9

  • _ - . $ / ~ " ' @ : +

  • & (utilizzo di &)

  • * (corrisponde a 0 o più caratteri)

  • ? (corrisponde esattamente a 1 carattere)

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

Esempio di modelli di percorso HTTP
  • /img/*

  • /img/*/pics

Esempio di modelli di percorso gRPC
  • /package

  • /package.service

  • /package.service/method

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.

Esempio di condizione del modello di percorso per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un URL che contiene la stringa specificata.

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

Esempio di condizione della stringa di query per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con una stringa di query che include una coppia chiave/valore di "version=v1" o un set di chiavi impostato su “example”.

[ { "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. Puoi usare sia indirizzi IP IPv4 che IPv6. 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 dell'intestazione X-Forwarded-For. Per cercare gli indirizzi nell’intestazione X-Forwarded-For, utilizza una condizione http-header.

Esempio di condizione IP di origine per AWS CLI

Puoi specificare le condizioni quando crei o modifichi una regola. Per ulteriori informazioni consulta i comandi create-rule e modify-rule. La seguente condizione è soddisfatta dalle richieste con un indirizzo IP di origine in uno dei blocchi CIDR specificati.

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